From extest-admin@lists.bell-labs.com Sun Oct 1 06:08:42 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA07578 for ; Sun, 1 Oct 2000 06:08:41 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C25FA44798 for ; Sun, 1 Oct 2000 05:05:13 -0400 (EDT) Subject: lists.bell-labs.com mailing list memberships reminder From: mailman-owner@lists.bell-labs.com To: sip-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: extest-admin@lists.bell-labs.com Errors-To: extest-admin@lists.bell-labs.com X-BeenThere: extest@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk Message-Id: <20001001090513.C25FA44798@lists.bell-labs.com> Date: Sun, 1 Oct 2000 05:05:13 -0400 (EDT) This is a reminder, sent out once a month, about your lists.bell-labs.com mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, sip-request@lists.bell-labs.com) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@lists.bell-labs.com. Thanks! Passwords for sip-archive@lists.ietf.org: List Password // URL ---- -------- sip@lists.bell-labs.com TDGd http://lists.bell-labs.com/mailman/options/sip/sip-archive%40lists.ietf.org From sip-admin@lists.bell-labs.com Sun Oct 1 11:22:14 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA09538 for ; Sun, 1 Oct 2000 11:22:04 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6CA3244337; Sun, 1 Oct 2000 10:22:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from dgesmtp01.wcom.com (dgesmtp01.wcom.com [199.249.16.16]) by lists.bell-labs.com (Postfix) with ESMTP id F3AA944336 for ; Sun, 1 Oct 2000 10:21:03 -0400 (EDT) Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-33 #42260) id <0G1R00I01BYR1Z@firewall.mcit.com> for sip@lists.bell-labs.com; Sun, 1 Oct 2000 15:20:51 +0000 (GMT) Received: from dgismtp03.wcomnet.com ([166.38.58.143]) by firewall.mcit.com (PMDF V5.2-33 #42260) with ESMTP id <0G1R00G3XBYRO7@firewall.mcit.com>; Sun, 01 Oct 2000 15:20:51 +0000 (GMT) Received: from CONVERSION-DAEMON by dgismtp03.wcomnet.com (PMDF V5.2-33 #42262) id <0G1R00601BVGNK@dgismtp03.wcomnet.com>; Sun, 01 Oct 2000 15:18:53 +0000 (GMT) Received: from dgismtp03.wcomnet.com by dgismtp03.wcomnet.com (PMDF V5.2-33 #42262) with SMTP id <0G1R00601BVGNH@dgismtp03.wcomnet.com>; Sun, 01 Oct 2000 15:18:52 +0000 (GMT) Received: from C25776A ([166.44.58.119]) by dgismtp03.wcomnet.com (PMDF V5.2-33 #42262) with SMTP id <0G1R00H91BV1V0@dgismtp03.wcomnet.com>; Sun, 01 Oct 2000 15:18:40 +0000 (GMT) From: Henry Sinnreich In-reply-to: <976F7C55E3B2D111A0720008C728549C048772C1@en0060exch001u.uk.lucent.com> To: "Casati, Alessio (Alessio)" , "'John M. Zwiebel'" Cc: "'Tony Ballardie '" , "'idmr '" , "'mboned '" , "'maddogs '" , sip@lists.bell-labs.com Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 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 Subject: [SIP] RE: WAN multicast status Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sun, 01 Oct 2000 10:19:51 -0500 Content-Transfer-Encoding: 7bit >Finally, I do agree that AAA is not the only issue >multicast faces >for true Internet scale deployment. The other issue I believe, is "interdomain". Looking back at the history of multicast to make another protocol successful (SIP), it appeared both "AAA" and "interdomain'" are required to make it successful. But this may be of interest to other WG's - the SIP WG most notably. Henry >-----Original Message----- >From: owner-mboned@network-services.uoregon.edu >[mailto:owner-mboned@network-services.uoregon.edu]On >Behalf Of Casati, >Alessio (Alessio) >Sent: Sunday, October 01, 2000 5:59 AM >To: 'John M. Zwiebel' >Cc: 'Henry Sinnreich '; 'Tony Ballardie '; 'idmr '; >'mboned '; 'maddogs >' >Subject: RE: WAN multicast status > > > > >> ^ A personal opinion in hindsight: The multicast >community did not >> ^ develop and standardize the AAA and payments >issues related to >> ^ multicast. >> >> I agree, but I don't believe it matters. IMHO folks >who want >> data replication in the network with very tight control over >> who sees it and pays for it are going to opt for layer-4-7 >> replication ala Microsoft and Real and others. >> >> >I think that the very fact one could >organize a DDoS attack by making many hosts join >a "monster number" of multicast groups in a region >of the Internet would make people think some form >of L3 control is needed. > >It's a problem of admission to the right to influence >multicast routing in the Internet, on a per multicast group >basis. > >Finally, I do agree that AAA is not the only issue >multicast faces >for true Internet scale deployment. Anyway, this is not >to say it is not possible to solve them all :). >In fact, John wants to go to the beach, eventually ;) > > >alessio > > > > > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sun Oct 1 23:17:00 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA17240 for ; Sun, 1 Oct 2000 23:17:00 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3557244337; Sun, 1 Oct 2000 22:17:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 55ED244336 for ; Sun, 1 Oct 2000 22:16:48 -0400 (EDT) Received: from eagle (1Cust97.tnt2.freehold.nj.da.uu.net [63.17.114.97]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with SMTP id XAA01651; Sun, 1 Oct 2000 23:18:34 -0400 (EDT) From: "Jonathan Rosenberg" To: , , Subject: RE: [SIP] SIP through firewalls without SIP proxy Message-ID: <000401c02c1f$5c4359e0$e69ffea9@dynamicsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 In-Reply-To: <87A245E94948D3118DE30008C716B01301523B86@c0005v1idc1.oss.level3.com> Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sun, 1 Oct 2000 23:17:55 -0400 Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Jon.Peterson@Level3.com [mailto:Jon.Peterson@Level3.com] > Sent: Saturday, September 30, 2000 3:34 PM > To: simon@firetalk.com; sip@lists.bell-labs.com > Subject: RE: [SIP] SIP through firewalls without SIP proxy > > > > In fact, there has been talk (out of the foglamps mailing list) of > chartering a new group to pursue this protocol in particular. > This group is > developing a framework document to describe the > characteristics of such a > firewall control protocol, see: > > http://search.ietf.org/internet-drafts/draft-kuthan-fcp-01.txt > > From a casual glance at your sketch below, it seems that your > work is in > line with the efforts in that community of interest. I'm sure > that group > would be happy to see more support of the exploration of > these sorts of > protocols. In fact, your proposal seems more or less to be the same as proposed in the above document. Whether the protocol is used between a proxy and the firewall/NAT and whether its used between the proxy and the firewall/NAT doesn't change the protocol. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 2 01:15:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA20420 for ; Mon, 2 Oct 2000 01:15:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 538994434D; Mon, 2 Oct 2000 00:15:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sumo.vocaltec.co.il (sumo.vocaltec.co.il [199.203.72.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5999544336 for ; Mon, 2 Oct 2000 00:14:23 -0400 (EDT) Received: from il4.vocaltec.co.il (notesgw.vocaltec.co.il [199.203.72.136]) by sumo.vocaltec.co.il (8.9.3/8.9.3) with ESMTP id IAA13665 for ; Mon, 2 Oct 2000 08:17:20 +0200 (IST) From: Joshua_Fox@vocaltec.com To: sip@lists.bell-labs.com X-Mailer: Lotus Notes Release 5.0.3 March 21, 2000 Message-ID: X-MIMETrack: Serialize by Router on IL4/Vocaltec_Comm(Release 5.0.3 |March 21, 2000) at 10/02/2000 08:13:24 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [SIP] logic in the peers or in the center Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 2 Oct 2000 08:13:23 +0200 As a newcomer to SIP, I have a question about the architecture to be used with SIP. SIP is devoted to initiating a session between two peers, then getting out of the way. There are many benefits to this architecture, particularly in the highly non-centralized Internet. Yet there is another architectural model, in which the center holds the logic. The call goes through a switch, which holds the intelligence about the call;The peers do not "know" whom they are communicating with. In a PSTN call to a call center placed with Automatic Call Distribution, for example, the caller does not know which call-center-agent will answer. Even once the call is started, there is no need for the caller's User Agent (telephone) to "know" that. (This is not a question of security, rather, it is a question of where the logic should reside). Likewise (unless a Customer Relations Management system is set up), the agent does not know the originating number, nor does s/he need to. The ACD can have complicated switching algorithms, which are not logically under the control of the peers. The essential difference is where to keep the the information "caller jones@somewhere.com is now in a session with smith@elsewhere.com and doe@nowhere.com". In SIP statelessness in the center (the servers) is a goal (although some stateful behaviors exist); in this alternate model, statefulness in the center and statelessness in the peers is the goal. Is SIP suited for this kind of centralized control? I realize that SIP, like any protocol, can be made to suit any task, but the question is whether these needs map onto SIP so naturally that it is the best protocol. Sincerely, Joshua Fox _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 2 01:17:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA20660 for ; Mon, 2 Oct 2000 01:17:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7BB5144352; Mon, 2 Oct 2000 00:17:01 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 4354C4434D for ; Mon, 2 Oct 2000 00:16:49 -0400 (EDT) Received: from eagle (1Cust97.tnt2.freehold.nj.da.uu.net [63.17.114.97]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with SMTP id BAA01975; Mon, 2 Oct 2000 01:18:21 -0400 (EDT) From: "Jonathan Rosenberg" To: "'hammer michael'" , "Doug Harbert" , "Simon Barber" Cc: "Jonathan Rosenberg" , "'Tom-PT Taylor'" , "'sip'" Subject: RE: [SIP] Re-direct of Media During Ringing Message-ID: <000401c02c30$177e9d40$e69ffea9@dynamicsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 In-Reply-To: <4.3.2.7.2.20000929102353.00b159c0@cia.cisco.com> Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 2 Oct 2000 01:17:41 -0400 Content-Transfer-Encoding: 7bit I agree that the notion of the caller delivering all kinds of media to the called party, before the call is "answered", worries me a lot. Particularly if you want the called party to modify some aspect of the "early media session". Security is definitely a problem here. You can argue that the called party shouldn't return a 183 with SDP containing a sendrecv parameter if it didn't know the caller. But, this imposes an unreasonable burden on the called party. I think the problem is related to people's coupling of a session with answering a physical telephone device. To me, the example with the alarm clock is clear - a session has most definitely been started. Allowing re-invites before a session is established is complicated. Take the simple case of a normal phone call. Does the UAS need to collect all these invites, and then answer them all once it accepts the call? If it accepts, does it send a 200 OK to the first, then reject the rest, 200 OK to all of them? WHat happens if one of those transactions doesn't complete? The primary complexity is really holding on to those reinvites, and then responding to all when the call is answered. This is quite a pain. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com > -----Original Message----- > From: hammer michael [mailto:mhammer@cisco.com] > Sent: Friday, September 29, 2000 1:27 PM > To: Doug Harbert; Simon Barber > Cc: Jonathan Rosenberg; 'Tom-PT Taylor'; 'sip' > Subject: Re: [SIP] Re-direct of Media During Ringing > > > Simon, > > I would not rely on being able to identify the calling party > (long live > anonymity???). As I have noticed on the telephone network, > telemarketers > are very good at not identifying themselves ("out of area" on > my caller id > box) and can be expected to do the same on the net. > > Mike > > > At 05:59 PM 09/28/2000 -0600, Doug Harbert wrote: > >Simon Barber wrote: > > > > > > > Example service: > > > > > > > > > > Morning alarm clock, calls me on my SIP phone, > connecting early inbound > > > > > media first to a quiet internet radio station (the phone plays > > > > this on its > > > > > speaker, instead of ringing), then if unanswered after 2 > > > > minutes, re-invite > > > > > the early media to a thrash metal sample from an RTSP server. > > > > When the call > > > > > is answered connect me to a message telling me what's > on my to-do list > > > > > today, and reminding me it's my girlfriend's birthday. > > > > > > > > > > > > > The applications you describe here sound like sessions. In fact, > > > > any time one > > > > party delivers media to another party, there is a session and > > > > there should be > > > > explicit agreement between parties to form this session. Perhaps > > > > what is needed > > > > > > By this notion there should be no re-invite at all - > changing the media at > > > all would be counted as a new session, requiring the user > explicitly accept > > > the new session. I do not accept this at all. > > > >No, re-INVITE during an established session is ok. The above > example indicates > >a re-INVITE before the session has been established. > Possibly a better method > >would be to CANCEL the current INVITE and issue a new INVITE > to establish a > >different session. > > > > > > > > > > > > > > > > here is a way for your sip phone to automatically answer calls > > > > from your alarm > > > > clock, or for your pager to automatically answer calls and > > > > perform the page. > > > > These devices could modify their behaviors depending > upon the application > > > > requested for the session, low level alarm, high level > alarm, page. > > > > > > Automatically answering calls is different from > delivering media before the > > > answer. If you automatically answer a call there is no > possibility for the > > > callee to later really answer the call. For example the > alarm clock servive > > > I proposed would not be possible - the service is > terminated by the callee > > > answering the call, listening to a message, and hanging up. > > > > > > >If your SIP phone has automatically answered the call > because it recognizes > >that it is from your alarm clock, then the session is > established. There is no > >need to tear it down just because a person wants to talk. > Your phone as an > >intelligent endpoint could recognize the off hook, and if > necessary issue a > >re-INVITE to modify the session parameters for the voice call. > > > > > > > > > > > > > > > The recipient of the call or his/her agents (phones, pagers,...) > > > > must have the > > > > authority to decide whether or not to accept the session, and > > > > receive media. > > > > > > > > > > Certainly the recipient of the call should have good > control over what > > > sessions they accept, and these control should include > controls over > > > sessions delivering media before the call is answered. > These controls > > may be > > > partly provided in the UA and partly in the proxy servers > that forward the > > > call to the user's UA. > > > > > > Simon Barber > > > >Delivery of media to the callee before the session has been > completely setup > >worries me somehow (I picture telemarketers sending their > spiel into my living > >room). But I suppose that since the callee can accept or > reject this media via > >the SDP in the 183 then that allows sufficient control. This > may be useful if > >the endpoint can recognize the caller and allow or disallow > receipt of the > >media according to who is calling. Though if the SIP phone > can do this, it > >should be able to accept the call for call screening > purposes, and allow the > >callee to pick it up if he/she wants to. > > > >Doug Harbert > > > > > >_______________________________________________ > >SIP mailing list > >SIP@lists.bell-labs.com > >http://lists.bell-labs.com/mailman/listinfo/sip > > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 2 01:32:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA22587 for ; Mon, 2 Oct 2000 01:32:03 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D954B44356; Mon, 2 Oct 2000 00:32:01 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 0AC3B44352 for ; Mon, 2 Oct 2000 00:31:47 -0400 (EDT) Received: from eagle (1Cust97.tnt2.freehold.nj.da.uu.net [63.17.114.97]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with SMTP id BAA02008; Mon, 2 Oct 2000 01:33:33 -0400 (EDT) From: "Jonathan Rosenberg" To: "'Gethin Liddell'" , "Jonathan Rosenberg" , "'Dvir Oren'" , "'SIP'" Subject: RE: [SIP] received param Message-ID: <000601c02c32$37bb90c0$e69ffea9@dynamicsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 In-Reply-To: <00092917302500.26665@gethin> Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 2 Oct 2000 01:32:55 -0400 Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Gethin Liddell [mailto:gethin@ubiquity.net] > Sent: Friday, September 29, 2000 12:27 PM > To: Jonathan Rosenberg; 'Dvir Oren'; 'SIP' > Subject: RE: [SIP] received param > > > On Fri, 29 Sep 2000, Jonathan Rosenberg wrote: > > I agree that the proxy should not be checking the received > parameter, since > > it didn't insert it in the first place. In fact, I thought > that the spec > > said that the downstream proxy should actually remove the > received parameter > > before forwarding upstream. But, I couldn't find text > stating that in > > rfc2543 or the bis draft which said that. > > > > I think its a good idea to strip out the received tag. > Basically if a UA or > > proxy sends a request with a via parameter X, what comes back in the > > response should be exactly the same. > > > > Anyone object to adding this to the spec (along with text > clarifying not to > > look at the received parameter if it is there). > > no objection, but is this just gonna turn into another one of > those "be > strict on what you send and liberal on what you receive" scenario's, > > i.e. should it not be a MUST to send back vias without > modification but > a SHOULD in that clients are able to a handle modified vias as > described b4? Seems so. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 2 01:36:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA23095 for ; Mon, 2 Oct 2000 01:36:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 51E1644356; Mon, 2 Oct 2000 00:36:01 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id E137044352 for ; Mon, 2 Oct 2000 00:35:50 -0400 (EDT) Received: from eagle (1Cust97.tnt2.freehold.nj.da.uu.net [63.17.114.97]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with SMTP id BAA02029; Mon, 2 Oct 2000 01:37:45 -0400 (EDT) From: "Jonathan Rosenberg" To: "'farhan'" , "sip" Subject: RE: [SIP] distributed sip Message-ID: <000701c02c32$cd5105c0$e69ffea9@dynamicsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 In-Reply-To: <000001c0298a$5e265510$1200a8c0@bigboy> Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 2 Oct 2000 01:37:06 -0400 Content-Transfer-Encoding: 7bit > -----Original Message----- > From: farhan [mailto:farhan@hotfoon.com] > Sent: Thursday, September 28, 2000 2:34 PM > To: sip > Subject: [SIP] distributed sip > > > is there anything that prevents a sip deployment such that > all the ua's > behind a sip proxy are not sip compliant ? > let me build this up slowly. > 1. consider a multi-user host that can run individual sip UAs > for each user > logged in. > 2. we can replace the multiple instances of UA with a single > user agent that > is able to handle more than one simultaneous user. This may not seem > efficient, but there is nothing which prevents such a deployment. > 3. now consider that the physical endpoints are in turn > remotely located. > > We will at this stage have a distributed SIP wherein, the > actual endpoints > of a sip call are slave units of a central control unit and > the control unit > in turn is sip compliant (the slave units are not). I hate to break it to you, but this is not a new idea. Its exactly what is done in the mgcp/megaco gateway decomposition model. Its even been done in models where the protocol between "slave" and "controller" is not a master-slave protocol, but a call control protocol. I believe dialpad works this way for H.323. So, of course you can do it. As far as the SIP network is concerned, your controller is the SIP UA. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 2 02:32:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA02748 for ; Mon, 2 Oct 2000 02:32:04 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 442C54433F; Mon, 2 Oct 2000 01:32:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 54F4D44336 for ; Mon, 2 Oct 2000 01:31:33 -0400 (EDT) Received: from eagle (1Cust97.tnt2.freehold.nj.da.uu.net [63.17.114.97]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with SMTP id CAA02145; Mon, 2 Oct 2000 02:33:21 -0400 (EDT) From: "Jonathan Rosenberg" To: "'Jo Hornsby'" , "Jonathan Rosenberg" , , Subject: RE: [SIP] Outbound call routing Message-ID: <000d01c02c3a$91c36180$e69ffea9@dynamicsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 In-Reply-To: <001201c02891$31f2d260$4e34c3c1@ubiquity.co.uk> Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 2 Oct 2000 02:32:42 -0400 Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Jo Hornsby [mailto:jhornsby@ubiquity.net] > Sent: Wednesday, September 27, 2000 10:43 AM > To: Jonathan Rosenberg; Jon.Peterson@Level3.com; > sip@lists.bell-labs.com > Subject: RE: [SIP] Outbound call routing > > > > Seems like general consensus that Route would be the right mechanism > > here, no? > > The only problem I can see is where there is some need to end up > at a UA on a specific port. > > For instance, I want to contact: > sip:giles@giles.library.buffy.com:8000 > and route through supersip.com, this means I would form the Route > > Normal processing rules would have a proxy try and resolve > supersip.com using A records, and contact it on port 8000; this > probably isn't going to work. Since Route is serving a different purpose in this case than its normal post-Record-Route function, you would not construct it the same way. I would argue that the Route would look like: Route: sip:giles@giles.library.buffy.com;maddr=supersip.com Route: sip:giles@giles.library.buffy.com:8000 i.e., no port in the initial Route. How would the UA know to do this? Same as how it would know to use this Route in the first place - the configuration piece we have not yet discussed. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 2 02:34:59 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA02759 for ; Mon, 2 Oct 2000 02:34:59 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 38B784434E; Mon, 2 Oct 2000 01:35:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 19E8F4433F for ; Mon, 2 Oct 2000 01:34:51 -0400 (EDT) Received: from eagle (1Cust97.tnt2.freehold.nj.da.uu.net [63.17.114.97]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with SMTP id CAA02178; Mon, 2 Oct 2000 02:36:38 -0400 (EDT) From: "Jonathan Rosenberg" To: , "Jonathan Rosenberg" Cc: , Subject: RE: [SIP] Session Timer Question Message-ID: <000f01c02c3b$07291780$e69ffea9@dynamicsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 In-Reply-To: Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 2 Oct 2000 02:35:59 -0400 Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Bodgey [mailto:bodgey@in.huawei.com] > Sent: Wednesday, September 27, 2000 1:02 AM > To: Jonathan Rosenberg > Cc: sip@lists.bell-labs.com; christer.holmberg@lmf.ericsson.se > Subject: RE: [SIP] Session Timer Question > > > > The question is: does the UAS need to insert the > > > Session-Expires header > > > in the response? The UAC may even not be able to understand > > > it (even if > > > it does, there is nothing it can do with it since it doesn't > > > support the > > > session timer in the first place) and the UAS will do the > refreshes in > > > either case. > > > > Yes, its needed for the benefit of proxies along the path who may be > > interested in the information. > > > > -Jonathan R. > > When using the extension, we need use the "supported" header > to consult > between the UAS and UAC before either UAS or UAC adds some > extensions. So we > ought to define Option-tag to support the extension or a type > of extension > that is clasified from the many extensions. From page 1: Protocol Overview UACs which support the session timer extension defined here include a Supported header in all requests, excepting ACK, containing the option tag "timer" [4]. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 2 02:55:00 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA02913 for ; Mon, 2 Oct 2000 02:55:00 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D281044344; Mon, 2 Oct 2000 01:55:01 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lists.bell-labs.com (Postfix) with ESMTP id 2DD504433F for ; Mon, 2 Oct 2000 01:54:12 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id e926s6Z22339 for ; Mon, 2 Oct 2000 08:54:07 +0200 (MEST) 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 JAA19653 for ; Mon, 2 Oct 2000 09:54:05 +0300 (EET DST) Received: from lmf.ericsson.se (E005004B52C74-udp410841.lmf.ericsson.se [131.160.30.91]) by greymse1.lmf.ericsson.se (8.9.3 (PHNE_18979)/8.8.6) with ESMTP id JAA17594 for ; Mon, 2 Oct 2000 09:54:03 +0300 (EETDST) Message-ID: <39D83109.B0906929@lmf.ericsson.se> From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Content-Type: multipart/mixed; boundary="------------C9A5A6BDA9E99EF93F662B98" Subject: [SIP] Provisional responses in other direction Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 02 Oct 2000 09:54:01 +0300 This is a multi-part message in MIME format. --------------C9A5A6BDA9E99EF93F662B98 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, I have a question about a SIP/PSTN issue. When the caller sends an INVITE, he may include a ISUP MIME message body in the request, and the callee may send back ISUP MIMEs in the 18x- and/or 200 responses. But, what happens if the caller wants to send more ISUP MIMEs before he has received the final response for the INVITE? re-INVITEs should not be used before the final response to the first INVITE has been received, and PRACK can not be used since we don't know when/if there is going to be a ISUP MIME to be sent. One solution would be to use the INFO method, but is it allowed to use INFO before the session has been completely established? Regards, Christer Holmberg Ericsson Finland --------------C9A5A6BDA9E99EF93F662B98 Content-Type: text/x-vcard; charset=us-ascii; name="christer.holmberg.vcf" Content-Description: Card for Christer Holmberg Content-Disposition: attachment; filename="christer.holmberg.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Holmberg;Christer tel;cell:+358-40-5604412 tel;work:+358-9-2992943 x-mozilla-html:FALSE org:Ericsson;Advanced Signalling Research Laboratory adr:;;;;;; version:2.1 email;internet:christer.holmberg@lmf.ericsson.se title:System Designer fn:Christer Holmberg end:vcard --------------C9A5A6BDA9E99EF93F662B98-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 2 03:02:00 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA03020 for ; Mon, 2 Oct 2000 03:02:00 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5294A44344; Mon, 2 Oct 2000 02:02:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 23B1E44336 for ; Mon, 2 Oct 2000 02:01:47 -0400 (EDT) Received: from eagle (1Cust97.tnt2.freehold.nj.da.uu.net [63.17.114.97]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with SMTP id DAA02219; Mon, 2 Oct 2000 03:03:44 -0400 (EDT) From: "Jonathan Rosenberg" To: "'Sudipto Mukherjee'" , "Jonathan Rosenberg" Cc: Subject: RE: [SIP] Content-Disposition Header questions Message-ID: <001201c02c3e$d025b320$e69ffea9@dynamicsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 In-Reply-To: <39CF6AEF.F92151C5@cisco.com> Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 2 Oct 2000 03:03:04 -0400 Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Sudipto Mukherjee [mailto:sudiptom@cisco.com] > Sent: Monday, September 25, 2000 11:11 AM > To: Jonathan Rosenberg > Cc: 'sip@lists.bell-labs.com' > Subject: Re: [SIP] Content-Disposition Header questions > > > Jonathan, > > > > To indicate preconditions such as qos / security in 183 > as defined in > > > manyfolks draft, disposition-type is set to "session". > > > > Actually, no. The idea was that the preconditions draft > would have to define > > its own value here. Putting "preconditions" into the bis > draft made no sense > > if preconditions weren't even defined there. > > > > My understanding was the "attribute" line in the SDP such as a=qos: > would > further qualify the Content-Disposition value of "session" and enable > the UA to take the appropriate action. These preconditions are already > defined in manyfolks draft. > > Can these be used together ? My preference is that if something affects the behavior of SIP signaling, there be something about that in the SIP headers. That is why I would prefer a specific preconditions disposition to be defined. This will allow systems to be built that provide a clean separation between the SIP handling and the content handling. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 2 09:09:00 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA07391 for ; Mon, 2 Oct 2000 09:09:00 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7320B44341; Mon, 2 Oct 2000 08:09:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id CDBC74433F for ; Mon, 2 Oct 2000 08:08:10 -0400 (EDT) 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 JAA03696; Mon, 2 Oct 2000 09:07:59 -0400 (EDT) Message-ID: <39D888B0.89FD6327@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: "'hammer michael'" , Doug Harbert , Simon Barber , "'Tom-PT Taylor'" , "'sip'" Subject: Re: [SIP] Re-direct of Media During Ringing References: <000401c02c30$177e9d40$e69ffea9@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 02 Oct 2000 09:08:00 -0400 Content-Transfer-Encoding: 7bit It is also not clear why we need these pseudo/half/semi/virtual sessions in SIP. We can transfer sessions if we need to or use re-INVITE; billing and such should be handled at a lower layer, not the SIP layer. In general, I think it would be much better to label the 200 OK response with some informational indication what kind of session this is ("this is a robot speaking" or "you're not speaking to the party you dialed, but rather an automated failure announcement") rather than going down the 183 route for all but the most primitive PSTN legacy services. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 2 11:10:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA08910 for ; Mon, 2 Oct 2000 11:10:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id DE5E344341; Mon, 2 Oct 2000 10:10:01 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by lists.bell-labs.com (Postfix) with ESMTP id 17A0D4433F for ; Mon, 2 Oct 2000 10:09:29 -0400 (EDT) Received: from stsang4 (tsang-pc [192.4.8.80]) by thumper.research.telcordia.com (8.10.1/8.10.1) with SMTP id e92F9Oa15067; Mon, 2 Oct 2000 11:09:24 -0400 (EDT) From: "Simon Tsang (Telcordia Technologies)" To: "SIP mailing list (IETF)" , "Appliances (external) mailing list" 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.50.4133.2400 Importance: Normal Subject: [SIP] Event notification in SIP? Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 2 Oct 2000 11:09:23 -0400 Content-Transfer-Encoding: 7bit Folks, I'm looking for information on how events are represented in the SUBSCRIBE and NOTIFY methods. There is an ID draft-roach-sip-subscribe-notify-00.txt which proposes a new Event header, but I notice that it has expired. Does anyone know if it's been re-issued (it's not on the IETF IDs page) or if there is another ID which covers the same ground? Thanks, Simon --------- Simon Tsang (Ph.D) Research Scientist - Internet Service Management Research Telcordia Technologies ( http://www.telcordia.com ) E-mail: stsang@research.telcordia.com Phone: +1.973.829.4511 Fax: +1.973.829.5889 Post: MCC 1E 206R, 445 South Street, Morristown, NJ 07960, USA. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 2 13:44:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA11657 for ; Mon, 2 Oct 2000 13:44:02 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2E19D44341; Mon, 2 Oct 2000 12:44:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mailsrv02.multitude.com (mailsrv02.firetalk.com [204.178.116.251]) by lists.bell-labs.com (Postfix) with ESMTP id 3A5874433F for ; Mon, 2 Oct 2000 12:43:08 -0400 (EDT) Received: from sbarber2k (s242.firetalk.com [204.178.116.242]) by mailsrv02.multitude.com (Rockliffe SMTPRA 3.4.2) with SMTP id ; Mon, 2 Oct 2000 10:41:02 -0700 From: "Simon Barber" To: "Jonathan Rosenberg" , "'hammer michael'" , "Doug Harbert" Cc: "'Tom-PT Taylor'" , "'sip'" Subject: RE: [SIP] Re-direct of Media During Ringing Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0065_01C02C5D.C9C05660" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: <000401c02c30$177e9d40$e69ffea9@dynamicsoft.com> Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 2 Oct 2000 10:44:49 -0700 This is a multi-part message in MIME format. ------=_NextPart_000_0065_01C02C5D.C9C05660 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Jonathan Rosenberg: > I agree that the notion of the caller delivering all kinds of media to the > called party, before the call is "answered", worries me a lot. > Particularly > if you want the called party to modify some aspect of the "early media > session". Security is definitely a problem here. You can argue that the > called party shouldn't return a 183 with SDP containing a > sendrecv parameter > if it didn't know the caller. But, this imposes an unreasonable burden on > the called party. It would be unreasonable to expect every terminal to include this kind of policy decision. In the normal case calls coming from unknown callers will pass through a proxy that is part of the called party's domain. The called party's proxy should provide this filtering policy for incoming calls. > > I think the problem is related to people's coupling of a session with > answering a physical telephone device. To me, the example with the alarm > clock is clear - a session has most definitely been started. > > Allowing re-invites before a session is established is > complicated. Take the > simple case of a normal phone call. Does the UAS need to collect all these > invites, and then answer them all once it accepts the call? If it accepts, > does it send a 200 OK to the first, then reject the rest, 200 OK to all of > them? WHat happens if one of those transactions doesn't complete? The > primary complexity is really holding on to those reinvites, and then > responding to all when the call is answered. This is quite a pain. This comes back to a thread from several weeks ago - I believe the initial INVITE transaction should not extend over the 'ringing' period, but should complete immediately to signify 'ringing' (with a disposition indicating this). Then a subsequent re-invite with a disposition 'answered' would signify the change in the session when a call is answered. > > -Jonathan R. > > --- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > > -----Original Message----- > > From: hammer michael [mailto:mhammer@cisco.com] > > Sent: Friday, September 29, 2000 1:27 PM > > To: Doug Harbert; Simon Barber > > Cc: Jonathan Rosenberg; 'Tom-PT Taylor'; 'sip' > > Subject: Re: [SIP] Re-direct of Media During Ringing > > > > > > Simon, > > > > I would not rely on being able to identify the calling party > > (long live > > anonymity???). As I have noticed on the telephone network, > > telemarketers > > are very good at not identifying themselves ("out of area" on > > my caller id > > box) and can be expected to do the same on the net. > > > > Mike > > > > > > At 05:59 PM 09/28/2000 -0600, Doug Harbert wrote: > > >Simon Barber wrote: > > > > > > > > > Example service: > > > > > > > > > > > > Morning alarm clock, calls me on my SIP phone, > > connecting early inbound > > > > > > media first to a quiet internet radio station (the phone plays > > > > > this on its > > > > > > speaker, instead of ringing), then if unanswered after 2 > > > > > minutes, re-invite > > > > > > the early media to a thrash metal sample from an RTSP server. > > > > > When the call > > > > > > is answered connect me to a message telling me what's > > on my to-do list > > > > > > today, and reminding me it's my girlfriend's birthday. > > > > > > > > > > > > > > > > The applications you describe here sound like sessions. In fact, > > > > > any time one > > > > > party delivers media to another party, there is a session and > > > > > there should be > > > > > explicit agreement between parties to form this session. Perhaps > > > > > what is needed > > > > > > > > By this notion there should be no re-invite at all - > > changing the media at > > > > all would be counted as a new session, requiring the user > > explicitly accept > > > > the new session. I do not accept this at all. > > > > > >No, re-INVITE during an established session is ok. The above > > example indicates > > >a re-INVITE before the session has been established. > > Possibly a better method > > >would be to CANCEL the current INVITE and issue a new INVITE > > to establish a > > >different session. > > > > > > > > > > > > > > > > > > > > > here is a way for your sip phone to automatically answer calls > > > > > from your alarm > > > > > clock, or for your pager to automatically answer calls and > > > > > perform the page. > > > > > These devices could modify their behaviors depending > > upon the application > > > > > requested for the session, low level alarm, high level > > alarm, page. > > > > > > > > Automatically answering calls is different from > > delivering media before the > > > > answer. If you automatically answer a call there is no > > possibility for the > > > > callee to later really answer the call. For example the > > alarm clock servive > > > > I proposed would not be possible - the service is > > terminated by the callee > > > > answering the call, listening to a message, and hanging up. > > > > > > > > > >If your SIP phone has automatically answered the call > > because it recognizes > > >that it is from your alarm clock, then the session is > > established. There is no > > >need to tear it down just because a person wants to talk. > > Your phone as an > > >intelligent endpoint could recognize the off hook, and if > > necessary issue a > > >re-INVITE to modify the session parameters for the voice call. > > > > > > > > > > > > > > > > > > > > The recipient of the call or his/her agents (phones, pagers,...) > > > > > must have the > > > > > authority to decide whether or not to accept the session, and > > > > > receive media. > > > > > > > > > > > > > Certainly the recipient of the call should have good > > control over what > > > > sessions they accept, and these control should include > > controls over > > > > sessions delivering media before the call is answered. > > These controls > > > may be > > > > partly provided in the UA and partly in the proxy servers > > that forward the > > > > call to the user's UA. > > > > > > > > Simon Barber > > > > > >Delivery of media to the callee before the session has been > > completely setup > > >worries me somehow (I picture telemarketers sending their > > spiel into my living > > >room). But I suppose that since the callee can accept or > > reject this media via > > >the SDP in the 183 then that allows sufficient control. This > > may be useful if > > >the endpoint can recognize the caller and allow or disallow > > receipt of the > > >media according to who is calling. Though if the SIP phone > > can do this, it > > >should be able to accept the call for call screening > > purposes, and allow the > > >callee to pick it up if he/she wants to. > > > > > >Doug Harbert > > > > > > > > >_______________________________________________ > > >SIP mailing list > > >SIP@lists.bell-labs.com > > >http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > ------=_NextPart_000_0065_01C02C5D.C9C05660 Content-Type: text/x-vcard; name="Simon Barber.vcf" Content-Disposition: attachment; filename="Simon Barber.vcf" Content-Transfer-Encoding: quoted-printable BEGIN:VCARD VERSION:2.1 N:Barber;Simon FN:Simon Barber ORG:Firetalk Communications, Inc. TEL;WORK;VOICE:(650) 636-1924 TEL;CELL;VOICE:(650) 743-1919 ADR;WORK:;;5000 Shoreline Court, Suite 200;South San = Francisco;CA;94080;United States of America LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:5000 Shoreline Court, Suite = 200=3D0D=3D0ASouth San Francisco, CA 94080=3D0D=3D0AUnit=3D ed States of America URL:http://www.firetalk.com URL:http://www.firetalk.com EMAIL;PREF;INTERNET:simon@firetalk.com REV:20000914T193921Z END:VCARD ------=_NextPart_000_0065_01C02C5D.C9C05660-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 2 14:00:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA11872 for ; Mon, 2 Oct 2000 14:00:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id DE84244341; Mon, 2 Oct 2000 13:00:01 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mailsrv02.multitude.com (mailsrv02.firetalk.com [204.178.116.251]) by lists.bell-labs.com (Postfix) with ESMTP id A703F4433F for ; Mon, 2 Oct 2000 12:59:07 -0400 (EDT) Received: from sbarber2k (s242.firetalk.com [204.178.116.242]) by mailsrv02.multitude.com (Rockliffe SMTPRA 3.4.2) with SMTP id ; Mon, 2 Oct 2000 10:57:02 -0700 From: "Simon Barber" To: "Jonathan Rosenberg" , , Subject: RE: [SIP] SIP through firewalls without SIP proxy Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0068_01C02C60.06072CF0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: <000401c02c1f$5c4359e0$e69ffea9@dynamicsoft.com> Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 2 Oct 2000 11:00:49 -0700 This is a multi-part message in MIME format. ------=_NextPart_000_0068_01C02C60.06072CF0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit I am proposing a protocol that runs on any character stream between the client (behind the firewall) and a server (outside the firewall), and that does not need any special arrangements made on the firewall. The best example would be using HTTP to communicate between the client and the server - this channel is the most commonly available channel on the internet (except e-mail), and may pass through proxys and firewalls between the client and server. The key difference between this and foglamps or SOCKS is that this does not require the firewall administrator's permission, or even knowledge. For this to work UDP and TCP data and control must all pass over the same connection. Simon Barber > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Sunday, October 01, 2000 8:18 PM > To: Jon.Peterson@Level3.com; simon@firetalk.com; sip@lists.bell-labs.com > Subject: RE: [SIP] SIP through firewalls without SIP proxy > > > > > > > -----Original Message----- > > From: Jon.Peterson@Level3.com [mailto:Jon.Peterson@Level3.com] > > Sent: Saturday, September 30, 2000 3:34 PM > > To: simon@firetalk.com; sip@lists.bell-labs.com > > Subject: RE: [SIP] SIP through firewalls without SIP proxy > > > > > > > > In fact, there has been talk (out of the foglamps mailing list) of > > chartering a new group to pursue this protocol in particular. > > This group is > > developing a framework document to describe the > > characteristics of such a > > firewall control protocol, see: > > > > http://search.ietf.org/internet-drafts/draft-kuthan-fcp-01.txt > > > > From a casual glance at your sketch below, it seems that your > > work is in > > line with the efforts in that community of interest. I'm sure > > that group > > would be happy to see more support of the exploration of > > these sorts of > > protocols. > > In fact, your proposal seems more or less to be the same as > proposed in the > above document. Whether the protocol is used between a proxy and the > firewall/NAT and whether its used between the proxy and the firewall/NAT > doesn't change the protocol. > > -Jonathan R. > --- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > ------=_NextPart_000_0068_01C02C60.06072CF0 Content-Type: text/x-vcard; name="Simon Barber.vcf" Content-Disposition: attachment; filename="Simon Barber.vcf" Content-Transfer-Encoding: quoted-printable BEGIN:VCARD VERSION:2.1 N:Barber;Simon FN:Simon Barber ORG:Firetalk Communications, Inc. TEL;WORK;VOICE:(650) 636-1924 TEL;CELL;VOICE:(650) 743-1919 ADR;WORK:;;5000 Shoreline Court, Suite 200;South San = Francisco;CA;94080;United States of America LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:5000 Shoreline Court, Suite = 200=3D0D=3D0ASouth San Francisco, CA 94080=3D0D=3D0AUnit=3D ed States of America URL:http://www.firetalk.com URL:http://www.firetalk.com EMAIL;PREF;INTERNET:simon@firetalk.com REV:20000914T193921Z END:VCARD ------=_NextPart_000_0068_01C02C60.06072CF0-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 2 18:10:59 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA14846 for ; Mon, 2 Oct 2000 18:10:58 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 085184433F; Mon, 2 Oct 2000 17:11:01 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ivigate.intervoice.com (ivigate.intervoice.com [208.200.21.196]) by lists.bell-labs.com (Postfix) with ESMTP id A0C1244338 for ; Mon, 2 Oct 2000 17:10:19 -0400 (EDT) Received: from itmail-ict1.wichita.brite.com (itmail-ict1.wichita.brite.com [151.214.5.174]) by ivigate.intervoice.com (Build 98 8.9.3/NT-8.9.3) with ESMTP id RAA27994; Mon, 02 Oct 2000 17:13:01 -0500 Received: by itmail-ict1-imc.wichita.brite.com with Internet Mail Service (5.5.2448.0) id ; Mon, 2 Oct 2000 17:06:23 -0500 Message-ID: From: "Culpepper, Bert" To: Gonzalo Camarillo Cc: Rohan Mahy , Jonathan Rosenberg , sip@lists.bell-labs.com, Henning Schulzrinne , mmusic MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] draft-camarillo-sip-sdp-00.txt Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 2 Oct 2000 17:06:22 -0500 Hi, I'm not writing to present a problem with this proposal but to state a need for it? For a specific case not mentioned in the draft. A "3rd-party call agent" may need to be able to receive tones and also have them be presented to the 2nd party. Tone transport is defined by RFC2833, it recommends that gateways remove the tones from the audio media. So..., I'd like an endpoint to understand the following media description in a session description. m=audio 10010 RTP/AVP 4 c=IN IP4 111.2.30.4 a=rtpmap:4 G723/8000 m=audio 10020 RTP/AVP 97 c=IN IP4 111.2.30.4 a=rtpmap:97 telephone-event a=fmtp:97 0-15 m=audio 20000 RTP/AVP 97 c=IN IP4 111.2.31.10 a=rtpmap:97 telephone-event a=fmtp:97 0-15,16 (In this case one "c" line can be used in the session description instead of how it's shown.) Nothing I read in RFC 2543 (SIP) and RFC 2327 (SDP) indicates the above is not allowed. This is not a standards issue but I wonder how many endpoints (gateways included) will support sending the two media types to the different destinations as indicated above. If in SIP the above session description doesn't result in three "media streams" being sent to the indicated host/port, media replication (which may not be present in an endpoint) will require a specific resource in the network. Is the use of the flow ID attribute required to achieve the above? Am I incorrect in what I think should result from the above session description in SIP? The ID does seem to encourage endpoint support for media replication to different hosts and ports which I'd like to see as standard functionality in some endpoints & environments. Regards, Bert _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 2 18:41:46 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA15185 for ; Mon, 2 Oct 2000 18:41:46 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2E32B44371; Mon, 2 Oct 2000 17:40:07 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14]) by lists.bell-labs.com (Postfix) with ESMTP id 3FFBE44338; Mon, 2 Oct 2000 17:39:24 -0400 (EDT) Received: from fokus.gmd.de (dhcp082 [195.37.78.210]) by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id AAA10539; Tue, 3 Oct 2000 00:38:48 +0200 (MET DST) Message-ID: <39D90E55.217B38D@fokus.gmd.de> From: Jiri Kuthan Organization: GMD Fokus X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: kuthan@fokus.gmd.de Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Subject: [SIP] iptel2001 Call for Papers Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 03 Oct 2000 00:38:13 +0200 Content-Transfer-Encoding: 8bit Call for Papers 2nd IP Telephony Workshop April 2-3, 2001 - Columbia University, New York City http://www.fokus.gmd.de/events/iptel2001/ Objectives ---------- Internet telephony is rapidly evolving from research to design and deployment. The objectives of the IP Telephony Workshop are to bring together researchers, developers, vendors and service providers active in this area and stimulate discussion on innovation, research, implementation, deployment experiences and future directions. Scope & Topics -------------- Original technical articles related to IP telephony are solicited. Only papers with significant technical content, not "white papers" or tutorials, will be considered for publication: - Research papers (unique ideas, novel algorithms, architectures, measurements, theoretical and/or analytical contributions) - Surveys, state-of-the-art studies, technology comparisons - Implementation and deployment reports - Standardization reports Particular areas of interest include, but are not limited to, the following: - Integration with Internet services (e.g., web, instant messaging, games) - Added-value services (e.g., call centers, conferencing) - Mobility and 3rd generation wireless - Authentication, authorization, accounting, charging, settlement - QoS support - Security (e.g., privacy, authentication, certification authorities, firewall traversal) - Call signaling & processing - Feature creation - Supporting services (e.g., call routing, lookup services) - Audio & video encoding and transmission - Management and provisioning - Interworking with the PSTN - Design and deployment considerations (e.g., performance, scalability, reliability) Important Dates --------------- Full paper due November 27th, 2000 Notification of acceptance January 12th, 2001 Final version due January 31st, 2001 Program published and February 5th, 2001 registration opens Workshop April 2nd-3rd, 2001 iptel2001 Organizing Committee ------------------------------ Program Chair H. Schulzrinne Columbia University Program Committee M. Arango Sun Microsystems F. Baker Cisco W. Bauerfeld T-Nova G. Bond AT&T Research S. Bradner Harvard University G. Carle GMD FOKUS J. Crowcroft UCL C. Huitema Microsoft G. S. Kuo National Central University, Taiwan J. Kuthan GMD Fokus T. Magedanz IKV++ GmbH W. Marshall AT&T Research K. Mehdi University of Kansas D. Oran Cisco J. Ott University of Bremen T. La Porta Bell Labs B. Rosen Marconi J. Rosenberg dynamicsoft H. Sinnreich MCI WorldCom R. Steinmetz Technical University of Darmstadt H. Stüttgen NEC CCRLE W. Wimmreuter Siemens L. Wolf University of Karlsruhe A. Wolisz Technical University of Berlin M. Zitterbart Technical University of Braunschweig Submission Instructions ----------------------- Authors are invited to submit full papers written in English before November 27th, 2000. The submissions will be reviewed, and accepted papers will be included in the program. Notifications of acceptance will be sent out on January 12th, 2000. Deadline for submission of camera-ready copies is January 31st, 2001. Authors of accepted papers will need to sign a Copyright Transfer Form and submit a Netbib entry. Papers must be submitted electronically using the Web site at http://www.cs.columbia.edu/iptel Submissions must be in PDF or Postscript; any other documents cannot be accepted. Postscript papers must use only standard PostScript fonts: Times Roman, Courier, Symbol, and Helvetica. Papers must be formatted according to the IEEE Transactions format except for the font size, which MUST be 11pt. Templates are available at the Web site http://www.fokus.gmd.de/events/iptel2001/cfp/ Because of the size limitation on the final manuscript, and to ensure that the reviewed paper and the final version have a similar size, papers with more than 11 pages cannot be reviewed. Submissions must include: title, authors, affiliation, abstract, list of keywords, and contact information. One of the authors of each accepted paper must present the paper at iptel'2001. Contact Address --------------- Please, send all your inquiries regarding iptel2001 to iptel2001@egroups.com. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 2 21:17:00 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA16658 for ; Mon, 2 Oct 2000 21:17:00 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3EE6444345; Mon, 2 Oct 2000 20:17:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id D8DE544338 for ; Mon, 2 Oct 2000 20:16:29 -0400 (EDT) Received: from CINQUECENTO (c500355-a.plano1.tx.home.com [24.10.21.154]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with SMTP id VAA10900; Mon, 2 Oct 2000 21:18:28 -0400 (EDT) From: "Robert Sparks" To: "Jonathan Rosenberg" , Subject: RE: [SIP] RE: REFER -> Referred-By syntax Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 2 Oct 2000 20:13:32 -0500 Content-Transfer-Encoding: 7bit I agree with Jonathan's suggestion. One small thing to note: A side effect of allowing the arguments to be completely unordered is removing "href" and "scheme" from the set of parameter names that can appear in sig-scheme-params. In the extremely unlikely event that someone developed a scheme in other circles that used those parameter names, and we wanted to use it for SIP, we would have to map them into something that didn't collide. > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Thursday, September 28, 2000 11:54 AM > To: 'Eric Tremblay'; 'Robert Sparks'; 'sip@lists.bell-labs.com' > Subject: RE: [SIP] RE: REFER -> Referred-By syntax > > > Referrer URL should definited be name-addr or addr-spec. > > Also, the BNF actually imposes an order on the parameters, which is > different from other headers. I would argue the BNF should be: > > Referred-By = "Referred-By" ":" (name-addr | addr-spec) *(";" > referred-by-params) > referred-by-params = referenced-url | ref-signature > > and then you would add wording that says referencd-url is mandatory. > > -Jonathan R. > > --- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > > -----Original Message----- > > From: Eric Tremblay [mailto:etremblay@mediatrix.com] > > Sent: Wednesday, September 27, 2000 8:58 PM > > To: 'Robert Sparks'; Eric Tremblay; sip@lists.bell-labs.com > > Subject: [SIP] RE: REFER -> Referred-By syntax > > > > > > > > I agree but for one thing (and this is probably what you meant): > > > > As per the Contact description, if "referrer-url" or "referenced-url" > > contains a comma, semicolon or question mark, then the URL with such a > > character MUST be enclosed within the "<" and ">" brackets. > > Otherwise, the > > URL does not need to be enclosed in the brackets (but it can > > be all the > > same). > > > > I think we should make this clear in the spec. > > > > As for the having a name-addr instead of a single SIP-URL for > > "referrer-url", I fully agree. > > > > Best regards, > > > > EricT > > > > -----Original Message----- > > From: Robert Sparks [mailto:rsparks@dynamicsoft.com] > > Sent: Wednesday, September 27, 2000 6:00 PM > > To: Eric Tremblay; sip@lists.bell-labs.com > > Subject: RE: REFER -> Referred-By syntax > > > > > > The -01 syntax follows Contact very closely. ref=, scheme= and > > the sig-scheme-params are all header parameters (they come after > > the first semicolon after the referred-by URL). You will have > > to go through the same level of effort to parse them that you > > go through for expires= on a Contact header. > > > > Things creating a Referred-By header SHOULD wrap URIs in <> > > wherever they occur, per the below recommendation. > > > > The primary deviation from the spirit of Contact's syntax is > > allowing only a SIP-URL for the referrer-url instead of allowing > > (name-addr|addr-spec). On reflection, the display-name in name-addr > > would probably be useful to parties receiving the header. Are there > > objections to allowing that? > > > > RjS > > > -----Original Message----- > > > From: Eric Tremblay [mailto:etremblay@mediatrix.com] > > > Sent: Wednesday, September 27, 2000 4:15 PM > > > To: 'Robert Sparks'; sip@lists.bell-labs.com > > > Subject: REFER -> Referred-By syntax > > > > > > > > > > > > I think the syntax of Referred-By should be reviewed: > > > > > > 1- The parser has to check for "ref" to find the beginning of the > > > "referenced-url", which (I think) goes against the suggestion in > > > draft-ietf-sip-guidelines-00.txt (and it badly breaks my > > parser ;) ): > > > > > > Headers that contain a list of URIs SHOULD follow the > > same syntax as > > > the Contact header in SIP. Implementors are also > > encouraged to always > > > wrap these URI in angle brackets "<" and ">". We have > > found this to > > > be a frequently misimplemented feature. > > > > > > 2- The same thing to find the beginning of "ref-signature", > > the parser has > > > to look out for "scheme" in the previous URL. > > > > > > > > > Shouldn't the syntax be something like the following (making the > > > "<" and ">" > > > brackets mandatory): > > > > > > Referred-By = ("Referred-By" | "b") ":" referrer-url > > > ";" referenced-url > > > [";" ref-signature] > > > referrer-url = "<" SIP-URL ">" > > > referenced-url = "<" URL ">" > > > ref-signature = signature-scheme *( ";" sig-scheme-params ) > > > signature-scheme = "scheme" "=" token > > > sig-scheme-parms = token "=" ( token | quoted-string ) > > > > > > > > > Best regards, > > > > > > EricT > > > > > > > > > > > > -----Original Message----- > > > From: Robert Sparks [mailto:rsparks@dynamicsoft.com] > > > Sent: Tuesday, September 26, 2000 10:06 AM > > > To: Tom-PT Taylor; sip@lists.bell-labs.com > > > Subject: [SIP] RE: Referred-By: ...referenced-url > > > > > > > > > Yes. > > > > > > The referenced party needs to be able to know, with proof, > > which of the > > > headers in > > > the request it receives came from the referrer, and that those > > > headers have > > > not been > > > modified. > > > > > > RjS > > > -----Original Message----- > > > From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com] > > > Sent: Monday, September 25, 2000 7:03 PM > > > To: sip@lists.bell-labs.com > > > Cc: 'rsparks@dynamicsoft.com' > > > Subject: Referred-By: ...referenced-url > > > > > > > > > According to draft-ietf-sip-cc-transfer-01.txt, the > > > referenced-url component > > > of the Referred-By: header contains a copy of the URL > > transmitted in the > > > Refer-To: header. What if the Refer-To: URL contains headers (e.g. > > > Accept-Contact:). Are these also reproduced in > > Referred-By:, particularly > > > as it appears in the REFER request? > > > Tom Taylor > > > > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 3 01:05:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA20901 for ; Tue, 3 Oct 2000 01:05:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3895A44349; Tue, 3 Oct 2000 00:05:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 3FBF244338 for ; Tue, 3 Oct 2000 00:04:18 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA11284; Tue, 3 Oct 2000 01:06:10 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Tue, 3 Oct 2000 01:00:42 -0400 Message-ID: From: Jonathan Rosenberg To: "'Simon Barber'" , Jonathan Rosenberg , "'Jon.Peterson@Level3.com'" , "'sip@lists.bell-labs.com'" Subject: RE: [SIP] SIP through firewalls without SIP proxy MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 3 Oct 2000 01:00:41 -0400 > -----Original Message----- > From: Simon Barber [mailto:simon@firetalk.com] > Sent: Monday, October 02, 2000 2:01 PM > To: Jonathan Rosenberg; Jon.Peterson@Level3.com; > sip@lists.bell-labs.com > Subject: RE: [SIP] SIP through firewalls without SIP proxy > > > I am proposing a protocol that runs on any character stream > between the > client (behind the firewall) and a server (outside the > firewall), and that > does not need any special arrangements made on the firewall. The best > example would be using HTTP to communicate between the client and the > server - this channel is the most commonly available channel > on the internet > (except e-mail), and may pass through proxys and firewalls between the > client and server. > > The key difference between this and foglamps or SOCKS is that > this does not > require the firewall administrator's permission, or even > knowledge. For this > to work UDP and TCP data and control must all pass over the > same connection. But they don't; the RTP is carried on a separate port from the signaling, which is one of the main problems. How would you handle this case? -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 3 01:15:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA22210 for ; Tue, 3 Oct 2000 01:15:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9F0E844372; Tue, 3 Oct 2000 00:15:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 10CBF44351 for ; Tue, 3 Oct 2000 00:14:40 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA11326; Tue, 3 Oct 2000 01:16:39 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Tue, 3 Oct 2000 01:11:11 -0400 Message-ID: From: Jonathan Rosenberg To: "'Joshua_Fox@vocaltec.com'" , "'sip@lists.bell-labs.com'" Subject: RE: [SIP] logic in the peers or in the center MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 3 Oct 2000 01:11:10 -0400 > -----Original Message----- > From: Joshua_Fox@vocaltec.com [mailto:Joshua_Fox@vocaltec.com] > Sent: Monday, October 02, 2000 2:13 AM > To: sip@lists.bell-labs.com > Subject: [SIP] logic in the peers or in the center > > > As a newcomer to SIP, I have a question about the > architecture to be used > with SIP. > > SIP is devoted to initiating a session between two peers, > then getting out > of the way. There are many benefits to this architecture, > particularly in > the highly non-centralized Internet. > > Yet there is another architectural model, in which the center > holds the > logic. The call goes through a switch, which holds the > intelligence about > the call;The peers do not "know" whom they are communicating with. > > In a PSTN call to a call center placed with Automatic Call > Distribution, > for example, the caller does not know which call-center-agent > will answer. > Even once the call is started, there is no need for the > caller's User Agent > (telephone) to "know" that. (This is not a question of > security, rather, it > is a question of where the logic should reside). Likewise (unless a > Customer Relations Management system is set up), the agent > does not know > the originating number, nor does s/he need to. The ACD can > have complicated > switching algorithms, which are not logically under the control of the > peers. > > The essential difference is where to keep the the information "caller > jones@somewhere.com is now in a session with smith@elsewhere.com and > doe@nowhere.com". In SIP statelessness in the center (the > servers) is a > goal (although some stateful behaviors exist); in this > alternate model, > statefulness in the center and statelessness in the peers is the goal. > > Is SIP suited for this kind of centralized control? Yes it is. It simply depends on which SIP elements you place where. SIP proxies, as you point out, are aimed towards statelessness. SIP user agents, on the other hand, have complete call state and control over the call. In the simplest model, proxies live "in the middle" in the network, with user agents only at the end. But, that need not be the case. THe middle of the network can contain an element generally referred to as a "back to back user agent", or B2BUA, which is a user agent server on one side, and a user agent client on the other. Using this mechanism, coupled with the third party call control mechanisms described in: http://search.ietf.org/internet-drafts/draft-rosenberg-sip-3pcc-00.txt elements in the network can maintain complete call state and complete control. Applications like ACD, click-to-dial, pre-paid calling, etc. are quite easy to do in this model. This does not require any extensions to SIP or changes in the way other entities work. SIP is just a protocol; there are many ways it can be used. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 3 01:26:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA23704 for ; Tue, 3 Oct 2000 01:26:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C84D444368; Tue, 3 Oct 2000 00:26:01 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 9CBD144351 for ; Tue, 3 Oct 2000 00:25:41 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA11395; Tue, 3 Oct 2000 01:27:37 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Tue, 3 Oct 2000 01:22:09 -0400 Message-ID: From: Jonathan Rosenberg To: "'Robert Sparks'" , Jonathan Rosenberg , "'sip@lists.bell-labs.com'" Subject: RE: [SIP] RE: REFER -> Referred-By syntax MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 3 Oct 2000 01:22:08 -0400 > -----Original Message----- > From: Robert Sparks [mailto:rsparks@dynamicsoft.com] > Sent: Monday, October 02, 2000 9:14 PM > To: Jonathan Rosenberg; sip@lists.bell-labs.com > Subject: RE: [SIP] RE: REFER -> Referred-By syntax > > > I agree with Jonathan's suggestion. > > One small thing to note: > > A side effect of allowing the arguments to be completely unordered is > removing "href" and "scheme" from the set of parameter names that > can appear in sig-scheme-params. Well, you're not removing them from the header, right? They would just also be normal header params along with referenced URL, right? > In the extremely unlikely event that > someone developed a scheme in other circles that used those parameter > names, and we wanted to use it for SIP, we would have to map > them into > something that didn't collide. This doesn't seem like a real problem. THanks, Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 3 02:03:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA01350 for ; Tue, 3 Oct 2000 02:03:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 314104433F; Tue, 3 Oct 2000 01:03:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sumo.vocaltec.co.il (sumo.vocaltec.co.il [199.203.72.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7C5F744338 for ; Tue, 3 Oct 2000 01:02:20 -0400 (EDT) Received: from il4.vocaltec.co.il (notesgw.vocaltec.co.il [199.203.72.136]) by sumo.vocaltec.co.il (8.9.3/8.9.3) with ESMTP id JAA13738; Tue, 3 Oct 2000 09:05:08 +0200 (IST) From: Joshua_Fox@vocaltec.com Subject: RE: [SIP] logic in the peers or in the center To: Jonathan Rosenberg , sip@lists.bell-labs.com X-Mailer: Lotus Notes Release 5.0.3 March 21, 2000 Message-ID: X-MIMETrack: Serialize by Router on IL4/Vocaltec_Comm(Release 5.0.3 |March 21, 2000) at 10/03/2000 09:01:12 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 3 Oct 2000 09:01:08 +0200 Thank you for pointing me to this alternate SIP architecture. With this alternate architecture, we place the User Agent logic in the center, in the server, thus leaving a logically much thinner client. With a completely distributed architecture, it is impossible to implement a full third-party-control architecture. For example, say that an ACD or the like decides that amy@anywhere.com and joe@somewhere.com should be conversing, but amy has not yet connected (she will, in a minute or two). This is easy enough, as long as the logic is in the center, but if the architecture requires us to store the fact that amy and joe are in session only in amy's and joe's peers, then we're in trouble. Since amy's User Agent is as yet unreachable, and according to this model we are not allowed to store the session state in the server, there is nowhere to store the session state. With the third-party control architecture and SIP, then, we would create a Back-to-Back User Agent for amy in the server, then hope she shows up. Joshua Fox _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 3 02:49:00 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA03802 for ; Tue, 3 Oct 2000 02:49:00 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9965844351; Tue, 3 Oct 2000 01:49:01 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lists.bell-labs.com (Postfix) with ESMTP id 7DFBD44338 for ; Tue, 3 Oct 2000 01:48:19 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id e936mDt04329; Tue, 3 Oct 2000 08:48:14 +0200 (MEST) Received: from lmf.ericsson.se (E005004B57CE1.lmf.ericsson.se [131.160.30.148]) by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id JAA27243; Tue, 3 Oct 2000 09:48:11 +0300 (EET DST) Message-ID: <39D9812A.71826411@lmf.ericsson.se> 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: Christer.Holmberg@lmf.ericsson.se Cc: sip@lists.bell-labs.com, Steve Donovan Subject: Re: [SIP] Provisional responses in other direction References: <39D83109.B0906929@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 03 Oct 2000 09:48:10 +0300 Content-Transfer-Encoding: 7bit Hi, Christer.Holmberg@lmf.ericsson.se wrote: > > Hi, > > I have a question about a SIP/PSTN issue. > > When the caller sends an INVITE, he may include a ISUP MIME message body > in the request, and the callee may send back ISUP MIMEs in the 18x- > and/or 200 responses. But, what happens if the caller wants to send more > ISUP MIMEs before he has received the final response for the INVITE? > re-INVITEs should not be used before the final response to the first > INVITE has been received, and PRACK can not be used since we don't know > when/if there is going to be a ISUP MIME to be sent. > > One solution would be to use the INFO method, but is it allowed to use > INFO before the session has been completely established? I believe that as soon as you receive the INVITE with a contact header you can send INFO back to the caller. You do not have to wait until the session is established (200 OK for the INVITE) for sending INFO. It is true that it is said in the draft that INFO is used for mid-session signalling, but I do not see a reason for avoiding sending it in the middle of the session establishment (before 200 OK has been sent). Does anybody see any reason that I might be missing? These INFO messages sent before the 200 OK for the INVITE can be used for tranfering ISUP messages from the callee to the caller before the ACM. Gonzalo > > Regards, > > Christer Holmberg > Ericsson Finland -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland http://www.hut.fi/~gonzalo _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 3 04:16:59 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA04322 for ; Tue, 3 Oct 2000 04:16:59 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 898BE44356; Tue, 3 Oct 2000 03:17:01 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lists.bell-labs.com (Postfix) with ESMTP id 75E5F44338 for ; Tue, 3 Oct 2000 03:16:34 -0400 (EDT) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id e938GUt06971 for ; Tue, 3 Oct 2000 10:16:30 +0200 (MEST) Received: FROM esealnt743.al.sw.ericsson.se BY esealnt461 ; Tue Oct 03 10:09:34 2000 +0200 Received: by esealnt743.al.sw.ericsson.se with Internet Mail Service (5.5.2651.58) id ; Tue, 3 Oct 2000 10:15:45 +0200 Message-ID: <56E7307B0850D411B1480008C75DD5EAB73CE1@enlrynt303.dsn.ericsson.se> From: "Arnoud van Wijk (ELN)" To: "'Jonathan Rosenberg'" , "'Simon Barber'" , "'Jon.Peterson@Level3.com'" , "'sip@lists.bell-labs.com'" Subject: RE: [SIP] SIP through firewalls without SIP proxy MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="ISO-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 3 Oct 2000 10:15:40 +0200 Hmm, what about a fixed port number for RTP traffic? (odd and even port) Maybe even a second and a third RTP port pair (in case of high traffic)? You will indeed leave the firewall open in this way, but it still would be a guarded entrance (only allow RTP/RTCP packets) Just my 2 cents. Arnoud van Wijk > -----Original Message----- > From: Simon Barber [mailto:simon@firetalk.com] > Sent: Monday, October 02, 2000 2:01 PM > To: Jonathan Rosenberg; Jon.Peterson@Level3.com; > sip@lists.bell-labs.com > Subject: RE: [SIP] SIP through firewalls without SIP proxy > > > I am proposing a protocol that runs on any character stream > between the > client (behind the firewall) and a server (outside the > firewall), and that > does not need any special arrangements made on the firewall. The best > example would be using HTTP to communicate between the client and the > server - this channel is the most commonly available channel > on the internet > (except e-mail), and may pass through proxys and firewalls between the > client and server. > > The key difference between this and foglamps or SOCKS is that > this does not > require the firewall administrator's permission, or even > knowledge. For this > to work UDP and TCP data and control must all pass over the > same connection. But they don't; the RTP is carried on a separate port from the signaling, which is one of the main problems. How would you handle this case? -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 3 05:01:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA04625 for ; Tue, 3 Oct 2000 05:01:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id F3CAF44381; Tue, 3 Oct 2000 04:01:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from gollum.axion.bt.co.uk (gollum.axion.bt.co.uk [132.146.17.41]) by lists.bell-labs.com (Postfix) with ESMTP id BE50344338 for ; Tue, 3 Oct 2000 04:00:16 -0400 (EDT) Received: from cbtlipnt01.btlabs.bt.co.uk by gollum (local) with ESMTP; Tue, 3 Oct 2000 09:59:14 +0100 Received: by cbtlipnt01.btlabs.bt.co.uk with Internet Mail Service (5.5.2652.35) id ; Tue, 3 Oct 2000 09:57:50 +0100 Message-ID: From: richard.swale@bt.com To: Arnoud.van.Wijk@eln.ericsson.se, jdrosen@dynamicsoft.com, simon@firetalk.com, Jon.Peterson@Level3.com, sip@lists.bell-labs.com Subject: RE: [SIP] SIP through firewalls without SIP proxy X-Mailer: Internet Mail Service (5.5.2652.35) MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 3 Oct 2000 09:56:45 +0100 Arnoud, Whilst I think this may be a practical solution for very small installations (at home perhaps) it will definitely not scale to large deployments - the number of physical boxes would become impractical from a physical management point of view and very expensive. There would also need to be some method of letting the end applications know which fixed port pairs they could use. Even then how would you do admission control between competing applications to avoid QoS problems for the media streams? regards Richard -----Original Message----- From: Arnoud van Wijk (ELN) [mailto:Arnoud.van.Wijk@eln.ericsson.se] Sent: Tuesday, October 03, 2000 9:16 AM To: 'Jonathan Rosenberg'; 'Simon Barber'; 'Jon.Peterson@Level3.com'; 'sip@lists.bell-labs.com' Subject: RE: [SIP] SIP through firewalls without SIP proxy Hmm, what about a fixed port number for RTP traffic? (odd and even port) Maybe even a second and a third RTP port pair (in case of high traffic)? You will indeed leave the firewall open in this way, but it still would be a guarded entrance (only allow RTP/RTCP packets) Just my 2 cents. Arnoud van Wijk > -----Original Message----- > From: Simon Barber [mailto:simon@firetalk.com] > Sent: Monday, October 02, 2000 2:01 PM > To: Jonathan Rosenberg; Jon.Peterson@Level3.com; > sip@lists.bell-labs.com > Subject: RE: [SIP] SIP through firewalls without SIP proxy > > > I am proposing a protocol that runs on any character stream > between the > client (behind the firewall) and a server (outside the > firewall), and that > does not need any special arrangements made on the firewall. The best > example would be using HTTP to communicate between the client and the > server - this channel is the most commonly available channel > on the internet > (except e-mail), and may pass through proxys and firewalls between the > client and server. > > The key difference between this and foglamps or SOCKS is that > this does not > require the firewall administrator's permission, or even > knowledge. For this > to work UDP and TCP data and control must all pass over the > same connection. But they don't; the RTP is carried on a separate port from the signaling, which is one of the main problems. How would you handle this case? -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 3 07:39:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA06507 for ; Tue, 3 Oct 2000 07:39:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 47F1044369; Tue, 3 Oct 2000 06:39:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sumo.vocaltec.co.il (sumo.vocaltec.co.il [199.203.72.1]) by lists.bell-labs.com (Postfix) with ESMTP id 52FFA44338 for ; Tue, 3 Oct 2000 06:38:45 -0400 (EDT) Received: from il4.vocaltec.co.il (notesgw.vocaltec.co.il [199.203.72.136]) by sumo.vocaltec.co.il (8.9.3/8.9.3) with ESMTP id OAA20924 for ; Tue, 3 Oct 2000 14:41:45 +0200 (IST) From: Joshua_Fox@vocaltec.com To: sip@lists.bell-labs.com X-Mailer: Lotus Notes Release 5.0.3 March 21, 2000 Message-ID: X-MIMETrack: Serialize by Router on IL4/Vocaltec_Comm(Release 5.0.3 |March 21, 2000) at 10/03/2000 02:37:49 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [SIP] choosing a SIP URL Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 3 Oct 2000 14:37:47 +0200 I've been studying SIP, and have a question about the SIP URL's. If this is a FAQ, please let me know, but I have not seen this addressed in the avaialble documentation including the RFC 2543 section 2. One of the great challenges of IP telephony is identifying the User. The IP Address, of course, won't do, since a User can switch machines and a machine can switch IP addresses (with dynamically assigned addresses). Yet we'd like to make it possible for a casual user to download an IP telephony client and place a call anonymously (as you might from a pay phone), without entering an email address or other unique identifier. One solution is to create a Universally Unique Identifier, using randomization (perhaps with other data tossed in to assure uniqueness). You would produce a SIP URL such as 4b2908a2ce45a8b9e04e5@xyz.com, where xyz.com is a domain name from the company providing the software Another solution is to simply require the user to register with identifying information. How has this been solved in the past? Sincerely, Joshua Fox _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 3 08:20:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA07834 for ; Tue, 3 Oct 2000 08:20:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B1FC44438A; Tue, 3 Oct 2000 07:20:01 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from dgesmtp02.wcom.com (dgesmtp02.wcom.com [199.249.16.17]) by lists.bell-labs.com (Postfix) with ESMTP id 980994438A for ; Tue, 3 Oct 2000 07:19:37 -0400 (EDT) Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-33 #42261) id <0G1U00001SWL12@firewall.mcit.com> for sip@lists.bell-labs.com; Tue, 3 Oct 2000 12:19:33 +0000 (GMT) Received: from dgismtp04.wcomnet.com ([166.38.58.144]) by firewall.mcit.com (PMDF V5.2-33 #42261) with ESMTP id <0G1U00M4TSWLCU@firewall.mcit.com>; Tue, 03 Oct 2000 12:19:33 +0000 (GMT) Received: from CONVERSION-DAEMON by dgismtp04.wcomnet.com (PMDF V5.2-33 #42262) id <0G1U00F01SYKZH@dgismtp04.wcomnet.com>; Tue, 03 Oct 2000 12:20:44 +0000 (GMT) Received: from dgismtp04.wcomnet.com by dgismtp04.wcomnet.com (PMDF V5.2-33 #42262) with SMTP id <0G1U00F01SYGYX@dgismtp04.wcomnet.com>; Tue, 03 Oct 2000 12:20:44 +0000 (GMT) Received: from C25776A ([166.44.57.223]) by dgismtp04.wcomnet.com (PMDF V5.2-33 #42262) with SMTP id <0G1U00F2ZSYC54@dgismtp04.wcomnet.com>; Tue, 03 Oct 2000 12:20:38 +0000 (GMT) From: Henry Sinnreich Subject: RE: [SIP] choosing a SIP URL In-reply-to: To: Joshua_Fox@vocaltec.com, sip@lists.bell-labs.com Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 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: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 03 Oct 2000 07:19:21 -0500 Content-Transfer-Encoding: 7bit >Another solution is to simply require the user to >register with identifying >information. See http://www.softarmor.com/sipwg/drafts/draft-johnston-sip-call-fl ows-00.txt Henry Henry Sinnreich MCI WorldCom 400 International Parkway Richardson, Texas 75081 USA >-----Original Message----- >From: sip-admin@lists.bell-labs.com >[mailto:sip-admin@lists.bell-labs.com]On Behalf Of >Joshua_Fox@vocaltec.com >Sent: Tuesday, October 03, 2000 7:38 AM >To: sip@lists.bell-labs.com >Subject: [SIP] choosing a SIP URL > > >I've been studying SIP, and have a question about the >SIP URL's. If this is >a FAQ, please let me know, but I have not seen this >addressed in the >avaialble documentation including the RFC 2543 section 2. > >One of the great challenges of IP telephony is >identifying the User. The IP >Address, of course, won't do, since a User can switch >machines and a >machine can switch IP addresses (with dynamically >assigned addresses). Yet >we'd like to make it possible for a casual user to >download an IP telephony >client and place a call anonymously (as you might from >a pay phone), >without entering an email address or other unique identifier. > >One solution is to create a Universally Unique >Identifier, using >randomization (perhaps with other data tossed in to >assure uniqueness). You >would produce a SIP URL such as >4b2908a2ce45a8b9e04e5@xyz.com, where >xyz.com is a domain name from the company providing >the software > >Another solution is to simply require the user to >register with identifying >information. > >How has this been solved in the past? > > >Sincerely, > >Joshua Fox > > >_______________________________________________ >SIP mailing list >SIP@lists.bell-labs.com >http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 3 09:45:13 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA10859 for ; Tue, 3 Oct 2000 09:45:13 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4334B4438B; Tue, 3 Oct 2000 08:45:14 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from jodie.lucid (unknown [212.25.93.158]) by lists.bell-labs.com (Postfix) with SMTP id 19AB444337 for ; Sat, 30 Sep 2000 08:30:52 -0400 (EDT) Received: (qmail 28643 invoked by uid 1002); 30 Sep 2000 13:32:43 -0000 From: Dvir Oren MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "farhan" Cc: SIP Subject: [SIP] distributed sip In-Reply-To: <000001c0298a$5e265510$1200a8c0@bigboy> References: <000001c0298a$5e265510$1200a8c0@bigboy> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14805.59978.749186.309459@jodie.lucid> Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sat, 30 Sep 2000 16:32:41 +0300 (IDT) Content-Transfer-Encoding: 7bit farhan writes ("[SIP] distributed sip"): > We will at this stage have a distributed SIP wherein, the actual endpoints > of a sip call are slave units of a central control unit and the control unit > in turn is sip compliant (the slave units are not). What you are suggesting is in fact some SIP-X gateway, where 'X' is some proprietery protocol that is supposed to be smaller than SIP. The network between the SIP gateway and the end point units is not a SIP network, but an 'X network'. You might even want to hink of using MGCP, which is client-server based, where the end points are just dumb terminals. I'm suggesting this since it might help to use something that already has been done. On the other hand, since between the SIP gateway and the remote units there is a network, you'll have to handle all the possible errors in the network. Basically, this will mean re-inventing a protocol. So, why not use an existing one? I don't even see why you can't use SIP. > client is just a 48kb slave totally controlled by hotfoon.com. As a I don't think you need one of those giant C++/Java implementations that are megabytes in size. You can do with a small implementation of SIP. -- Dvir Oren Lucid VON Ltd. 9 Saloniki St., Tel-Aviv Israel Tel: +972 3 644 3038 Fax: +972 3 644 3039 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 3 09:46:55 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA10950 for ; Tue, 3 Oct 2000 09:46:55 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B199344398; Tue, 3 Oct 2000 08:45:33 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from jodie.lucid (unknown [212.25.93.158]) by lists.bell-labs.com (Postfix) with SMTP id AC88144336 for ; Sat, 30 Sep 2000 08:40:07 -0400 (EDT) Received: (qmail 28678 invoked by uid 1002); 30 Sep 2000 13:42:00 -0000 From: Dvir Oren MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Jo Hornsby" Cc: SIP Subject: RE: [SIP] received param In-Reply-To: <003601c029f0$0e7878c0$4e34c3c1@ubiquity.co.uk> References: <14803.34874.915381.402119@jodie.lucid> <003601c029f0$0e7878c0$4e34c3c1@ubiquity.co.uk> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14805.60716.456500.974554@jodie.lucid> Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sat, 30 Sep 2000 16:41:59 +0300 (IDT) Content-Transfer-Encoding: 7bit Jo Hornsby writes ("RE: [SIP] received param"): > Isn't your DNS potentially flawed, then? I don't see why the proxy > can't know all the IP addresses that it's using (in the simplest > case, just make them configurable). I wouldn't say 'flawed', but it certainly is incomplete. The point is that DNS is an external function to the SIP implementation, and I can't force any DNS maintainer to enter all the IP addresses correctly. -- Dvir Oren Lucid VON Ltd. 9 Saloniki St., Tel-Aviv Israel Tel: +972 3 644 3038 Fax: +972 3 644 3039 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 3 09:49:45 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA11138 for ; Tue, 3 Oct 2000 09:49:45 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id F34EA4439E; Tue, 3 Oct 2000 08:45:49 -0400 (EDT) Delivered-To: sip@share.research.bell-labs.com Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by lists.bell-labs.com (Postfix) with SMTP id AAE9644336 for ; Sat, 30 Sep 2000 15:42:03 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by dirty; Sat Sep 30 16:40:18 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 9987A44380; Sat, 30 Sep 2000 16:27:08 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ans.ih.lucent.com (ans.ih.lucent.com [135.2.78.5]) by lists.bell-labs.com (Postfix) with SMTP id 54D224437D for ; Sat, 30 Sep 2000 16:27:08 -0400 (EDT) Received: by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id PAA02297; Sat, 30 Sep 2000 15:27:04 -0500 Received: from lucent.com by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id PAA02291; Sat, 30 Sep 2000 15:27:04 -0500 Message-ID: <39D64C92.F006E20@lucent.com> From: "Vijay K. Gurbani" Reply-To: vkg@lucent.com Organization: Intelligent Network/Messaging Systems & Internet Software Group X-Mailer: Mozilla 4.61 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] Second branch parameter Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sat, 30 Sep 2000 15:26:58 -0500 Content-Transfer-Encoding: 7bit All: Justifiably, the updated definition of an "isomorphic" request now includes the "second" branch parameter of the topmost Via header. My problem is, how does one recognize the "second" branch parameter? The bis draft says that "...The [branch] token MUST be unique for each distinct request. The precise format of the token is implementation- defined. In order to be able to both detect loops and associate responses with the corresponding requests, the parameter SHOULD consist of two parts separable by implementation." (Section 6.46, August bis) Two questions: 1) should the SHOULD be changed to a MUST? 2) should the bis specify what the separator token is? If not, consider a proxy that gets the following SIP request: INVITE sip:vkg@iit.edu ... Via: SIP/2.0/UDP exp1.example.com;branch=a7c68feda6711e3efa55 Via: SIP/2.0/UDP sip.ih.lucent.com How does the proxy know which is the "second" branch parameter of the topmost Via if it does not know what the separator is? The bis examples show branch parameters being delimited by a "." (at least that's my interpretation of them). However, I am not comfortable parsing the branch token looking for a "." to figure out what the "second" branch parameter is. Am I missing something here, or is this a problem? Thanks, -- Vijay K. Gurbani vkg@lucent.com vkg@research.bell-labs.com vkg@acm.org Internet Software Group/Intelligent Network and Messaging Systems Lucent Technologies/Bell Labs Innovations, 263 Shuman Blvd, Rm 1A-413 Naperville, Illinois 60566 Voice: +1 630 224 0216 Fax: +1 630 713 0184 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 3 09:51:43 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA11283 for ; Tue, 3 Oct 2000 09:51:43 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 040F1443A4; Tue, 3 Oct 2000 08:45:55 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from web313.mail.yahoo.com (web313.mail.yahoo.com [216.115.105.78]) by lists.bell-labs.com (Postfix) with SMTP id 850AF44337 for ; Sun, 1 Oct 2000 05:22:52 -0400 (EDT) Message-ID: <20001001102249.10854.qmail@web313.mail.yahoo.com> Received: from [147.8.180.8] by web313.mail.yahoo.com; Sun, 01 Oct 2000 03:22:49 PDT From: Pauline Wong To: sip@lists.bell-labs.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [SIP] SIP Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sun, 1 Oct 2000 03:22:49 -0700 (PDT) Dear all, How can I get/set a SIP address? Would you please reply me as soon as possible? Thanks. Best Regards, Ling __________________________________________________ Do You Yahoo!? Yahoo! Photos - 35mm Quality Prints, Now Get 15 Free! http://photos.yahoo.com/ _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 3 09:53:53 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA11396 for ; Tue, 3 Oct 2000 09:53:52 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 92612443B2; Tue, 3 Oct 2000 08:46:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by lists.bell-labs.com (Postfix) with ESMTP id 193EE4436C for ; Mon, 2 Oct 2000 17:20:54 -0400 (EDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [171.71.147.106]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id PAA16453; Mon, 2 Oct 2000 15:20:13 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id PAA06585; Mon, 2 Oct 2000 15:20:12 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14809.2588.603599.164604@thomasm-u1.cisco.com> To: "Roy, Radhika R, ALCOO" Cc: Billy Biggs , farhan , sip Subject: RE: [SIP] sip mobility with REGISTER In-Reply-To: References: X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 2 Oct 2000 15:20:12 -0700 (PDT) Content-Transfer-Encoding: 7bit Roy, Radhika R, ALCOO writes: > Hi, Billy: > > The bottom line of your argument is "performance (e.g., frequency of use, > latency, etc.)" problems, if you use anything in the SIP layer to address > mobility. > > Let assume for sake of argument that there is no performance problem: Will > the procedure work using REGISTER and re-INVITE? > > The second aspect of your assumption is that mobile IP mobile will solve all > problems. No, mobile IP has also problems from performance point of view > especially for real-time communications like voice in addition to fast > hand-offs and frequency of location updates. These are common problem regardless of whether you do it at L3 or L7. The thing that seriously pushes me toward the L3 solution is that in order to do fast handoff, it must be performed in a geographically/ topologically localized fashion or you're going to need to make c faster. The reason that this pushes me toward L3 is just from the standpoint of end to end transparency: I'd much rather tell the local provider that I want to move my attachment point for IP packets from here to there, rather than having to tell a localized SIP proxy to do the SIP equivalent (and http, and smtp, ad nauseum). This nicely avoids the e-2-e security problems of proxy routed traffic as well which makes me happy too :-) Mike _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 3 10:13:00 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12090 for ; Tue, 3 Oct 2000 10:13:00 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0BBF1443AB; Tue, 3 Oct 2000 09:13:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lists.bell-labs.com (Postfix) with ESMTP id A678444395 for ; Tue, 3 Oct 2000 09:12:43 -0400 (EDT) Received: from esealnt409.al.sw.ericsson.se (esealnt409.al.sw.ericsson.se [153.88.251.32]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id e93ECdZ17173 for ; Tue, 3 Oct 2000 16:12:39 +0200 (MEST) Received: FROM esealnt743.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Tue Oct 03 16:12:24 2000 +0200 Received: by esealnt743.al.sw.ericsson.se with Internet Mail Service (5.5.2651.58) id ; Tue, 3 Oct 2000 16:12:23 +0200 Message-ID: <56E7307B0850D411B1480008C75DD5EAB73CE6@enlrynt303.dsn.ericsson.se> From: "Arnoud van Wijk (ELN)" To: "'Pauline Wong'" , sip@lists.bell-labs.com Subject: RE: [SIP] SIP MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="ISO-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 3 Oct 2000 16:12:13 +0200 Hello Pauline. Getting a SIP address is very much like getting an E-mail address. It depends on the provider. A company I know gives SIP addresses. http://www.hotsip.com But we cannot use them yet. Arnoud _______________________________________________________________ ERICSSON EUROLABS NETHERLANDS BV Arnoud van Wijk ABACUS Lab Research & Development (ELN/V) Fax: +31-161 247569 _______________________________________________________________ -----Original Message----- From: Pauline Wong [mailto:paulineww@yahoo.com] Sent: zondag 1 okt 2000 12:23 To: sip@lists.bell-labs.com Subject: [SIP] SIP Dear all, How can I get/set a SIP address? Would you please reply me as soon as possible? Thanks. Best Regards, Ling __________________________________________________ Do You Yahoo!? Yahoo! Photos - 35mm Quality Prints, Now Get 15 Free! http://photos.yahoo.com/ _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 3 10:20:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12227 for ; Tue, 3 Oct 2000 10:20:02 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 46352443BE; Tue, 3 Oct 2000 09:20:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from drago1.ubiquity.net (unknown [194.202.146.92]) by lists.bell-labs.com (Postfix) with SMTP id 3A101443BD for ; Tue, 3 Oct 2000 09:19:52 -0400 (EDT) Received: from gecko.ubiquity.co.uk by drago1.ubiquity.net via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 3 Oct 2000 14:20:13 UT Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id PAA11605; Tue, 3 Oct 2000 15:18:08 +0100 (BST) From: "Jo Hornsby" To: , Subject: RE: [SIP] Second branch parameter Message-ID: <000201c02d44$c0b00100$4e34c3c1@ubiquity.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 In-Reply-To: <39D64C92.F006E20@lucent.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 3 Oct 2000 15:18:08 +0100 Content-Transfer-Encoding: 7bit > Justifiably, the updated definition of an "isomorphic" request now > includes the "second" branch parameter of the topmost Via header. My > problem is, how does one recognize the "second" branch parameter? The > bis draft says that "...The [branch] token MUST be unique for each > distinct request. The precise format of the token is implementation- > defined. In order to be able to both detect loops and associate > responses with the corresponding requests, the parameter SHOULD consist > of two parts separable by implementation." (Section 6.46, August bis) > > Two questions: > 1) should the SHOULD be changed to a MUST? > 2) should the bis specify what the separator token is? If not, consider > a proxy that gets the following SIP request: > > INVITE sip:vkg@iit.edu > ... > Via: SIP/2.0/UDP exp1.example.com;branch=a7c68feda6711e3efa55 > Via: SIP/2.0/UDP sip.ih.lucent.com > > How does the proxy know which is the "second" branch parameter of > the topmost Via if it does not know what the separator is? The > bis examples show branch parameters being delimited by a "." (at > least that's my interpretation of them). However, I am not > comfortable parsing the branch token looking for a "." to figure > out what the "second" branch parameter is. > > Am I missing something here, or is this a problem? I wouldn't perceive this as a problem, since the "second branch parameter" is by definition part of the whole branch parameter, thus you just use the whole branch parameter to distinguish. I don't see why the text bothers mentioning the "second part" explicitly, however; might as well just strike the word "second" from the definition of an Isomorphic Request. - Jo. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 3 10:23:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12339 for ; Tue, 3 Oct 2000 10:23:03 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B8238443CE; Tue, 3 Oct 2000 09:23:01 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by lists.bell-labs.com (Postfix) with ESMTP id 4DB904439B for ; Tue, 3 Oct 2000 09:22:28 -0400 (EDT) Received: from daebh01nok.americas.nokia.com (daebh01nok.americas.nokia.com [172.18.242.182]) by mgw-x2.nokia.com (8.10.2/8.10.2/Nokia) with ESMTP id e93EMLP22478; Tue, 3 Oct 2000 17:22:21 +0300 (EET DST) Received: by daebh01nok with Internet Mail Service (5.5.2448.0) id ; Tue, 3 Oct 2000 09:18:51 -0500 Message-ID: From: Cliff.Harris@nokia.com To: Gonzalo.Camarillo@lmf.ericsson.se, Christer.Holmberg@lmf.ericsson.se Cc: sip@lists.bell-labs.com Subject: RE: [SIP] Provisional responses in other direction MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 3 Oct 2000 09:15:36 -0500 One problem is that there may not be a tag and a route yet. Take a look at http://lists.bell-labs.com/pipermail/sip/2000q2/000006.html. You can send the INFO before you've got a tag, but then you're taking your chances, and the INFO may not get to the right place. A second problem is that SIP doesn't provide a general mechanism for ordering messages. An INFO will have a new CSeq, but any responses to the INVITE will not, and nor will the ACK, so the UA receiving the INFO will not be able to tell if it has been received out of order with respect to a response to the INVITE or an ACK. A UAS that was concerned about this issue could wait until the INFO or response (assuming the use of PRACKs) had been acknowledged before sending the next message. I wonder if a UAS should use 183 rather than INFO to send any attachments before the INVITE transaction is complete(?). The UAC, though, has no choice other than INFO. What call flows are you looking at that require the early INFOs? > -----Original Message----- > From: EXT Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > Sent: Tuesday, October 03, 2000 2:48 AM > To: Christer.Holmberg@lmf.ericsson.se > Cc: sip@lists.bell-labs.com; Steve Donovan > Subject: Re: [SIP] Provisional responses in other direction > > > Hi, > > Christer.Holmberg@lmf.ericsson.se wrote: > > > > Hi, > > > > I have a question about a SIP/PSTN issue. > > > > When the caller sends an INVITE, he may include a ISUP MIME > message body > > in the request, and the callee may send back ISUP MIMEs in the 18x- > > and/or 200 responses. But, what happens if the caller wants > to send more > > ISUP MIMEs before he has received the final response for the INVITE? > > re-INVITEs should not be used before the final response to the first > > INVITE has been received, and PRACK can not be used since > we don't know > > when/if there is going to be a ISUP MIME to be sent. > > > > One solution would be to use the INFO method, but is it > allowed to use > > INFO before the session has been completely established? > > > I believe that as soon as you receive the INVITE with a contact header > you can send INFO back to the caller. You do not have to wait > until the > session is established (200 OK for the INVITE) for sending INFO. It is > true that it is said in the draft that INFO is used for mid-session > signalling, but I do not see a reason for avoiding sending it in the > middle of the session establishment (before 200 OK has been sent). > > Does anybody see any reason that I might be missing? > > These INFO messages sent before the 200 OK for the INVITE can be used > for tranfering ISUP messages from the callee to the caller before the > ACM. > > Gonzalo > > > > > > > > > > > > Regards, > > > > Christer Holmberg > > Ericsson Finland > > -- > Gonzalo Camarillo Phone : +358 9 299 33 71 > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > Telecom R&D Fax : +358 9 299 30 52 > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > Finland http://www.hut.fi/~gonzalo > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 3 10:26:36 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12421 for ; Tue, 3 Oct 2000 10:26:36 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B6F85443DF; Tue, 3 Oct 2000 09:25:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from exchange01.iirltd.co.uk (unknown [193.133.64.178]) by lists.bell-labs.com (Postfix) with ESMTP id 5DFED443BE for ; Tue, 3 Oct 2000 09:16:08 -0400 (EDT) Received: by exchange01.iirltd.co.uk with Internet Mail Service (5.5.2650.21) id <4F3DVM0W>; Tue, 3 Oct 2000 15:16:33 +0100 Message-ID: From: Claire Tranah To: "'sip@lists.bell-labs.com'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] SIP Research and Interoperability Testing Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 3 Oct 2000 15:16:33 +0100 Hi there, I just wanted to thank all of who helped me with my research on SIP Implementation and Deployment and especially those of you who responded to the call of papers. The programme is now complete please visit www.iir-conferences.com/ipmobile and let me know what you think. We are also hosting a SIP Interoperability exhibition and I would love to hear from any vendors who might like to take part in this. I'm looking forward to your response. Once again thanks for all your help. Claire Tranah Conference Producer - Telecoms and Technology IIR Ltd tel. +44 (0) 20 7915 5097 email: ctranah@iir-conferences.com ********************************** see my latest conference at www.telecomstransmission.com/ipqos ********************************** _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 3 10:33:38 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12623 for ; Tue, 3 Oct 2000 10:33:38 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5067D443C1; Tue, 3 Oct 2000 09:30:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ckmso1.proxy.att.com (ckmso1.att.com [12.20.58.69]) by lists.bell-labs.com (Postfix) with ESMTP id 54D05443EB for ; Tue, 3 Oct 2000 09:29:02 -0400 (EDT) Received: from njb140r1.ems.att.com ([135.65.202.58]) by ckmso1.proxy.att.com (AT&T IPNS/MSO-2.2) with ESMTP id KAA03811; Tue, 3 Oct 2000 10:28:54 -0400 (EDT) Received: from njb140bh1.ems.att.com by njb140r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2) id KAA24933; Tue, 3 Oct 2000 10:27:32 -0400 (EDT) Received: by njb140bh1.ems.att.com with Internet Mail Service (5.5.2652.35) id ; Tue, 3 Oct 2000 10:28:53 -0400 Message-ID: From: "Roy, Radhika R, ALCOO" To: Michael Thomas Cc: Billy Biggs , farhan , sip Subject: RE: [SIP] sip mobility with REGISTER MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 3 Oct 2000 10:28:43 -0400 Hi, Mike: It is being examined how much L1, L2, L3, and/or upper layer (e.g., L7) need to be involved for the hand-off. So, it not so much pushing the L1 solution to L2/L3/L7. It is rather: What needs to be in each layer, if any, so far the hand-off is concerned as the point of attachment is changed during the session. Best regards, Radhika R. Roy AT&T -----Original Message----- From: Michael Thomas [mailto:mat@cisco.com] Sent: Monday, October 02, 2000 6:20 PM To: Roy, Radhika R, ALCOO Cc: Billy Biggs; farhan; sip Subject: RE: [SIP] sip mobility with REGISTER Roy, Radhika R, ALCOO writes: > Hi, Billy: > > The bottom line of your argument is "performance (e.g., frequency of use, > latency, etc.)" problems, if you use anything in the SIP layer to address > mobility. > > Let assume for sake of argument that there is no performance problem: Will > the procedure work using REGISTER and re-INVITE? > > The second aspect of your assumption is that mobile IP mobile will solve all > problems. No, mobile IP has also problems from performance point of view > especially for real-time communications like voice in addition to fast > hand-offs and frequency of location updates. These are common problem regardless of whether you do it at L3 or L7. The thing that seriously pushes me toward the L3 solution is that in order to do fast handoff, it must be performed in a geographically/ topologically localized fashion or you're going to need to make c faster. The reason that this pushes me toward L3 is just from the standpoint of end to end transparency: I'd much rather tell the local provider that I want to move my attachment point for IP packets from here to there, rather than having to tell a localized SIP proxy to do the SIP equivalent (and http, and smtp, ad nauseum). This nicely avoids the e-2-e security problems of proxy routed traffic as well which makes me happy too :-) Mike _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 3 10:37:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12732 for ; Tue, 3 Oct 2000 10:37:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id BFA6D443F3; Tue, 3 Oct 2000 09:30:06 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14]) by lists.bell-labs.com (Postfix) with ESMTP id 478AB443EB for ; Tue, 3 Oct 2000 09:29:08 -0400 (EDT) Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprch1.nortel.com; Tue, 3 Oct 2000 09:28:02 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Tue, 3 Oct 2000 09:27:55 -0500 Message-ID: <353093573B82D411889E0000F808216648E3B3@zcard00q.ca.nortel.com> From: "Peter Blatherwick" To: "'Dvir Oren'" , farhan Cc: SIP Subject: RE: [SIP] distributed sip MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C02D46.1D710280" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 3 Oct 2000 09:27:53 -0500 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_01C02D46.1D710280 Content-Type: text/plain; charset="iso-8859-1" Megaco IP Phone MG provides such a solution for master/slave controlled "dumb" appliances, which can easily be used within a SIP-based network. See http://www.ietf.org/internet-drafts/draft-ietf-megaco-ipphone-03.txt. Its currently in Last Call, for Informational RFC, in Megaco WG. Before the religious war starts (experience shows it will), I want to make it clear I very much like both SIP and the Megaco/H.248 approach to end devices. Both SIP-based and Megaco/H.248-based end user appliances have strong roles in the real world. The two models are completely compatible within a system, and are complementary in nature. Properly implemented, the end user actually can't tell the difference between the two approaches. While the peer-peer approach characterized by SIP is truly excellent for SmartPhone type applications supporting stand-alone features and services, the master/slave type approach characterized by Megaco/H.248 affords major advantages for new feature/service development and deployment, especially across large systems supporting horizontal features/services. With the Megaco/H.248 approach, since new features and services are developed and deployed on network-based servers near the network edge (on the Media Gateway Controllers (MGC)), mass software downloads to the large numbers of diverse devices out there is not necessary to introduce the new feature, generic rather than device-specific development tools can be used, and there is no need to "upgrade" end devices over time to add memory etc since the device itself is unchanged. Since the MGC acts as a proxy for the end devices (slightly different sense than SIP usage here), its still fundamentally a SIP network, operating in conjunction with Megaco/H.248-based master/slave control underneath -- the two are orthogonal, not in competition. Cost is a diminishing issue, but cost of a master/slave type system will always be lower than for peer-peer type approach since the end device does not need to carry the more complex peer protocol logic, implement features and feature interactions locally, and does not locally implement the associated user interface either (just the widgets to drive the UI). Size of the specific protocol stack itself is much less of an issue than the associated implementation logic. Hope that helps, Peter Blatherwick -----Original Message----- From: Dvir Oren [mailto:dvir@lucidvon.com] Sent: Saturday, September 30, 2000 09:33 To: farhan Cc: SIP Subject: [SIP] distributed sip farhan writes ("[SIP] distributed sip"): > We will at this stage have a distributed SIP wherein, the actual endpoints > of a sip call are slave units of a central control unit and the control unit > in turn is sip compliant (the slave units are not). What you are suggesting is in fact some SIP-X gateway, where 'X' is some proprietery protocol that is supposed to be smaller than SIP. The network between the SIP gateway and the end point units is not a SIP network, but an 'X network'. You might even want to hink of using MGCP, which is client-server based, where the end points are just dumb terminals. I'm suggesting this since it might help to use something that already has been done. On the other hand, since between the SIP gateway and the remote units there is a network, you'll have to handle all the possible errors in the network. Basically, this will mean re-inventing a protocol. So, why not use an existing one? I don't even see why you can't use SIP. > client is just a 48kb slave totally controlled by hotfoon.com. As a I don't think you need one of those giant C++/Java implementations that are megabytes in size. You can do with a small implementation of SIP. -- Dvir Oren Lucid VON Ltd. 9 Saloniki St., Tel-Aviv Israel Tel: +972 3 644 3038 Fax: +972 3 644 3039 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip ------_=_NextPart_001_01C02D46.1D710280 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [SIP] distributed sip

Megaco IP Phone MG provides such a solution for = master/slave controlled "dumb" appliances, which can easily = be used within a SIP-based network.  See http://www.ietf.org/internet-drafts/draft-ietf-megaco-= ipphone-03.txt.  Its currently in Last Call, for Informational = RFC, in Megaco WG. 

Before the religious war starts (experience shows it = will), I want to make it clear I very much like both SIP and the = Megaco/H.248 approach to end devices.  Both SIP-based and = Megaco/H.248-based end user appliances have strong roles in the real = world.  The two models are completely compatible within a system, = and are complementary in nature.  Properly implemented, the end = user actually can't tell the difference between the two approaches. =

While the peer-peer approach characterized by SIP is = truly excellent for SmartPhone type applications supporting stand-alone = features and services, the master/slave type approach characterized by = Megaco/H.248 affords major advantages for new feature/service = development and deployment, especially across large systems supporting = horizontal features/services.  With the Megaco/H.248 approach, = since new features and services are developed and deployed on = network-based servers near the network edge (on the Media Gateway = Controllers (MGC)), mass software downloads to the large numbers of = diverse devices out there is not necessary to introduce the new = feature, generic rather than device-specific development tools can be = used, and there is no need to "upgrade" end devices over time = to add memory etc since the device itself is unchanged.  Since the = MGC acts as a proxy for the end devices (slightly different sense than = SIP usage here), its still fundamentally a SIP network, operating in = conjunction with Megaco/H.248-based master/slave control underneath -- = the two are orthogonal, not in competition.  

Cost is a diminishing issue, but cost of a = master/slave type system will always be lower than for peer-peer type = approach since the end device does not need to carry the more complex = peer protocol logic, implement features and feature interactions = locally, and does not locally implement the associated user interface = either (just the widgets to drive the UI).  Size of the specific = protocol stack itself is much less of an issue than the associated = implementation logic. 

Hope that helps,
Peter Blatherwick

-----Original Message-----
From: Dvir Oren [mailto:dvir@lucidvon.com]
Sent: Saturday, September 30, 2000 09:33
To: farhan
Cc: SIP
Subject: [SIP] distributed sip


farhan writes ("[SIP] distributed = sip"):

> We will at this stage have a distributed SIP = wherein, the actual endpoints
> of a sip call are slave units of a central = control unit and the control unit
> in turn is sip compliant (the slave units are = not).

What you are suggesting is in fact some SIP-X = gateway, where 'X' is
some proprietery protocol that is supposed to be = smaller than SIP.
The network between the SIP gateway and the end = point units is not a
SIP network, but an 'X network'.  You might = even want to hink of using
MGCP, which is client-server based, where the end = points are just dumb
terminals.  I'm suggesting this since it might = help to use something
that already has been done.

On the other hand, since between the SIP gateway and = the remote units
there is a network, you'll have to handle all the = possible errors in
the network.  Basically, this will mean = re-inventing a protocol.  So,
why not use an existing one?

I don't even see why you can't use SIP. 

> client is just a 48kb slave totally controlled = by hotfoon.com. As a

I don't think you need one of those giant C++/Java = implementations
that are megabytes in size.  You can do with a = small implementation of
SIP.

--
Dvir = Oren           &n= bsp;   <dviro@lucidvon.com>
Lucid VON Ltd.     <http://www.lucidvon.com>
9 Saloniki = St.,        = Tel-Aviv       Israel
Tel:  +972 3 644 3038  Fax:  +972 3 = 644 3039

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip

------_=_NextPart_001_01C02D46.1D710280-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 3 12:29:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA16116 for ; Tue, 3 Oct 2000 12:29:04 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D379A44379; Tue, 3 Oct 2000 11:29:01 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from hotmail.com (f294.law7.hotmail.com [216.33.236.172]) by lists.bell-labs.com (Postfix) with ESMTP id B171044349 for ; Tue, 3 Oct 2000 11:28:12 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 3 Oct 2000 09:28:06 -0700 Received: from 164.164.6.34 by lw7fd.law7.hotmail.msn.com with HTTP; Tue, 03 Oct 2000 16:28:06 GMT X-Originating-IP: [164.164.6.34] From: "rahul pande" To: sip@lists.bell-labs.com Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 03 Oct 2000 16:28:06.0685 (UTC) FILETIME=[E90E74D0:01C02D56] Subject: [SIP] few comments on Drafts...... Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 03 Oct 2000 21:58:06 IST Hello Sir, The new drafts which are comming up are not abiding by the previous rfcs, for example in the draft draft-ietf-mmusic-sdp-atm-00.txt The general format of the media information line adapted for AAL2 applications is: m= ... where as the rfc2327 clearly defines that is not repetitive. In another, Megaco draft, few of the SDP mandatory headers have been made optional, which will not be inter operable with previous implemented SDPs. Sir, shouldn't we draft new things taking into consideration backward compatibility.... Thanking you, rahul _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. Share information about yourself, create your own public profile at http://profiles.msn.com. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 3 17:41:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA23854 for ; Tue, 3 Oct 2000 17:41:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E272544381; Tue, 3 Oct 2000 16:41:02 -0400 (EDT) Delivered-To: sip@share.research.bell-labs.com Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by lists.bell-labs.com (Postfix) with SMTP id 6455D44338 for ; Tue, 3 Oct 2000 14:40:06 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Tue Oct 3 15:38:37 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 89B8244380; Tue, 3 Oct 2000 15:25:28 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ans.ih.lucent.com (ans.ih.lucent.com [135.2.78.5]) by lists.bell-labs.com (Postfix) with SMTP id 4490D4437D for ; Tue, 3 Oct 2000 15:25:28 -0400 (EDT) Received: by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id OAA20233; Tue, 3 Oct 2000 14:25:23 -0500 Cc: sip@lists.bell-labs.com Received: from lucent.com by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id OAA20225; Tue, 3 Oct 2000 14:25:21 -0500 Message-ID: <39DA329A.938A35D5@lucent.com> From: "Vijay K. Gurbani" Reply-To: vkg@lucent.com Organization: Intelligent Network/Messaging Systems & Internet Software Group X-Mailer: Mozilla 4.61 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Jo Hornsby Original-CC: sip@lists.bell-labs.com Subject: Re: [SIP] Second branch parameter References: <000201c02d44$c0b00100$4e34c3c1@ubiquity.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 03 Oct 2000 14:25:14 -0500 Content-Transfer-Encoding: 7bit Henning/Jonathan: Should we chop off the word "second" (vis-a-vis the branch parameter) from the definition of an isomorphic request, as Jo suggests? I am for it. For all its worth, I was confused on the initial reading of the definition and reconciliation of how the branch parameter is constructed. Comments? Jo Hornsby wrote: > vkg@lucent.com wrote: > > Justifiably, the updated definition of an "isomorphic" request now > > includes the "second" branch parameter of the topmost Via header. > > My problem is, how does one recognize the "second" branch parameter? > > The bis draft says that "...The [branch] token MUST be unique for > > each distinct request. The precise format of the token is > > implementation- defined. In order to be able to both detect loops > > and associate responses with the corresponding requests, the > > parameter SHOULD consist of two parts separable by implementation." > > (Section 6.46, August bis) > > > > Two questions: > > 1) should the SHOULD be changed to a MUST? > > 2) should the bis specify what the separator token is? If not, > > consider a proxy that gets the following SIP request: > > > > INVITE sip:vkg@iit.edu > > ... > > Via: SIP/2.0/UDP exp1.example.com;branch=a7c68feda6711e3efa55 > > Via: SIP/2.0/UDP sip.ih.lucent.com > > > > How does the proxy know which is the "second" branch parameter of > > the topmost Via if it does not know what the separator is? The > > bis examples show branch parameters being delimited by a "." (at > > least that's my interpretation of them). However, I am not > > comfortable parsing the branch token looking for a "." to figure > > out what the "second" branch parameter is. > > > > Am I missing something here, or is this a problem? > > I wouldn't perceive this as a problem, since the "second branch > parameter" is by definition part of the whole branch parameter, > thus you just use the whole branch parameter to distinguish. > > I don't see why the text bothers mentioning the "second part" > explicitly, however; might as well just strike the word "second" > from the definition of an Isomorphic Request. > > - Jo. - vijay -- Vijay K. Gurbani vkg@lucent.com vkg@research.bell-labs.com vkg@acm.org Internet Software Group/Intelligent Network and Messaging Systems Lucent Technologies/Bell Labs Innovations, 263 Shuman Blvd, Rm 1A-413 Naperville, Illinois 60566 Voice: +1 630 224 0216 Fax: +1 630 713 0184 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 3 17:42:44 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA23878 for ; Tue, 3 Oct 2000 17:42:44 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C8F4044390; Tue, 3 Oct 2000 16:41:06 -0400 (EDT) Delivered-To: sip@share.research.bell-labs.com Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by lists.bell-labs.com (Postfix) with SMTP id 8ABF944338 for ; Tue, 3 Oct 2000 14:58:05 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Tue Oct 3 15:57:34 EDT 2000 Received: by lists.bell-labs.com (Postfix) id BA42644380; Tue, 3 Oct 2000 15:44:24 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ans.ih.lucent.com (ans.ih.lucent.com [135.2.78.5]) by lists.bell-labs.com (Postfix) with SMTP id 6DC354437D for ; Tue, 3 Oct 2000 15:44:24 -0400 (EDT) Received: by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id OAA26760; Tue, 3 Oct 2000 14:44:19 -0500 From: vkg@lucent.com (Vijay K Gurbani) Cc: vkg@lucent.com Received: by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id OAA26725; Tue, 3 Oct 2000 14:44:19 -0500 Message-Id: <200010031944.OAA26725@ans.ih.lucent.com> Original-From: vkg@ans.ih.lucent.com (Vijay K Gurbani) To: sip@lists.bell-labs.com Original-Cc: vkg@ans.ih.lucent.com Subject: [SIP] Error in Via received BNF? Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 3 Oct 2000 14:44:19 -0500 Hi: The Sept 4th 2000 BNF, Section 6.46.2, says that, "...If and only if the source address and port differ from the sent-by address, the proxy also includes the source port in the received parameter." The BNF of the received parameter in Section 6.46.6 is: via-received = "received" = host Given the statement in 6.46.2, shouldn't it be: via-received = "received" = host[":"port] Comments? - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} IN Architecture and Internet Software Group Lucent Technologies/Bell Labs Innovations 263 Shuman Blvd., Rm 1A-413 Naperville, Illinois 60566 Voice: +1 630 224 0216 Fax: +1 630 713 0184 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 3 17:44:45 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA23899 for ; Tue, 3 Oct 2000 17:44:44 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 58E70443AA; Tue, 3 Oct 2000 16:43:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id BFDBE44397 for ; Tue, 3 Oct 2000 16:42:34 -0400 (EDT) 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 RAA15407; Tue, 3 Oct 2000 17:42:26 -0400 (EDT) Message-ID: <39DA52C3.4B1CE717@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Vijay K Gurbani Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Error in Via received BNF? References: <200010031944.OAA26725@ans.ih.lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 03 Oct 2000 17:42:27 -0400 Content-Transfer-Encoding: 7bit Vijay K Gurbani wrote: > > Hi: > > The Sept 4th 2000 BNF, Section 6.46.2, says that, "...If and only if the > source address and port differ from the sent-by address, the proxy also > includes the source port in the received parameter." This was an over-enthusiastic addition to the text, which will disappear again (since it didn't help and isn't backward compatible). Thus, no need to change the text. > > The BNF of the received parameter in Section 6.46.6 is: > > via-received = "received" = host > > Given the statement in 6.46.2, shouldn't it be: > > via-received = "received" = host[":"port] > > Comments? > > - vijay > -- > Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} > IN Architecture and Internet Software Group > Lucent Technologies/Bell Labs Innovations 263 Shuman Blvd., Rm 1A-413 > Naperville, Illinois 60566 Voice: +1 630 224 0216 Fax: +1 630 713 0184 > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 3 18:37:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA24352 for ; Tue, 3 Oct 2000 18:37:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id BE01444366; Tue, 3 Oct 2000 17:37:01 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mailsrv02.multitude.com (mailsrv02.firetalk.com [204.178.116.251]) by lists.bell-labs.com (Postfix) with ESMTP id 667A244338 for ; Tue, 3 Oct 2000 17:36:02 -0400 (EDT) Received: from sbarber2k (s242.firetalk.com [204.178.116.242]) by mailsrv02.multitude.com (Rockliffe SMTPRA 3.4.2) with SMTP id ; Tue, 3 Oct 2000 15:33:56 -0700 From: "Simon Barber" To: "Jonathan Rosenberg" , , Subject: RE: [SIP] SIP through firewalls without SIP proxy Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0023_01C02D4F.E125EFC0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 3 Oct 2000 15:37:46 -0700 This is a multi-part message in MIME format. ------=_NextPart_000_0023_01C02D4F.E125EFC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit I'm proposing a generic method to transport socket API calls (these may apply to many sockets) through a single connection. RTP media would be transported by sending messages corresponding to send and recv API calls. All these messages would go through the same single connection. This connection might be a TCP stream or an HTTP stream. Simon > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Monday, October 02, 2000 10:01 PM > To: 'Simon Barber'; Jonathan Rosenberg; 'Jon.Peterson@Level3.com'; > 'sip@lists.bell-labs.com' > Subject: RE: [SIP] SIP through firewalls without SIP proxy > > > > > > > -----Original Message----- > > From: Simon Barber [mailto:simon@firetalk.com] > > Sent: Monday, October 02, 2000 2:01 PM > > To: Jonathan Rosenberg; Jon.Peterson@Level3.com; > > sip@lists.bell-labs.com > > Subject: RE: [SIP] SIP through firewalls without SIP proxy > > > > > > I am proposing a protocol that runs on any character stream > > between the > > client (behind the firewall) and a server (outside the > > firewall), and that > > does not need any special arrangements made on the firewall. The best > > example would be using HTTP to communicate between the client and the > > server - this channel is the most commonly available channel > > on the internet > > (except e-mail), and may pass through proxys and firewalls between the > > client and server. > > > > The key difference between this and foglamps or SOCKS is that > > this does not > > require the firewall administrator's permission, or even > > knowledge. For this > > to work UDP and TCP data and control must all pass over the > > same connection. > > But they don't; the RTP is carried on a separate port from the signaling, > which is one of the main problems. How would you handle this case? > > -Jonathan R. > --- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > http://www.dynamicsoft.com > ------=_NextPart_000_0023_01C02D4F.E125EFC0 Content-Type: text/x-vcard; name="Simon Barber.vcf" Content-Disposition: attachment; filename="Simon Barber.vcf" Content-Transfer-Encoding: quoted-printable BEGIN:VCARD VERSION:2.1 N:Barber;Simon FN:Simon Barber ORG:Firetalk Communications, Inc. TEL;WORK;VOICE:(650) 636-1924 TEL;CELL;VOICE:(650) 743-1919 ADR;WORK:;;5000 Shoreline Court, Suite 200;South San = Francisco;CA;94080;United States of America LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:5000 Shoreline Court, Suite = 200=3D0D=3D0ASouth San Francisco, CA 94080=3D0D=3D0AUnit=3D ed States of America URL:http://www.firetalk.com URL:http://www.firetalk.com EMAIL;PREF;INTERNET:simon@firetalk.com REV:20000914T193921Z END:VCARD ------=_NextPart_000_0023_01C02D4F.E125EFC0-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 3 19:06:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA24588 for ; Tue, 3 Oct 2000 19:06:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6BDF544366; Tue, 3 Oct 2000 18:06:01 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ertpg14e1.nortelnetworks.com (ertpg14e1.nortelnetworks.com [47.234.0.35]) by lists.bell-labs.com (Postfix) with ESMTP id 7C17944338 for ; Tue, 3 Oct 2000 18:05:16 -0400 (EDT) Received: from zsc4c002.corpwest.baynetworks.com by ertpg14e1.nortelnetworks.com; Tue, 3 Oct 2000 19:04:30 -0400 Received: from zsc4c006.corpwest.baynetworks.com ([134.177.2.153]) by zsc4c002.corpwest.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id T3GDX0AJ; Tue, 3 Oct 2000 16:04:28 -0700 Received: from long-pc.us.nortel.com (long-pc.corpwest.baynetworks.com [134.177.44.60]) by zsc4c006.corpwest.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id T7ZMV1V6; Tue, 3 Oct 2000 16:04:26 -0700 Message-Id: <4.2.2.20001003160256.00bd5730@zsc4c006.corpwest.baynetworks.com> X-Sender: long@zsc4c006.corpwest.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 To: sip From: "Lyndon Ong" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [SIP] SIP ISUP MIME draft Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 03 Oct 2000 16:05:38 -0700 Folks, I have not seen any comments on the list regarding the reissued SIP ISUP MIME draft (http://www.ietf.org/internet-drafts/draft-ietf-sip-isup-mime-04.txt), although I've gotten some minor ones offline. Are there any comments or questions on the draft? Thanks, L. Ong _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 3 19:07:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA24599 for ; Tue, 3 Oct 2000 19:07:04 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E360F44397; Tue, 3 Oct 2000 18:07:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mailsrv02.multitude.com (mailsrv02.firetalk.com [204.178.116.251]) by lists.bell-labs.com (Postfix) with ESMTP id E736C44338 for ; Tue, 3 Oct 2000 18:06:54 -0400 (EDT) Received: from sbarber2k (s242.firetalk.com [204.178.116.242]) by mailsrv02.multitude.com (Rockliffe SMTPRA 3.4.2) with SMTP id ; Tue, 3 Oct 2000 16:04:48 -0700 From: "Simon Barber" To: "Jonathan Rosenberg" , "'hammer michael'" , "Doug Harbert" Cc: "'Tom-PT Taylor'" , "'sip'" Subject: RE: [SIP] Re-direct of Media During Ringing Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0035_01C02D54.3182EAA0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <000401c02c30$177e9d40$e69ffea9@dynamicsoft.com> Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 3 Oct 2000 16:08:39 -0700 This is a multi-part message in MIME format. ------=_NextPart_000_0035_01C02D54.3182EAA0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Another scenario where re-invite during ringing is needed: I am a user connected to the internet by a modem. My bandwidth is limited, so I can only receive one stream at a time. I am talking to a user with a pre-established session. I want to consult with another person. I place my established session on-hold. I call the new person. I hear an announcement through early media - 'you are in a queue and will be answered in 20 minutes' I want to return to talking to the first person while I wait for the second call to be answered. Because I am on a modem I must put the new call on hold (I don't have the bandwidth to receive media from 2 sources). Here I need to send a re-invite during early media, to put the media on hold. Not allowing re-invite during ringing is an artificial restriction imposed by a design flaw in the SIP protocol. Simon Barber. > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Sunday, October 01, 2000 10:18 PM > To: 'hammer michael'; Doug Harbert; Simon Barber > Cc: Jonathan Rosenberg; 'Tom-PT Taylor'; 'sip' > Subject: RE: [SIP] Re-direct of Media During Ringing > > > I agree that the notion of the caller delivering all kinds of media to the > called party, before the call is "answered", worries me a lot. > Particularly > if you want the called party to modify some aspect of the "early media > session". Security is definitely a problem here. You can argue that the > called party shouldn't return a 183 with SDP containing a > sendrecv parameter > if it didn't know the caller. But, this imposes an unreasonable burden on > the called party. > > I think the problem is related to people's coupling of a session with > answering a physical telephone device. To me, the example with the alarm > clock is clear - a session has most definitely been started. > > Allowing re-invites before a session is established is > complicated. Take the > simple case of a normal phone call. Does the UAS need to collect all these > invites, and then answer them all once it accepts the call? If it accepts, > does it send a 200 OK to the first, then reject the rest, 200 OK to all of > them? WHat happens if one of those transactions doesn't complete? The > primary complexity is really holding on to those reinvites, and then > responding to all when the call is answered. This is quite a pain. > > -Jonathan R. > > --- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > > -----Original Message----- > > From: hammer michael [mailto:mhammer@cisco.com] > > Sent: Friday, September 29, 2000 1:27 PM > > To: Doug Harbert; Simon Barber > > Cc: Jonathan Rosenberg; 'Tom-PT Taylor'; 'sip' > > Subject: Re: [SIP] Re-direct of Media During Ringing > > > > > > Simon, > > > > I would not rely on being able to identify the calling party > > (long live > > anonymity???). As I have noticed on the telephone network, > > telemarketers > > are very good at not identifying themselves ("out of area" on > > my caller id > > box) and can be expected to do the same on the net. > > > > Mike > > > > > > At 05:59 PM 09/28/2000 -0600, Doug Harbert wrote: > > >Simon Barber wrote: > > > > > > > > > Example service: > > > > > > > > > > > > Morning alarm clock, calls me on my SIP phone, > > connecting early inbound > > > > > > media first to a quiet internet radio station (the phone plays > > > > > this on its > > > > > > speaker, instead of ringing), then if unanswered after 2 > > > > > minutes, re-invite > > > > > > the early media to a thrash metal sample from an RTSP server. > > > > > When the call > > > > > > is answered connect me to a message telling me what's > > on my to-do list > > > > > > today, and reminding me it's my girlfriend's birthday. > > > > > > > > > > > > > > > > The applications you describe here sound like sessions. In fact, > > > > > any time one > > > > > party delivers media to another party, there is a session and > > > > > there should be > > > > > explicit agreement between parties to form this session. Perhaps > > > > > what is needed > > > > > > > > By this notion there should be no re-invite at all - > > changing the media at > > > > all would be counted as a new session, requiring the user > > explicitly accept > > > > the new session. I do not accept this at all. > > > > > >No, re-INVITE during an established session is ok. The above > > example indicates > > >a re-INVITE before the session has been established. > > Possibly a better method > > >would be to CANCEL the current INVITE and issue a new INVITE > > to establish a > > >different session. > > > > > > > > > > > > > > > > > > > > > here is a way for your sip phone to automatically answer calls > > > > > from your alarm > > > > > clock, or for your pager to automatically answer calls and > > > > > perform the page. > > > > > These devices could modify their behaviors depending > > upon the application > > > > > requested for the session, low level alarm, high level > > alarm, page. > > > > > > > > Automatically answering calls is different from > > delivering media before the > > > > answer. If you automatically answer a call there is no > > possibility for the > > > > callee to later really answer the call. For example the > > alarm clock servive > > > > I proposed would not be possible - the service is > > terminated by the callee > > > > answering the call, listening to a message, and hanging up. > > > > > > > > > >If your SIP phone has automatically answered the call > > because it recognizes > > >that it is from your alarm clock, then the session is > > established. There is no > > >need to tear it down just because a person wants to talk. > > Your phone as an > > >intelligent endpoint could recognize the off hook, and if > > necessary issue a > > >re-INVITE to modify the session parameters for the voice call. > > > > > > > > > > > > > > > > > > > > The recipient of the call or his/her agents (phones, pagers,...) > > > > > must have the > > > > > authority to decide whether or not to accept the session, and > > > > > receive media. > > > > > > > > > > > > > Certainly the recipient of the call should have good > > control over what > > > > sessions they accept, and these control should include > > controls over > > > > sessions delivering media before the call is answered. > > These controls > > > may be > > > > partly provided in the UA and partly in the proxy servers > > that forward the > > > > call to the user's UA. > > > > > > > > Simon Barber > > > > > >Delivery of media to the callee before the session has been > > completely setup > > >worries me somehow (I picture telemarketers sending their > > spiel into my living > > >room). But I suppose that since the callee can accept or > > reject this media via > > >the SDP in the 183 then that allows sufficient control. This > > may be useful if > > >the endpoint can recognize the caller and allow or disallow > > receipt of the > > >media according to who is calling. Though if the SIP phone > > can do this, it > > >should be able to accept the call for call screening > > purposes, and allow the > > >callee to pick it up if he/she wants to. > > > > > >Doug Harbert > > > > > > > > >_______________________________________________ > > >SIP mailing list > > >SIP@lists.bell-labs.com > > >http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > ------=_NextPart_000_0035_01C02D54.3182EAA0 Content-Type: text/x-vcard; name="Simon Barber.vcf" Content-Disposition: attachment; filename="Simon Barber.vcf" Content-Transfer-Encoding: quoted-printable BEGIN:VCARD VERSION:2.1 N:Barber;Simon FN:Simon Barber ORG:Firetalk Communications, Inc. TEL;WORK;VOICE:(650) 636-1924 TEL;CELL;VOICE:(650) 743-1919 ADR;WORK:;;5000 Shoreline Court, Suite 200;South San = Francisco;CA;94080;United States of America LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:5000 Shoreline Court, Suite = 200=3D0D=3D0ASouth San Francisco, CA 94080=3D0D=3D0AUnit=3D ed States of America URL:http://www.firetalk.com URL:http://www.firetalk.com EMAIL;PREF;INTERNET:simon@firetalk.com REV:20000914T193921Z END:VCARD ------=_NextPart_000_0035_01C02D54.3182EAA0-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 3 19:19:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA24703 for ; Tue, 3 Oct 2000 19:19:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 99C1E4439E; Tue, 3 Oct 2000 18:19:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 7D0E64439D for ; Tue, 3 Oct 2000 18:18:33 -0400 (EDT) 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 TAA22834; Tue, 3 Oct 2000 19:18:12 -0400 (EDT) Message-ID: <39DA6934.5BC53A43@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Simon Barber Cc: Jonathan Rosenberg , "'hammer michael'" , Doug Harbert , "'Tom-PT Taylor'" , "'sip'" Subject: Re: [SIP] Re-direct of Media During Ringing References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 03 Oct 2000 19:18:12 -0400 Content-Transfer-Encoding: 7bit The problem is treating waiting in queue as early media - it's a session and should be treated as such. It's a call when you call the airline, say, even with steamphones. As I said earlier, the whole early media stuff is a kludge. The less we use it, the better. Trying to fix the kludge just adds layers upon layers of double complexity, once for "real" sessions and once for "pseudo" sessions, for no good reason. With a real VoIP system (as opposed to one that tries to imitate the analog phone system), you wouldn't get a voice stream for queueing, it would just be a 18x message, with no bandwidth difficulties. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 3 20:57:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA25382 for ; Tue, 3 Oct 2000 20:57:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 508844438D; Tue, 3 Oct 2000 19:57:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from aphrodite.systems.cfer.com (unknown [198.78.16.4]) by lists.bell-labs.com (Postfix) with ESMTP id 60C0E4437D for ; Tue, 3 Oct 2000 19:56:46 -0400 (EDT) Received: from voyanttech.com (dough-pc [192.168.58.41]) by aphrodite.systems.cfer.com (8.8.8+Sun/8.8.8) with ESMTP id SAA28689; Tue, 3 Oct 2000 18:54:15 -0600 (MDT) Message-ID: <39DA8104.1B407F80@voyanttech.com> From: Doug Harbert X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: Simon Barber Cc: Jonathan Rosenberg , "'hammer michael'" , "'Tom-PT Taylor'" , "'sip'" Subject: Re: [SIP] Re-direct of Media During Ringing References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 03 Oct 2000 18:59:48 -0600 Content-Transfer-Encoding: 7bit Simon Barber wrote: > Another scenario where re-invite during ringing is needed: > > I am a user connected to the internet by a modem. My bandwidth is limited, > so I can only receive one stream at a time. > > I am talking to a user with a pre-established session. > > I want to consult with another person. > > I place my established session on-hold. > > I call the new person. > > I hear an announcement through early media - 'you are in a queue and will be > answered in 20 minutes' > > I want to return to talking to the first person while I wait for the second > call to be answered. Because I am on a modem I must put the new call on hold > (I don't have the bandwidth to receive media from 2 sources). Here I need to > send a re-invite during early media, to put the media on hold. > > Not allowing re-invite during ringing is an artificial restriction imposed > by a design flaw in the SIP protocol. > > Simon Barber. > > > -----Original Message----- > > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > Sent: Sunday, October 01, 2000 10:18 PM > > To: 'hammer michael'; Doug Harbert; Simon Barber > > Cc: Jonathan Rosenberg; 'Tom-PT Taylor'; 'sip' > > Subject: RE: [SIP] Re-direct of Media During Ringing > > > > > > I agree that the notion of the caller delivering all kinds of media to the > > called party, before the call is "answered", worries me a lot. > > Particularly > > if you want the called party to modify some aspect of the "early media > > session". Security is definitely a problem here. You can argue that the > > called party shouldn't return a 183 with SDP containing a > > sendrecv parameter > > if it didn't know the caller. But, this imposes an unreasonable burden on > > the called party. > > > > I think the problem is related to people's coupling of a session with > > answering a physical telephone device. To me, the example with the alarm > > clock is clear - a session has most definitely been started. > > > > Allowing re-invites before a session is established is > > complicated. Take the > > simple case of a normal phone call. Does the UAS need to collect all these > > invites, and then answer them all once it accepts the call? If it accepts, > > does it send a 200 OK to the first, then reject the rest, 200 OK to all of > > them? WHat happens if one of those transactions doesn't complete? The > > primary complexity is really holding on to those reinvites, and then > > responding to all when the call is answered. This is quite a pain. > > > > -Jonathan R. > > > > --- > > Jonathan D. Rosenberg 72 Eagle Rock Ave. > > Chief Scientist First Floor > > dynamicsoft East Hanover, NJ 07936 > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > > http://www.dynamicsoft.com > > > > > -----Original Message----- > > > From: hammer michael [mailto:mhammer@cisco.com] > > > Sent: Friday, September 29, 2000 1:27 PM > > > To: Doug Harbert; Simon Barber > > > Cc: Jonathan Rosenberg; 'Tom-PT Taylor'; 'sip' > > > Subject: Re: [SIP] Re-direct of Media During Ringing > > > > > > > > > Simon, > > > > > > I would not rely on being able to identify the calling party > > > (long live > > > anonymity???). As I have noticed on the telephone network, > > > telemarketers > > > are very good at not identifying themselves ("out of area" on > > > my caller id > > > box) and can be expected to do the same on the net. > > > > > > Mike > > > > > > > > > At 05:59 PM 09/28/2000 -0600, Doug Harbert wrote: > > > >Simon Barber wrote: > > > > > > > > > > > Example service: > > > > > > > > > > > > > > Morning alarm clock, calls me on my SIP phone, > > > connecting early inbound > > > > > > > media first to a quiet internet radio station (the phone plays > > > > > > this on its > > > > > > > speaker, instead of ringing), then if unanswered after 2 > > > > > > minutes, re-invite > > > > > > > the early media to a thrash metal sample from an RTSP server. > > > > > > When the call > > > > > > > is answered connect me to a message telling me what's > > > on my to-do list > > > > > > > today, and reminding me it's my girlfriend's birthday. > > > > > > > > > > > > > > > > > > > The applications you describe here sound like sessions. In fact, > > > > > > any time one > > > > > > party delivers media to another party, there is a session and > > > > > > there should be > > > > > > explicit agreement between parties to form this session. Perhaps > > > > > > what is needed > > > > > > > > > > By this notion there should be no re-invite at all - > > > changing the media at > > > > > all would be counted as a new session, requiring the user > > > explicitly accept > > > > > the new session. I do not accept this at all. > > > > > > > >No, re-INVITE during an established session is ok. The above > > > example indicates > > > >a re-INVITE before the session has been established. > > > Possibly a better method > > > >would be to CANCEL the current INVITE and issue a new INVITE > > > to establish a > > > >different session. > > > > > > > > > > > > > > > > > > > > > > > > > > here is a way for your sip phone to automatically answer calls > > > > > > from your alarm > > > > > > clock, or for your pager to automatically answer calls and > > > > > > perform the page. > > > > > > These devices could modify their behaviors depending > > > upon the application > > > > > > requested for the session, low level alarm, high level > > > alarm, page. > > > > > > > > > > Automatically answering calls is different from > > > delivering media before the > > > > > answer. If you automatically answer a call there is no > > > possibility for the > > > > > callee to later really answer the call. For example the > > > alarm clock servive > > > > > I proposed would not be possible - the service is > > > terminated by the callee > > > > > answering the call, listening to a message, and hanging up. > > > > > > > > > > > > >If your SIP phone has automatically answered the call > > > because it recognizes > > > >that it is from your alarm clock, then the session is > > > established. There is no > > > >need to tear it down just because a person wants to talk. > > > Your phone as an > > > >intelligent endpoint could recognize the off hook, and if > > > necessary issue a > > > >re-INVITE to modify the session parameters for the voice call. > > > > > > > > > > > > > > > > > > > > > > > > > The recipient of the call or his/her agents (phones, pagers,...) > > > > > > must have the > > > > > > authority to decide whether or not to accept the session, and > > > > > > receive media. > > > > > > > > > > > > > > > > Certainly the recipient of the call should have good > > > control over what > > > > > sessions they accept, and these control should include > > > controls over > > > > > sessions delivering media before the call is answered. > > > These controls > > > > may be > > > > > partly provided in the UA and partly in the proxy servers > > > that forward the > > > > > call to the user's UA. > > > > > > > > > > Simon Barber > > > > > > > >Delivery of media to the callee before the session has been > > > completely setup > > > >worries me somehow (I picture telemarketers sending their > > > spiel into my living > > > >room). But I suppose that since the callee can accept or > > > reject this media via > > > >the SDP in the 183 then that allows sufficient control. This > > > may be useful if > > > >the endpoint can recognize the caller and allow or disallow > > > receipt of the > > > >media according to who is calling. Though if the SIP phone > > > can do this, it > > > >should be able to accept the call for call screening > > > purposes, and allow the > > > >callee to pick it up if he/she wants to. > > > > > > > >Doug Harbert > > > > > > > > > > > >_______________________________________________ > > > >SIP mailing list > > > >SIP@lists.bell-labs.com > > > >http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > > > Simon: In this example, you need not receive a media stream to know that you are in a queue, you should receive a 182 response which may give further details. However, if you do wish to hear the recorded message, you could after listening to the message, cancel the initial invite and issue a new invite, this time refusing the early media stream. You can accept the stream when the farend answers. Another possible way to handle the above example would be for the farend to actually answer the call, thus establishing a session. Then either side could issue a reinvite to place the other side on hold. The session is established but no media is being transferred. I still believe that any time you have media flowing, there should be an established session. This way, both parties have some ability to modify the media parameters. In the above example, if the farend didn't have sufficient bandwidth to produce the stream for 20 minutes, it's only option would be to refuse the call. It could not issue a reinvite prior to answering the call. Doug Harbert _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 4 02:17:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA12663 for ; Wed, 4 Oct 2000 02:17:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 15C2944356; Wed, 4 Oct 2000 01:17:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sumo.vocaltec.co.il (sumo.vocaltec.co.il [199.203.72.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0CB9D4433F for ; Wed, 4 Oct 2000 01:16:34 -0400 (EDT) Received: from ilnimo.vocaltec.co.il (ilnimo.vocaltec.co.il [194.90.71.135]) by sumo.vocaltec.co.il (8.9.3/8.9.3) with ESMTP id JAA13744 for ; Wed, 4 Oct 2000 09:19:36 +0200 (IST) From: Joshua_Fox@vocaltec.com To: sip@lists.bell-labs.com X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: X-MIMETrack: Serialize by Router on ILNimo/Vocaltec_Comm(Release 5.0.3 (Intl)|21 March 2000) at 10/04/2000 09:16:21 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [SIP] centralized vs. decentralized architectures Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 4 Oct 2000 09:16:16 +0200 I have recently posed some questions about centralized vs. decentralized architectures and SIP. One issue is that there is no escape from requiring the user to register an ID or to generate one. The need for user identity, as opposed to true anonymity, is one type of decentralization. Another issue is that SIP-based systems often use distributed logic for storing session state. On the other hand, the "center" (the server) can store session state using the back-to-back user-agent design. In that case, the server serves as a proxy in a sense (not the usual "SIP Proxy Server sense" ) for the clients, communicating with them by another protocol. These seem to be part of the usual architecture for SIP-based systems. This architecture puts the intelligence on the edge, not the center. There are reasons for centralization of logic, such as (1) the typical benefits of a thin client (2) ACDs or other central decision-makers. Nothing stops us from adopting a more centralized architecture with SIP, even if it's unusual. Joshua Fox Senior Architect Surf&Call Network Services _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 4 07:01:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA15137 for ; Wed, 4 Oct 2000 07:01:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id AD77D44356; Wed, 4 Oct 2000 06:01:01 -0400 (EDT) Delivered-To: sip@share.research.bell-labs.com Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by lists.bell-labs.com (Postfix) with SMTP id 76BB34433F for ; Wed, 4 Oct 2000 06:00:04 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Wed Oct 4 06:59:31 EDT 2000 Received: by lists.bell-labs.com (Postfix) id DBB7D44380; Wed, 4 Oct 2000 06:46:21 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from uk0006exch001h.wins.lucent.com (uk0006exch001h.uk.lucent.com [135.86.160.150]) by lists.bell-labs.com (Postfix) with ESMTP id 577A74437D for ; Wed, 4 Oct 2000 06:46:21 -0400 (EDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id ; Wed, 4 Oct 2000 10:42:08 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB00BCFAC@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: Simon Barber , "'Henning Schulzrinne'" Cc: Jonathan Rosenberg , "'hammer michael'" , Doug Harbert , "'Tom-PT Taylor'" , "'sip'" Subject: RE: [SIP] Re-direct of Media During Ringing MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 4 Oct 2000 10:42:07 +0100 This all appears to be focussing back to the old ISDN/B-ISDN discussions of what does answer really mean. Essentially there are several concepts that need to be designated, and a clear statement needs to be made about which protocol mechanism indicates which. They are: i) indication to the remote user of the session request ii) remote user acceptance of the session iii) start of charging for the session iv indication to the remote user of a media stream request v remote user acceptance of the media stream vi) start of charging for the media stream In the PSTN these boil down to two events, although with IN based queuing mechanisms, this is not totally satisfactory. In SIP they definitely do not all occur at the same time, and can need separate protocol mechanism for each. Some of these appearing at separate times will occur in more scenarios than others. The kludge is happening because the concepts have not been clearly separated. Keith Drage Keith Drage Lucent Technologies Tel: +44 1793 776249 Email: drage@lucent.com > ---------- > From: Henning Schulzrinne[SMTP:schulzrinne@cs.columbia.edu] > Sent: 04 October 2000 0:18 > To: Simon Barber > Cc: Jonathan Rosenberg; 'hammer michael'; Doug Harbert; 'Tom-PT Taylor'; > 'sip' > Subject: Re: [SIP] Re-direct of Media During Ringing > > The problem is treating waiting in queue as early media - it's a session > and should be treated as such. It's a call when you call the airline, > say, even with steamphones. As I said earlier, the whole early media > stuff is a kludge. The less we use it, the better. Trying to fix the > kludge just adds layers upon layers of double complexity, once for > "real" sessions and once for "pseudo" sessions, for no good reason. With > a real VoIP system (as opposed to one that tries to imitate the analog > phone system), you wouldn't get a voice stream for queueing, it would > just be a 18x message, with no bandwidth difficulties. > -- > Henning Schulzrinne http://www.cs.columbia.edu/~hgs > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 4 07:19:00 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA15392 for ; Wed, 4 Oct 2000 07:19:00 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 16CF644356; Wed, 4 Oct 2000 06:19:01 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from drago1.ubiquity.net (unknown [194.202.146.92]) by lists.bell-labs.com (Postfix) with SMTP id F018B4433F for ; Wed, 4 Oct 2000 06:18:49 -0400 (EDT) Received: from gecko.ubiquity.co.uk by drago1.ubiquity.net via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 4 Oct 2000 11:19:11 UT Received: from jundery.ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id MAA23499; Wed, 4 Oct 2000 12:17:08 +0100 (BST) Received: from localhost (jundery@localhost) by jundery.ubiquity.net (8.9.3/8.9.3) with ESMTP id MAA01756; Wed, 4 Oct 2000 12:17:08 GMT X-Authentication-Warning: jundery.ubiquity.net: jundery owned process doing -bs From: James Undery To: Henning Schulzrinne Cc: sip@lists.bell-labs.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [SIP] Registering non-SIP URIs Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 4 Oct 2000 12:17:08 +0000 (GMT) Hi, I've just been re-reading the latest draft and have noted an important part of registering non-SIP URIs is only mentioned in passing, section 6.14 the paragraph about 'REGISTER requests' says "Other [non-SIP] URI schemes have no expiration times." This would be good to mention in section 4.2.6 along with the rest of the REGISTER details. James Undery _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 4 07:53:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA16227 for ; Wed, 4 Oct 2000 07:53:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id DFB4744356; Wed, 4 Oct 2000 06:53:01 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by lists.bell-labs.com (Postfix) with ESMTP id 3215B44356 for ; Wed, 4 Oct 2000 06:33:29 -0400 (EDT) Received: from mr5.exu.ericsson.se. (mr5u3.ericy.com [208.237.135.124]) by imr1.ericy.com (8.9.3/8.9.3) with ESMTP id GAA26996; Wed, 4 Oct 2000 06:33:22 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr5.exu.ericsson.se. (8.10.2/8.10.2) with ESMTP id e94BW0818849; Wed, 4 Oct 2000 06:32:00 -0500 (CDT) Received: from ericsson.com (kipe195.eraj.ericsson.se [147.214.68.195]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id GAA15855; Wed, 4 Oct 2000 06:33:19 -0500 (CDT) Message-ID: <39DB155A.46A89E43@ericsson.com> From: Sean Olson Organization: Ericsson Inc. X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: James Undery Cc: Henning Schulzrinne , sip@lists.bell-labs.com Subject: Re: [SIP] Registering non-SIP URIs References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 04 Oct 2000 13:32:42 +0200 Content-Transfer-Encoding: 7bit While we're on the topic, I'm curious about the statement in this section "If neither of these mechanisms is used, SIP URIs are assumed to expire in one hour" Why the arbitrary "one hour"? Shouldn't this be up to the registrar and conveyed in the Expires: header in the 200 OK response? -- Sean Olson James Undery wrote: > Hi, > I've just been re-reading the latest draft and have noted an > important part of registering non-SIP URIs is only mentioned in passing, > section 6.14 the paragraph about 'REGISTER requests' says > > "Other [non-SIP] URI schemes have no expiration times." > > This would be good to mention in section 4.2.6 along with the rest of the > REGISTER details. > > James Undery > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 4 08:48:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA17896 for ; Wed, 4 Oct 2000 08:48:02 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 746B844356; Wed, 4 Oct 2000 07:48:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from qhars002.nortel.com (qhars002.NortelNetworks.com [192.100.101.19]) by lists.bell-labs.com (Postfix) with ESMTP id CB69E4433F for ; Wed, 4 Oct 2000 07:47:26 -0400 (EDT) Received: from zhard00m.europe.nortel.com (actually zhard00m) by qhars002.nortel.com; Wed, 4 Oct 2000 13:46:44 +0100 Received: by zhard00m.europe.nortel.com with Internet Mail Service (5.5.2652.35) id <4CDTLC2J>; Wed, 4 Oct 2000 13:46:39 +0100 Message-ID: <61ABD11436FED21192440000F81F3E360304C2E6@nwcwi1a.europe.nortel.com> From: "Mark Watson" To: "'Drage, Keith (Keith)'" , Simon Barber , "'Henning Schulzrinne'" Cc: Jonathan Rosenberg , "'hammer michael'" , Doug Harbert , "Tom-PT Taylor" , "'sip'" Subject: RE: [SIP] Re-direct of Media During Ringing MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C02E01.22B02CB0" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 4 Oct 2000 13:46:37 +0100 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_01C02E01.22B02CB0 Content-Type: text/plain; charset="ISO-8859-1" Added to this we have the concept of a preliminary one way media stream (from called party to calling party) which is not charged for - i.e. alerting or queueing phase. I guess this has been modelled as 'early media' which occurs before confirmation of the session, whereas arguably this should be something which is considered to take place after establishment of the session, but before charging begins. Is the problem the fact that session establishment has been equated with called party answer ? Regards, Mark Watson Nortel Networks -----Original Message----- From: Drage, Keith (Keith) [mailto:drage@lucent.com] Sent: 04 October 2000 10:42 To: Simon Barber; 'Henning Schulzrinne' Cc: Jonathan Rosenberg; 'hammer michael'; Doug Harbert; Taylor, Tom-PT ; 'sip' Subject: RE: [SIP] Re-direct of Media During Ringing This all appears to be focussing back to the old ISDN/B-ISDN discussions of what does answer really mean. Essentially there are several concepts that need to be designated, and a clear statement needs to be made about which protocol mechanism indicates which. They are: i) indication to the remote user of the session request ii) remote user acceptance of the session iii) start of charging for the session iv indication to the remote user of a media stream request v remote user acceptance of the media stream vi) start of charging for the media stream In the PSTN these boil down to two events, although with IN based queuing mechanisms, this is not totally satisfactory. In SIP they definitely do not all occur at the same time, and can need separate protocol mechanism for each. Some of these appearing at separate times will occur in more scenarios than others. The kludge is happening because the concepts have not been clearly separated. Keith Drage Keith Drage Lucent Technologies Tel: +44 1793 776249 Email: drage@lucent.com > ---------- > From: Henning Schulzrinne[SMTP:schulzrinne@cs.columbia.edu] > Sent: 04 October 2000 0:18 > To: Simon Barber > Cc: Jonathan Rosenberg; 'hammer michael'; Doug Harbert; 'Tom-PT Taylor'; > 'sip' > Subject: Re: [SIP] Re-direct of Media During Ringing > > The problem is treating waiting in queue as early media - it's a session > and should be treated as such. It's a call when you call the airline, > say, even with steamphones. As I said earlier, the whole early media > stuff is a kludge. The less we use it, the better. Trying to fix the > kludge just adds layers upon layers of double complexity, once for > "real" sessions and once for "pseudo" sessions, for no good reason. With > a real VoIP system (as opposed to one that tries to imitate the analog > phone system), you wouldn't get a voice stream for queueing, it would > just be a 18x message, with no bandwidth difficulties. > -- > Henning Schulzrinne http://www.cs.columbia.edu/~hgs > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip ------_=_NextPart_001_01C02E01.22B02CB0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: [SIP] Re-direct of Media During Ringing

Added to this we have the concept of a preliminary = one way media stream (from called party to calling party) which is not = charged for - i.e. alerting or queueing phase.

I guess this has been modelled as 'early media' which = occurs before confirmation of the session, whereas arguably this should = be something which is considered to take place after establishment of = the session, but before charging begins.

Is the problem the fact that session establishment = has been equated with called party answer ?

Regards,

Mark Watson
Nortel Networks

-----Original Message-----
From: Drage, Keith (Keith) [mailto:drage@lucent.com]
Sent: 04 October 2000 10:42
To: Simon Barber; 'Henning Schulzrinne'
Cc: Jonathan Rosenberg; 'hammer michael'; Doug = Harbert; Taylor, Tom-PT ;
'sip'
Subject: RE: [SIP] Re-direct of Media During = Ringing


This all appears to be focussing back to the old = ISDN/B-ISDN discussions of
what does answer really mean. Essentially there are = several concepts that
need to be designated, and a clear statement needs = to be made about which
protocol mechanism indicates which. They are:

i)      indication to the = remote user of the session request
ii)     remote user acceptance = of the session
iii)    start of charging for the = session
iv      indication to the = remote user of a media stream request
v       remote user = acceptance of the media stream
vi)     start of charging for = the media stream

In the PSTN these boil down to two events, although = with IN based queuing
mechanisms, this is not totally satisfactory. In SIP = they definitely do not
all occur at the same time, and can need separate = protocol mechanism for
each.

Some of these appearing at separate times will occur = in more scenarios than
others. The kludge is happening because the concepts = have not been clearly
separated.

Keith Drage

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

> ----------
> From: =         Henning = Schulzrinne[SMTP:schulzrinne@cs.columbia.edu]
> Sent: =         04 October 2000 0:18
> To:   Simon Barber
> Cc:   Jonathan Rosenberg; 'hammer = michael'; Doug Harbert; 'Tom-PT Taylor';
> 'sip'
> Subject:      Re: [SIP] = Re-direct of Media During Ringing
>
> The problem is treating waiting in queue as = early media - it's a session
> and should be treated as such. It's a call when = you call the airline,
> say, even with steamphones. As I said earlier, = the whole early media
> stuff is a kludge. The less we use it, the = better. Trying to fix the
> kludge just adds layers upon layers of double = complexity, once for
> "real" sessions and once for = "pseudo" sessions, for no good reason. With
> a real VoIP system (as opposed to one that = tries to imitate the analog
> phone system), you wouldn't get a voice stream = for queueing, it would
> just be a 18x message, with no bandwidth = difficulties.
> --
> Henning Schulzrinne   http://www.cs.columbia.edu/~hgs
>
> = _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip
>

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip

------_=_NextPart_001_01C02E01.22B02CB0-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 4 08:50:00 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA17939 for ; Wed, 4 Oct 2000 08:50:00 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 654D0443AC; Wed, 4 Oct 2000 07:50:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id C1D014433F for ; Wed, 4 Oct 2000 07:49:43 -0400 (EDT) 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 IAA02219; Wed, 4 Oct 2000 08:49:27 -0400 (EDT) Message-ID: <39DB2758.B217F4CD@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Mark Watson Cc: "'Drage, Keith (Keith)'" , Simon Barber , Jonathan Rosenberg , "'hammer michael'" , Doug Harbert , Tom-PT Taylor , "'sip'" Subject: Re: [SIP] Re-direct of Media During Ringing References: <61ABD11436FED21192440000F81F3E360304C2E6@nwcwi1a.europe.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 04 Oct 2000 08:49:28 -0400 Content-Transfer-Encoding: 7bit Can we please remove the word "charging" from the discussion? SIP has nothing directly to do with charging or billing, as discussed numerous times on this mailing list. Tying SIP requests to charging in a PSTN-like way is only going to lead to convoluted, inflexible and bell-headed architectures. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 4 09:06:59 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA18583 for ; Wed, 4 Oct 2000 09:06:59 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4EB17443A9; Wed, 4 Oct 2000 08:07:01 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id AD41344356 for ; Wed, 4 Oct 2000 08:06:22 -0400 (EDT) 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 JAA02889; Wed, 4 Oct 2000 09:06:15 -0400 (EDT) Message-ID: <39DB2B48.D496B50D@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: James Undery Cc: sip@lists.bell-labs.com References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] Re: Registering non-SIP URIs Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 04 Oct 2000 09:06:16 -0400 Content-Transfer-Encoding: 7bit Added at the beginning of the REGISTER section: A client uses the {\REGISTER} method to bind the address listed in the \header{To} header field with a SIP server to one or more URIs where the client can be reached. These URIs may use any schema, not limited to SIP. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 4 09:49:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA20207 for ; Wed, 4 Oct 2000 09:49:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2F80944362; Wed, 4 Oct 2000 08:49:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from drago1.ubiquity.net (unknown [194.202.146.92]) by lists.bell-labs.com (Postfix) with SMTP id 784DB44356 for ; Wed, 4 Oct 2000 08:48:43 -0400 (EDT) Received: from gecko.ubiquity.co.uk by drago1.ubiquity.net via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 4 Oct 2000 13:49:04 UT Received: from jundery.ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id OAA13680; Wed, 4 Oct 2000 14:47:00 +0100 (BST) Received: from localhost (jundery@localhost) by jundery.ubiquity.net (8.9.3/8.9.3) with ESMTP id OAA02392; Wed, 4 Oct 2000 14:47:01 GMT X-Authentication-Warning: jundery.ubiquity.net: jundery owned process doing -bs From: James Undery To: Henning Schulzrinne Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Re: Registering non-SIP URIs In-Reply-To: <39DB2B48.D496B50D@cs.columbia.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 4 Oct 2000 14:47:01 +0000 (GMT) On Wed, 4 Oct 2000, Henning Schulzrinne wrote: > Added at the beginning of the REGISTER section: > > A client uses the {\REGISTER} method to bind the address listed in > the \header{To} header field with a SIP server to one or more URIs where > the client can be reached. These URIs may use any schema, not > limited > to SIP. The point that I thought was missing is that SIP URIs have a default expiration of one hour, whereas, non-SIP URIs don't expire by default (according to section 6.14). HTH James Undery _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 4 10:17:00 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA20947 for ; Wed, 4 Oct 2000 10:16:59 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9509C443AB; Wed, 4 Oct 2000 09:17:01 -0400 (EDT) Delivered-To: sip@share.research.bell-labs.com Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by lists.bell-labs.com (Postfix) with SMTP id B7C5B44356 for ; Wed, 4 Oct 2000 09:16:05 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Wed Oct 4 10:15:24 EDT 2000 Received: by lists.bell-labs.com (Postfix) id C9FB344380; Wed, 4 Oct 2000 10:02:14 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from uk0006exch001h.wins.lucent.com (uk0006exch001h.uk.lucent.com [135.86.160.150]) by lists.bell-labs.com (Postfix) with ESMTP id 4D6C34437D for ; Wed, 4 Oct 2000 10:02:14 -0400 (EDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id ; Wed, 4 Oct 2000 15:02:13 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB00BCFB0@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: Mark Watson , "'Henning Schulzrinne'" Cc: "Drage, Keith (Keith)" , Simon Barber , Jonathan Rosenberg , "'hammer michael'" , Doug Harbert , Tom-PT Taylor , "'sip'" Subject: RE: [SIP] Re-direct of Media During Ringing MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 4 Oct 2000 15:02:10 +0100 And that may be the very reason why the kludges exist. There will be implementations of SIP that will need to including charging for the provision of a session, and for the provision of a media stream. That aspect, and how such charging should be made, is entirely up to the implementor. However, there may need to be an end-to-end flow, or at least between the proxies, that says "charging is now valid", or some such, and sent to the end user as "charging is now being applied", and this may be different from the acceptance by the end user of either a media stream or the session. Without that separation of charging from acceptance, then no session or media stream can be accepted until charging is due to start, thus resulting in this concept of "early media", which in essence is "before charging starts". Keith Drage Keith Drage Lucent Technologies Tel: +44 1793 776249 Email: drage@lucent.com > ---------- > From: Henning Schulzrinne[SMTP:schulzrinne@cs.columbia.edu] > Sent: 04 October 2000 13:49 > To: Mark Watson > Cc: 'Drage, Keith (Keith)'; Simon Barber; Jonathan Rosenberg; 'hammer > michael'; Doug Harbert; Tom-PT Taylor; 'sip' > Subject: Re: [SIP] Re-direct of Media During Ringing > > Can we please remove the word "charging" from the discussion? SIP has > nothing directly to do with charging or billing, as discussed numerous > times on this mailing list. Tying SIP requests to charging in a > PSTN-like way is only going to lead to convoluted, inflexible and > bell-headed architectures. > -- > Henning Schulzrinne http://www.cs.columbia.edu/~hgs > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 4 10:26:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA21107 for ; Wed, 4 Oct 2000 10:26:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6459644362; Wed, 4 Oct 2000 09:26:01 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by lists.bell-labs.com (Postfix) with ESMTP id 0FF8544356 for ; Wed, 4 Oct 2000 09:25:56 -0400 (EDT) Received: from daebh02nok.americas.nokia.com (daebh02nok.americas.nokia.com [172.18.242.183]) by mgw-x2.nokia.com (8.10.2/8.10.2/Nokia) with ESMTP id e94EPmP21622; Wed, 4 Oct 2000 17:25:48 +0300 (EET DST) Received: by daebh02nok with Internet Mail Service (5.5.2448.0) id ; Wed, 4 Oct 2000 09:25:47 -0500 Message-ID: From: Cliff.Harris@nokia.com To: Joshua_Fox@vocaltec.com, sip@lists.bell-labs.com Subject: RE: [SIP] centralized vs. decentralized architectures MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 4 Oct 2000 09:19:01 -0500 > -----Original Message----- > From: EXT Joshua_Fox@vocaltec.com [mailto:Joshua_Fox@vocaltec.com] > Sent: Wednesday, October 04, 2000 3:16 AM > To: sip@lists.bell-labs.com > Subject: [SIP] centralized vs. decentralized architectures > > > > I have recently posed some questions about centralized vs. > decentralized > architectures and SIP. > > One issue is that there is no escape from requiring the user > to register an > ID or to generate one. The need for user identity, as opposed to true > anonymity, is one type of decentralization. Why doesn't a B2BUA provide true anonymity? By the way, I'm curious about why anonymity is so important: are there legitimate reasons for people to make calls anonymously? > > Another issue is that SIP-based systems often use distributed > logic for > storing session state. On the other hand, the "center" (the > server) can > store session state using the back-to-back user-agent design. In that > case, the server serves as a proxy in a sense (not the usual > "SIP Proxy > Server sense" ) for the clients, communicating with them by another > protocol. A B2BUA speaks SIP on both sides. A SIP gateway speaks SIP on one side and some other protocol on the other. [ snipped ] _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 4 10:53:00 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA21734 for ; Wed, 4 Oct 2000 10:52:59 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 67C6B44362; Wed, 4 Oct 2000 09:53:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mail.parsec.co.za (mail.parsec.co.za [196.37.137.10]) by lists.bell-labs.com (Postfix) with SMTP id 84C3A44356 for ; Wed, 4 Oct 2000 09:52:12 -0400 (EDT) Received: from thys (unverified [172.17.5.45]) by server00.parsec.co.za (EMWAC SMTPRS 0.83) with SMTP id ; Wed, 04 Oct 2000 16:54:59 +0200 From: "Thys Nel" To: Message-ID: <004b01c02e12$99a329b0$2d0511ac@thys> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: [SIP] ipv4 addresses in sip bnf Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 4 Oct 2000 16:51:37 +0200 Content-Transfer-Encoding: 7bit Some time ago there was a discussion in this list about the correct bnf for ipv4 addresses in rfc2327 (sdp). Currently in sip an ipv4 address is defined as: IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT which of course allows invalid ipv4 addresses to pass the parser. Is there any specific reason why this definition is different to the one used in rfc2327? IP4-address = decimal-uchar "." decimal-uchar "." decimal-uchar "." decimal-uchar where decimal-uchar can be 0-255. The same applies to the "ttl" definition. -- Thys Nel _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 4 11:00:16 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA21883 for ; Wed, 4 Oct 2000 11:00:15 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 21E8D44362; Wed, 4 Oct 2000 10:00:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from smtp1.cluster.oleane.net (smtp1.cluster.oleane.net [195.25.12.16]) by lists.bell-labs.com (Postfix) with ESMTP id 4D82244356 for ; Wed, 4 Oct 2000 09:59:34 -0400 (EDT) Received: from oleane (dyn-1-1-241.Vin.dialup.oleane.fr [195.25.4.241]) by smtp1.cluster.oleane.net with SMTP id RAA39399 for ; Wed, 4 Oct 2000 17:00:27 +0200 (CEST) Message-ID: <005201c02e13$87c40240$0401a8c0@oleane.com> From: "Peter Lewis" To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_004F_01C02E24.4AD8DAC0" 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 Subject: [SIP] International SIP Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 4 Oct 2000 16:58:17 +0200 This is a multi-part message in MIME format. ------=_NextPart_000_004F_01C02E24.4AD8DAC0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable International SIP, 20-23 February 2001. The call for proposals dead line has been postponed to October 19th. Please get more details at: http://www.upperside.fr/intersip/intersip.htm ------=_NextPart_000_004F_01C02E24.4AD8DAC0 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
International SIP, 20-23 February=20 2001.
The call for proposals dead line has = been=20 postponed to October 19th.
Please get more details = at:
http://www.uppersi= de.fr/intersip/intersip.htm
 
 
------=_NextPart_000_004F_01C02E24.4AD8DAC0-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 4 11:16:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA22360 for ; Wed, 4 Oct 2000 11:16:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id AB69F44362; Wed, 4 Oct 2000 10:16:01 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14]) by lists.bell-labs.com (Postfix) with ESMTP id 6D17644356 for ; Wed, 4 Oct 2000 10:15:11 -0400 (EDT) Received: from fokus.gmd.de (dhcp082 [195.37.78.210]) by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id RAA00203; Wed, 4 Oct 2000 17:14:52 +0200 (MET DST) Message-ID: <39DB4974.4EAF0279@fokus.gmd.de> From: Jiri Kuthan Organization: GMD Fokus X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Simon Barber Cc: Jonathan Rosenberg , Jon.Peterson@Level3.com, sip@lists.bell-labs.com Subject: Re: [SIP] SIP through firewalls without SIP proxy References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 04 Oct 2000 17:15:00 +0200 Content-Transfer-Encoding: 7bit If you use an RTP/UDP/IP/Simon's_remote_sockets/HTTP/TCP/IP protocol stack you'll lose UDP's real-time property, introduce considerable bandwidth and processing overhead, and require presence of a cooperating Simon's_remote_sockets/HTTP/TCP/IP server. SOCKs is more or less doing what you're proposing. Simon Barber wrote: > > I'm proposing a generic method to transport socket API calls (these may > apply to many sockets) through a single connection. RTP media would be > transported by sending messages corresponding to send and recv API calls. > All these messages would go through the same single connection. This > connection might be a TCP stream or an HTTP stream. If your design requirement is the ability to subvert firewall policy you should check mailing lists dedicated to firewall hacking. > The key difference between this and foglamps or SOCKS is that this does not > require the firewall administrator's permission, or even knowledge. For this > to work UDP and TCP data and control must all pass over the same connection. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 4 12:58:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA25963 for ; Wed, 4 Oct 2000 12:58:02 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 49443443AB; Wed, 4 Oct 2000 11:58:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mailsrv02.multitude.com (mailsrv02.firetalk.com [204.178.116.251]) by lists.bell-labs.com (Postfix) with ESMTP id 4A657443A9 for ; Wed, 4 Oct 2000 11:57:33 -0400 (EDT) Received: from sbarber2k (s242.firetalk.com [204.178.116.242]) by mailsrv02.multitude.com (Rockliffe SMTPRA 3.4.2) with SMTP id ; Wed, 4 Oct 2000 09:55:25 -0700 From: "Simon Barber" To: "Drage, Keith (Keith)" , "'Henning Schulzrinne'" Cc: "Jonathan Rosenberg" , "'hammer michael'" , "Doug Harbert" , "'Tom-PT Taylor'" , "'sip'" Subject: RE: [SIP] Re-direct of Media During Ringing Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0007_01C02DE9.B3BF4320" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <475FF955A05DD411980D00508B6D5FB00BCFAC@en0033exch001u.uk.lucent.com> Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 4 Oct 2000 09:58:53 -0700 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C02DE9.B3BF4320 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit You put it far better than I could have! The big question is how to change SIP to better separate these concepts. Simon Barber > -----Original Message----- > From: sip-admin@lists.bell-labs.com > [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Drage, Keith (Keith) > Sent: Wednesday, October 04, 2000 2:42 AM > To: Simon Barber; 'Henning Schulzrinne' > Cc: Jonathan Rosenberg; 'hammer michael'; Doug Harbert; 'Tom-PT Taylor'; > 'sip' > Subject: RE: [SIP] Re-direct of Media During Ringing > > > This all appears to be focussing back to the old ISDN/B-ISDN > discussions of > what does answer really mean. Essentially there are several concepts that > need to be designated, and a clear statement needs to be made about which > protocol mechanism indicates which. They are: > > i) indication to the remote user of the session request > ii) remote user acceptance of the session > iii) start of charging for the session > iv indication to the remote user of a media stream request > v remote user acceptance of the media stream > vi) start of charging for the media stream > > In the PSTN these boil down to two events, although with IN based queuing > mechanisms, this is not totally satisfactory. In SIP they > definitely do not > all occur at the same time, and can need separate protocol mechanism for > each. > > Some of these appearing at separate times will occur in more > scenarios than > others. The kludge is happening because the concepts have not been clearly > separated. > > Keith Drage > > Keith Drage > Lucent Technologies > Tel: +44 1793 776249 > Email: drage@lucent.com > > > ---------- > > From: Henning Schulzrinne[SMTP:schulzrinne@cs.columbia.edu] > > Sent: 04 October 2000 0:18 > > To: Simon Barber > > Cc: Jonathan Rosenberg; 'hammer michael'; Doug Harbert; > 'Tom-PT Taylor'; > > 'sip' > > Subject: Re: [SIP] Re-direct of Media During Ringing > > > > The problem is treating waiting in queue as early media - it's a session > > and should be treated as such. It's a call when you call the airline, > > say, even with steamphones. As I said earlier, the whole early media > > stuff is a kludge. The less we use it, the better. Trying to fix the > > kludge just adds layers upon layers of double complexity, once for > > "real" sessions and once for "pseudo" sessions, for no good reason. With > > a real VoIP system (as opposed to one that tries to imitate the analog > > phone system), you wouldn't get a voice stream for queueing, it would > > just be a 18x message, with no bandwidth difficulties. > > -- > > Henning Schulzrinne http://www.cs.columbia.edu/~hgs > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > ------=_NextPart_000_0007_01C02DE9.B3BF4320 Content-Type: text/x-vcard; name="Simon Barber.vcf" Content-Disposition: attachment; filename="Simon Barber.vcf" Content-Transfer-Encoding: quoted-printable BEGIN:VCARD VERSION:2.1 N:Barber;Simon FN:Simon Barber ORG:Firetalk Communications, Inc. TEL;WORK;VOICE:(650) 636-1924 TEL;CELL;VOICE:(650) 743-1919 ADR;WORK:;;5000 Shoreline Court, Suite 200;South San = Francisco;CA;94080;United States of America LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:5000 Shoreline Court, Suite = 200=3D0D=3D0ASouth San Francisco, CA 94080=3D0D=3D0AUnit=3D ed States of America URL:http://www.firetalk.com URL:http://www.firetalk.com EMAIL;PREF;INTERNET:simon@firetalk.com REV:20000914T193921Z END:VCARD ------=_NextPart_000_0007_01C02DE9.B3BF4320-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 4 14:45:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA28633 for ; Wed, 4 Oct 2000 14:45:02 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3549644362; Wed, 4 Oct 2000 13:45:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from pigeon.vovida.com (a98.vovida.com [209.237.8.98]) by lists.bell-labs.com (Postfix) with ESMTP id 7542944356 for ; Wed, 4 Oct 2000 13:44:37 -0400 (EDT) Received: from vovida.com ([209.237.8.113]) by pigeon.vovida.com (Netscape Messaging Server 4.15) with ESMTP id G1X53Q00.39E; Wed, 4 Oct 2000 11:38:14 -0700 Message-ID: <39DB7A87.7BD48763@vovida.com> From: Amit Choksi Organization: Vovida Networks X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14 i686) X-Accept-Language: en MIME-Version: 1.0 To: Lyndon Ong Cc: sip Subject: Re: [SIP] SIP ISUP MIME draft References: <4.2.2.20001003160256.00bd5730@zsc4c006.corpwest.baynetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 04 Oct 2000 11:44:23 -0700 Content-Transfer-Encoding: 7bit Hi, I had a few questions about the draft 1. Can a Content-Transfer-Encoding header be expected 2. Is Content-Disposition a mandatory field 3. Is it possible that we have multiple Content-Type: headers followed by the corresponding payload Content-Type:application/ISUP Content-Type:application/SDP CRLF .....data...... CRLF ........data..... CRLF I appologize if I have missed the information already clarified in the draft. Thanks in advance Amit Choksi Lyndon Ong wrote: > Folks, > > I have not seen any comments on the list regarding the reissued SIP ISUP > MIME draft > (http://www.ietf.org/internet-drafts/draft-ietf-sip-isup-mime-04.txt), > although I've gotten some minor ones offline. Are there any comments or > questions on the draft? > > Thanks, > > L. Ong > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 4 15:39:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA29885 for ; Wed, 4 Oct 2000 15:39:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id F3C1A44362; Wed, 4 Oct 2000 14:39:01 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from june.Broomfield1.level3.net (june.Broomfield1.Level3.net [209.245.18.7]) by lists.bell-labs.com (Postfix) with ESMTP id CAFF744356 for ; Wed, 4 Oct 2000 14:38:24 -0400 (EDT) Received: from f1ee40-19.idc1.level3.com (hme0.f1ee40-19.idc1.oss.level3.com [10.1.144.204]) by june.Broomfield1.level3.net (8.9.3/8.9.3) with ESMTP id TAA26068; Wed, 4 Oct 2000 19:38:10 GMT From: Jon.Peterson@Level3.com Received: from n0195idc1.oss.level3.com (localhost [127.0.0.1]) by f1ee40-19.idc1.level3.com (8.8.8+Sun/8.8.8) with ESMTP id NAA17039; Wed, 4 Oct 2000 13:37:54 -0600 (MDT) Received: by n0195idc1.oss.level3.com with Internet Mail Service (5.5.2650.21) id ; Wed, 4 Oct 2000 13:39:45 -0600 Message-ID: <87A245E94948D3118DE30008C716B01301523B97@c0005v1idc1.oss.level3.com> To: achoksi@vovida.com, long@nortelnetworks.com Cc: sip@lists.bell-labs.com Subject: RE: [SIP] SIP ISUP MIME draft MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 4 Oct 2000 13:37:47 -0600 1. Content-Encoding is not used in any of the examples in the draft; the form in which ISUP is transmitted should be its native binary encoding. So it shouldn't be expected, no. Whether or not it could be used (if you for some reason wanted to encode ISUP differently) is a matter that would require some discussion. I wouldn't rule it out. 2. It is optional, but it has a default value as outlined in rfc2543 which we are not overloading - namely that the content should be considered a mandatory content (handling=required), and that in requests and 2xx responses 'session' is the assumed disposition for backwards-compatibility. However, rfc2543bis-02 also specifies that if the MIME type doesn't have a default disposition, then the disposition should be assumed to be 'render'. This seems to conflict with the backwards compatibility mechanism described above, and someone should probably fix that. I'd vote for mainaining the latter statute. Now, that much said, the ISUP MIME draft today doesn't specify a default content disposition for the ISUP MIME type. As the bis asks MIME types to have a default, I think we probably should define one, and I think it should be 'session' for ISUP. I suppose it would be the same for QSIG... Lyndon, have any feelings about that? 3. In the examples in the draft, a MIME multipart/mixed type is used; this allows multiple MIME bodies to appear in the same message. So, yes, it is possible, with multipart/mixed, although the format is different than the one you suggest below. Jon Peterson Aparna Vemuri Level(3) Communications -----Original Message----- From: Amit Choksi [mailto:achoksi@vovida.com] Sent: Wednesday, October 04, 2000 12:44 PM To: Lyndon Ong Cc: sip Subject: Re: [SIP] SIP ISUP MIME draft Hi, I had a few questions about the draft 1. Can a Content-Transfer-Encoding header be expected 2. Is Content-Disposition a mandatory field 3. Is it possible that we have multiple Content-Type: headers followed by the corresponding payload Content-Type:application/ISUP Content-Type:application/SDP CRLF .....data...... CRLF ........data..... CRLF I appologize if I have missed the information already clarified in the draft. Thanks in advance Amit Choksi Lyndon Ong wrote: > Folks, > > I have not seen any comments on the list regarding the reissued SIP ISUP > MIME draft > (http://www.ietf.org/internet-drafts/draft-ietf-sip-isup-mime-04.txt), > although I've gotten some minor ones offline. Are there any comments or > questions on the draft? > > Thanks, > > L. Ong > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 4 16:02:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA00373 for ; Wed, 4 Oct 2000 16:02:02 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3AA7B44362; Wed, 4 Oct 2000 15:02:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from aphrodite.systems.cfer.com (unknown [198.78.16.4]) by lists.bell-labs.com (Postfix) with ESMTP id 4404B44356 for ; Wed, 4 Oct 2000 15:01:31 -0400 (EDT) Received: from voyanttech.com (dough-pc [192.168.58.41]) by aphrodite.systems.cfer.com (8.8.8+Sun/8.8.8) with ESMTP id NAA09426; Wed, 4 Oct 2000 13:57:23 -0600 (MDT) Message-ID: <39DB8CE9.9CD6328B@voyanttech.com> From: Doug Harbert X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: "Drage, Keith (Keith)" Cc: Simon Barber , "'Henning Schulzrinne'" , Jonathan Rosenberg , "'hammer michael'" , "'Tom-PT Taylor'" , "'sip'" Subject: Re: [SIP] Re-direct of Media During Ringing References: <475FF955A05DD411980D00508B6D5FB00BCFAC@en0033exch001u.uk.lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 04 Oct 2000 14:02:49 -0600 Content-Transfer-Encoding: 7bit "Drage, Keith (Keith)" wrote: > This all appears to be focussing back to the old ISDN/B-ISDN discussions of > what does answer really mean. Essentially there are several concepts that > need to be designated, and a clear statement needs to be made about which > protocol mechanism indicates which. They are: > > i) indication to the remote user of the session request > ii) remote user acceptance of the session > iii) start of charging for the session > iv indication to the remote user of a media stream request > v remote user acceptance of the media stream > vi) start of charging for the media stream > > In the PSTN these boil down to two events, although with IN based queuing > mechanisms, this is not totally satisfactory. In SIP they definitely do not > all occur at the same time, and can need separate protocol mechanism for > each. > > Some of these appearing at separate times will occur in more scenarios than > others. The kludge is happening because the concepts have not been clearly > separated. > > Keith Drage > > Keith Drage > Lucent Technologies > Tel: +44 1793 776249 > Email: drage@lucent.com > > > ---------- > > From: Henning Schulzrinne[SMTP:schulzrinne@cs.columbia.edu] > > Sent: 04 October 2000 0:18 > > To: Simon Barber > > Cc: Jonathan Rosenberg; 'hammer michael'; Doug Harbert; 'Tom-PT Taylor'; > > 'sip' > > Subject: Re: [SIP] Re-direct of Media During Ringing > > > > The problem is treating waiting in queue as early media - it's a session > > and should be treated as such. It's a call when you call the airline, > > say, even with steamphones. As I said earlier, the whole early media > > stuff is a kludge. The less we use it, the better. Trying to fix the > > kludge just adds layers upon layers of double complexity, once for > > "real" sessions and once for "pseudo" sessions, for no good reason. With > > a real VoIP system (as opposed to one that tries to imitate the analog > > phone system), you wouldn't get a voice stream for queueing, it would > > just be a 18x message, with no bandwidth difficulties. > > -- > > Henning Schulzrinne http://www.cs.columbia.edu/~hgs > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > Keith: In my opinion, the early media kludge is due to the desire to equate establishment of a session with the called party answering the phone. I think that if we establish the session early on, then setting up media streams for delivery of call progress tones, and setting up media streams for voice conversation within that session can be accomplished with protocol elements already defined for SIP (specifically re-invite). An agent which is recording charging data could be made to trigger on those elements to determine the start of each phase of the call. Doug Harbert. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 4 16:19:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA00877 for ; Wed, 4 Oct 2000 16:19:00 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id AF216443D2; Wed, 4 Oct 2000 15:19:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from wusr3.mobilerain.com (sdsl-208-185-234-252.dsl.sjc.megapath.net [208.185.234.252]) by lists.bell-labs.com (Postfix) with ESMTP id 3168544356 for ; Wed, 4 Oct 2000 15:18:18 -0400 (EDT) Received: from mobilerain.com (IDENT:dsardana@localhost [127.0.0.1]) by wusr3.mobilerain.com (8.9.3/8.9.3) with ESMTP id NAA03916; Wed, 4 Oct 2000 13:16:57 -0700 Message-ID: <39DB9039.87C4CDF4@mobilerain.com> From: Bobby Sardana Organization: MobileRain Technologies, Inc. X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: Amit Choksi Cc: Lyndon Ong , sip Subject: Re: [SIP] SIP ISUP MIME draft References: <4.2.2.20001003160256.00bd5730@zsc4c006.corpwest.baynetworks.com> <39DB7A87.7BD48763@vovida.com> Content-Type: multipart/mixed; boundary="------------74FC8F64F06B13F4493DAEE7" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 04 Oct 2000 13:16:57 -0700 This is a multi-part message in MIME format. --------------74FC8F64F06B13F4493DAEE7 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello Amit: The (3) would require a "unique boundary" (RFC 2046 MIME Part 2, Section 5.1.1) for separation of each embedded Content-Type. Regards, Bobby.Sardana@mobilerain.com Amit Choksi wrote: > Hi, > I had a few questions about the draft > > 1. Can a Content-Transfer-Encoding header be expected > 2. Is Content-Disposition a mandatory field > 3. Is it possible that we have multiple Content-Type: headers followed by > the corresponding payload > > Content-Type:application/ISUP > Content-Type:application/SDP > CRLF > .....data...... > CRLF > ........data..... > CRLF > > I appologize if I have missed the information already clarified in the > draft. > Thanks in advance > > Amit Choksi > > Lyndon Ong wrote: > > > Folks, > > > > I have not seen any comments on the list regarding the reissued SIP ISUP > > MIME draft > > (http://www.ietf.org/internet-drafts/draft-ietf-sip-isup-mime-04.txt), > > although I've gotten some minor ones offline. Are there any comments or > > questions on the draft? > > > > Thanks, > > > > L. Ong > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip --------------74FC8F64F06B13F4493DAEE7 Content-Type: text/x-vcard; charset=us-ascii; name="bobby.sardana.vcf" Content-Description: Card for Bobby Sardana Content-Disposition: attachment; filename="bobby.sardana.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Sardana;Bobby x-mozilla-html:FALSE org:MobileRain Technologies, Inc.;Telecommunications adr:;;;;;; version:2.1 email;internet:bobby.sardana@mobilerain.com title:Engineer x-mozilla-cpt:;0 fn:Bobby Sardana end:vcard --------------74FC8F64F06B13F4493DAEE7-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 4 16:25:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA00955 for ; Wed, 4 Oct 2000 16:25:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id AC18944356; Wed, 4 Oct 2000 15:25:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by lists.bell-labs.com (Postfix) with ESMTP id BD69E44356 for ; Wed, 4 Oct 2000 15:24:41 -0400 (EDT) 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 NAA03060; Wed, 4 Oct 2000 13:25:03 -0700 (PDT) Received: from buckthorn-nt (dhcp-171-69-93-137.cisco.com [171.69.93.137]) by imop.cisco.com (Mirapoint) with ESMTP id AAG06400; Wed, 4 Oct 2000 13:24:35 -0700 (PDT) Message-Id: <4.2.0.58.20001004130911.00dd1a70@imop.cisco.com> X-Sender: rmahy@imop.cisco.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 To: "Roy, Radhika R, ALCOO" From: Rohan Mahy Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP Mobility ) Cc: Brian Stucker , sip@lists.bell-labs.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 04 Oct 2000 13:13:52 -0700 At 10:51 AM 9/29/00 , Roy, Radhika R, ALCOO wrote: >Hi, Brian: > >I guess that your mail has provided some technical inputs: 1. Inter-session >mobility and 2. Intra-session mobility. > >For inter-session mobility, you think that SIP in OK. > >For intra-session mobility, it appears that you are feeling comfortable, as >if, SIP is not designed to do this. > >Let us go to the basic: SIP is a session initiation protocol. It is the >mandate of SIP. So, we like to see that it MUST deal with mobility as well *NO* !! Part of SIPs mandate is *personal* mobility, as a user moves from device to device. Personal mobility is a good, useful thing. However, The SIP charter does *NOT* include solving the problem of a device moving through different layer 2 networks. This is a problem for a layer 3 protocol to solve generically. If Mobile IP doesn't do what we need it to, then lets extend it, fix it, or replace it. thanks, -rohan >because people will use it in mobile environment (for both intra- and >inter-session). > >For inter-session, I guess that there may be some involvement of REGISTER >and re-INVITE messages (because of change in location). > >That's all! > >All works are done in the lower layer and SIP is not involved (for example, >some one in the lower layer will find that the location has been changed, >accordingly the upper layer may take some actions, if needed). > >Hope this will clarify the things. > >Best regards, >Radhika R. Roy >AT&T > >-----Original Message----- >From: Brian Stucker [mailto:bstucker@nortelnetworks.com] >Sent: Friday, September 29, 2000 1:19 PM >To: sip@lists.bell-labs.com >Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP Mobility ) > > > >My intent isn't to confuse anyone. Quite the contrary. > >My point is that SIP, as an application, should not be concerned about the >vagaries of the underlying media it's being carried on. All applications >that use IP as a transport are going to have to contend with mobility in the >IP space on the intra-session timescale. So IP should solve the problem >because it's a general problem for IP. > >SIP does enough to handle inter-session mobility (I'm at my desk, I'm at >home), and not impede intra-session mobility. It's just simply not suited >for handling anything else because of the nature of the protocol. Any >intra-session mobility must be handled out-of-band as far as SIP is >concerned, and SIP must not make any requirements that would impede this. > >Again, to use wireless voice calls as an example, even with dedicated >transport links, thousands of pages of standards with CDMA/TDMA, IS-41, SS7, >and TCAP, a mobile switching center doesn't attempt to do what you guys are >talking about. It doesn't update the location of a mobile once it's handed >over to another switch in the location database until after your call has >completed, and the mobile registers on the system it moved into. Why? >Because the mobile could be handed back over to the first system, the >handoff could fail, etc. So they don't even attempt to keep the exact >location of the mobile up to date outside of the original switch until the >mobile is stable again, when the call ends. Instead, all incoming calls go >to the first switch, and that switch knows where to go from there to get the >call completed. > >SIP shouldn't be updating the location database every time a wireless >terminal moves around. Some sort of mobile IP proxy function, should instead >be used that knows how to currently find the terminal in it's mobile-aware >IP space. It should route based on the inbound packet's IP address only, and >not care what the payload data is either. > >That solves the problem for SIP, HTTP, FTP, POP3, RTP, you name it. Why >write an extension to every protocol that uses IP as a transport (and have >it solved, and debugged a million different ways) instead of just fixing the >problem at the IP layer (and have it solved, and debugged one way)? > >Brian Stucker >Nortel Networks > >-----Original Message----- >From: Roy, Radhika R, ALCOO [ mailto:rrroy@att.com ] >Sent: Friday, September 29, 2000 11:39 AM >To: hammer michael; Michael Thomas; Henry Sinnreich >Cc: Lewis Karl-QA3387; 'Henning Schulzrinne'; sip@lists.bell-labs.com >Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP >Mobility ) > > >Hi, Everyone: > >The need for addressing mobility is clear and SIP is only one part of the >whole equation. > >Let us not confuse people in the name of Pandora's box or otherwise. > >We have to meet the needs solving problems (not to show our back). > >For the SIP WG, it is the SIP session layer that needs to be addressed, if >it turns out that is a need to do some works. > >Best regards, >Radhika R. Roy >AT&T > >-----Original Message----- >From: hammer michael [ mailto:mhammer@cisco.com ] > >Sent: Friday, September 29, 2000 1:57 PM >To: Roy, Radhika R, ALCOO; Michael Thomas; Henry Sinnreich >Cc: Lewis Karl-QA3387; 'Henning Schulzrinne'; sip@lists.bell-labs.com >Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP >Mobility ) > > >I think Brian aptly pointed out the Pandora's box you open with "mobility." >That should be sufficient motivation to avoid that type of mobility in SIP. > >We are talking about different timescales, e.g.: per packet, per call, and >per registration. > >I thought your term "discrete" captured the idea that the type of >"mobility" you refer to is of the: call me at the office, then later, call >me at home, I'm here now "mobility." Because mobility conjures up so many >more issues, I like the word "presence" better. Presence management may be >more descriptive that mobility management. > >Mike > > >At 04:11 PM 09/28/2000 -0400, Roy, Radhika R, ALCOO wrote: > >Hi, Mike: > > > >Yes, we will have problems if we do not define the terms accurately. > > > >Let us assume that we are using SIP (RFC 2543) and its session layer as our > > >reference. Location, registration, and session are defined in SIP. > > > >Paging (and probably "path") has not been defined in SIP. I will not argue > >to take this abstraction in the SIP layer for now. > > > >Point of attachment has been used as a generic term to indicate "address of > > >the attachment." If we translate this abstraction in the SIP layer, it will > > >mean the addresses that are being used in the SIP layer (e.g., E.164, IP > >address, etc.). > > > >Now let us examine your points: Presence of a person or terminal, etc. > > > >In the SIP layer, I guess, that the presence of a person on a terminal >needs > >to be abstracted in terms of an "address." If that address is also related > >to the point of attachment, then it will also be related to mobility. > > > >(A person behind the terminal may have another ID to deal with personal > >mobility. Let us not address that personal mobility for now.) > > > >In this way, we can extend our analysis for each layer. > > > >Does this answer your question? > > > >Best regards, > >Radhika R. Roy > >AT&T > > > >-----Original Message----- > >From: hammer michael [ mailto:mhammer@cisco.com >] > >Sent: Thursday, September 28, 2000 6:29 PM > >To: Roy, Radhika R, ALCOO; Michael Thomas; Henry Sinnreich > >Cc: Lewis Karl-QA3387; 'Henning Schulzrinne'; sip@lists.bell-labs.com > >Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP > >Mobility ) > > > > > >Roy, > > > >I need to be very careful what word I choose. Session connection rather > >than path might have been more appropriate. I believe confusion can occur > >if the type of location, registration, location, paging, etc. is not > >accurately defined. I think that the intent of such services revolves > >about maintaining relationships between certain elements, such as between: > > > >user/application and terminal, > >terminal and network end-point, > >network end-point and link end-point, etc. > > > >The act of "registering" may mean different things at different layers and > >use different mechanisms to accomplish them. The question for me is > >whether these are handled independently or does one mechanism attempt to > >manage multiple associations or would one type of registration trigger > >another type at a different layer? > > > >Would SIP then manage the "presence" of a person on a terminal, where > >something else manages the "presence" of a terminal on the network? > > > >Mike Hammer > > > > > >At 12:28 PM 09/28/2000 -0400, Roy, Radhika R, ALCOO wrote: > > >Hi, Mike: > > > > > >You have made excellent points. In fact, you are in the heart of this > > >problem: How the communications path(s) needs to be established as the > >point > > >of attachment is changed during the contiguous mobility. > > > > > >I personally believe that SIP does not need to be involved to set up the > > >communications path(s) per se. > > > > > >However, SIP needs to be used to set up the session: re-INVITE (to the >new > > >address) may need to be used. > > > > > >In the process, location updates, paging, etc. are also involved. If the > > >location update does not have any impact in the SIP layer, I do not think > > > >that SIP should be aware of any change in the lower layer. For example, > > >mobile IP has the power of providing location transparency of the IP >layer > > >(although it has some problems to meet the performance requirements for >the > > >real-time communications like voice). > > > > > >In addition to IP addresses, there are also transport addresses (e.g., >UDP, > > >TCP) for media. One also needs to be careful how to deal with the TCP > > >connection. IP addresses change, but the TCP connections still remains >the > > >same. An update mechanism needs to be defined. In turn, does it mean that > > > >this updated information may also be propagated to the SIP layer (other > > >members may also provide comments on this) because SIP does have the > > >abstraction of the transport address? > > > > > >I have not yet talked about the link layer. > > > > > >I am not trying to solve the mobility problem here. > > > > > >All I am trying to show: If we try to analyze the situation doing an > > >end-to-end analysis, we can easily see what needs to be done in each >layer. > > >Finally, we can answer the question: Whether or not any new work is >needed > > >in the SIP layer to address both discrete and continuos mobility. > > > > > >But you are right that we MUST keep the involvement of the SIP layer to a > > > >minimal level (if possible, we should avoid it) to address the mobility > > >problem. > > > > > >Best regards, > > >Radhika R. Roy > > >AT&T > > > > > >-----Original Message----- > > >From: hammer michael [ mailto:mhammer@cisco.com > ] > > >Sent: Thursday, September 28, 2000 2:41 PM > > >To: Roy, Radhika R, ALCOO; Michael Thomas; Henry Sinnreich > > >Cc: Lewis Karl-QA3387; 'Henning Schulzrinne'; sip@lists.bell-labs.com > > >Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP > > >Mobility ) > > > > > > > > >Roy, > > > > > >Your use of the terms "discrete" and "continuous" strike to the heart of > > >the issue. In traditional mobile networks, there is an attempt to move >the > > >stream of media with the terminal as it crosses cell boundaries > > >(continuous). There are many papers related to voice and mobile-IP that > > >address how to move the communications path. > > > > > >The discrete case is more an issue of identification of the presence and > > >availability of recipients and the establishment of communications to > > >them. Because names and addresses denoting physical location are often > > >blurred, in essence, personal mobility involves the creation and deletion > > > >of recipients rather than their movement. > > > > > >As I understand it, SIP does not move existing communications so much as >it > > >destroys existing communications paths and replaces them with new ones. >In > > >that respect, some of the traditional mobility issues such as handover >are > > >avoided, but others, e.g. location updates and paging are still needed. > > > > > >While the telcos reverted to addressing hardware-oriented terminal >mobility > > >in PCS, the softer personal mobility is still open to definition. The >same > > >issues have appeared in the net world and each will need to be solved in > > >their respective layers. > > > > > >Mike > > > > > > > > >At 11:01 AM 09/28/2000 -0400, Roy, Radhika R, ALCOO wrote: > > > >Hi, Mike: > > > > > > > >In fact, this is the precisely the test why SIP should be involved or >to > >be > > > >enhanced to support mobility (discrete + continuos) in the case of >Voice, > > > >chat, IM, messaging, conferencing, games, and others. > > > > > > > >If it is found that SIP does not need to be involved, I do not think >that > > > >anyone will force it to do this. > > > > > > > >By the way, do you not see that how SIP (RFC 2543) has taken care of >many > > > >aspects of users' discrete mobility? Has it not been be an excellent >way > >of > > > >involving SIP to solve a kind of mobility in the first place (what >other > > > >applications like H.323 is yet to support)? > > > > > > > >Along the same line, if people come up with the ideas that it is better > > >to > > > >enhance SIP functionality to support other aspects of mobility (if > > > >alternative solutions are not there or not acceptable), I do not think > >that > > > >we should have any objections. > > > > > > > >Let us keep our mind open and judge each proposal with its own merits. > > > > > > > >Best regards, > > > >Radhika R. Roy > > > >AT&T > > > > > > > >-----Original Message----- > > > >From: Michael Thomas [ mailto:mat@cisco.com ] > > > >Sent: Wednesday, September 27, 2000 7:01 PM > > > >To: Henry Sinnreich > > > >Cc: Michael Thomas; Roy, Radhika R, ALCOO; Lewis Karl-QA3387; 'Henning > > > >Schulzrinne'; sip@lists.bell-labs.com > > > >Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP > > > >Mobility ) > > > > > > > > > > > >Henry Sinnreich writes: > > > > > >what seems clear is that there are a > > > > > >number of applications which won't be able to do > > > > > >that for a variety of reasons. > > > > > > > > > > Voice, chat, IM, messaging, conferencing, games, etc., are > > > > > plenty of reasons to justify the SIP approach to mobility. > > > > > > > > But what if you could do all of the same things > > > > and not need to modify or involve SIP and have the > > > > additional gain that things like http worked as well? > > > > > > > > Mike > > > > > > > > > > > > > > Henry > > > > > > > > > > >-----Original Message----- > > > > > >From: sip-admin@lists.bell-labs.com > > > > > >[ mailto:sip-admin@lists.bell-labs.com > ]On Behalf Of > > > > > >Michael Thomas > > > > > >Sent: Wednesday, September 27, 2000 8:33 PM > > > > > >To: Roy, Radhika R, ALCOO > > > > > >Cc: Michael Thomas; Lewis Karl-QA3387; 'Henning Schulzrinne'; > > > > > >sip@lists.bell-labs.com > > > > > >Subject: RE: [SIP] Attempt at summarizing current SIP > > > > > >drafts (SIP > > > > > >Mobility ) > > > > > > > > > > > > > > > > > > > > > > > >I guess what I'm having a hard time with is the > > > > > >starting point that assumes that SIP based > > > > > >application mobility is Good Thing. While it's > > > > > >clear that many applications *could* design in > > > > > >mobility, what seems clear is that there are a > > > > > >number of applications which won't be able to do > > > > > >that for a variety of reasons. Assuming that those > > > > > >applications are important too, then we're already > > > > > >stuck with needing to solve for the general > > > > > >problem. > > > > > > > > > > > >Starting out with the assumption that Mobile IP > > > > > >addresses the more general problem seems > > > > > >attractive because a good solution with fast > > > > > >handoff that addresses AAA and QoS would solve > > > > > >most of the application layer problems in a > > > > > >general way rather than just a SIP specific > > > > > >way. > > > > > > > > > > > >There also seems to be an implicit assumption in > > > > > >the draft of linkage of SIP to a AAA function. > > > > > >I'm going to guess that it is along the same line > > > > > >of thinking of the DQoS gate controller idea. The > > > > > >problem I have with that is that it is in the end > > > > > >an optimization on the normal RSVP/COPS pull > > > > > >model. However, things that don't fit into that > > > > > >model still have the non-optimized way of doing > > > > > >QoS authorization. That's probably not the fault > > > > > >of this draft, but it does seem to make the entire > > > > > >draft a cart-before-horse situation. > > > > > > > > > > > > Mike > > > > > > > > > > > >Roy, Radhika R, ALCOO writes: > > > > > > > Hi, Mike: > > > > > > > > > > > > > > I guess that SIP, as you rightly pointed out, is > > > > > >dealing with the signaling > > > > > > > mechanism in the application layer. So, SIP does > > > > > >not need to deal with L3 > > > > > > > media path. > > > > > > > > > > > > > > SIP does deal with addresses of the source and > > > > > >destination(s). > > > > > > > > > > > > > > In mobile environment, the point of attachment > > > > > >(i.e., addresses) changes: 1. > > > > > > > Between the sessions (discrete mobility) and 2. > > > > > >During the session > > > > > > > (continuous mobility). > > > > > > > > > > > > > > The problem that is being addressed is: What is the > > > > > >impact in SIP layer due > > > > > > > to these two kinds of mobility. > > > > > > > > > > > > > > I guess that for discrete mobility, SIP has > > > > > >probably addressed most of the > > > > > > > problems (others may also provide comments on this). > > > > > > > > > > > > > > For continuous mobility, there may need (or may > > > > > >not??) some works in the SIP > > > > > > > layer, if any (others may also provide comments). > > > > > > > > > > > > > > However, SIP can only address the mobility related > > > > > >problems in the > > > > > > > application layer. This alone may not be enough to > > > > > >solve all problems > > > > > > > because some L3 and L2 problems may also need to be > > > > > >addressed at the same > > > > > > > time to have the complete solution. > > > > > > > > > > > > > > In any solution, SIP mobility needs to be limited > > > > > >only to the application > > > > > > > layer (not L3, L2, etc.). > > > > > > > > > > > > > > Best regards, > > > > > > > Radhika R. Roy > > > > > > > AT&T > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Michael Thomas [ mailto:mat@cisco.com > ] > > > > > > > Sent: Wednesday, September 27, 2000 12:32 PM > > > > > > > To: Lewis Karl-QA3387 > > > > > > > Cc: 'Henning Schulzrinne'; sip@lists.bell-labs.com > > > > > > > Subject: RE: [SIP] Attempt at summarizing current SIP drafts > > > > > > > > > > > > > > > > > > > > > > > > > > > > While I'm more than willing to believe that there > > > > > > > are mobility issues that SIP needs to deal with, > > > > > > > this paper seems to be positing SIP as the means > > > > > > > of initiating data sessions altogether. To my > > > > > > > mind, that's a rather bellheaded way of thinking > > > > > > > about how you do what amounts to L3 admission > > > > > > > control. In fact, the IETF already has an L3 > > > > > > > admission control mechanism: RSVP. RSVP's main > > > > > > > advantage is that it follows actual network > > > > > > > topology. SIP is at a distinct disadvantage since > > > > > > > all it knows about is the signaling path which > > > > > > > in normal circumstances has nothing to do with > > > > > > > the actual data path. > > > > > > > > > > > > > > Maybe I'm misreading this whole paper, but it sure > > > > > > > looks like it to me. If my interpretation is > > > > > > > right, however, I'd like to know if the intention > > > > > > > is to signal the access routers providing the > > > > > > > L2/L3 bits using SIP instead of, say, COPS (or > > > > > > > DIAMETER). If so, I'd say that SIP truly has > > > > > > > arrived at becoming the new millenium's kitchen > > > > > > > sink if this is accepted. > > > > > > > > > > > > > > Mike > > > > > > > > > > > > > > Lewis Karl-QA3387 writes: > > > > > > > > I have just reviewed the Mobility Related drafts > > > > > >and am wondering if > > > > > > > anyone > > > > > > > > is aware of the current status of > > > > > >draft-itsumo-sip -mobility-req-01. In > > > > > > > > particular, several issues were identified such > > > > > >as Mobile IP not being > > > > > > > > sufficient for personal mobility and location > > > > > >services, completing > > > > > > > > registration in less than a few seconds, > > > > > >reconfiguration in milliseconds, > > > > > > > > providing location services, support of inter > > > > > >domain soft-hand and secure > > > > > > > > signaling. Have these issues been addressed or > > > > > >actively being worked? > > > > > > > > > > > > > > > > Karl > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Henning Schulzrinne > > > > > [ mailto:schulzrinne@cs.columbia.edu > ] > > > > > > > Sent: Monday, September 25, 2000 9:20 AM > > > > > > > To: sip@lists.bell-labs.com > > > > > > > Subject: [SIP] Attempt at summarizing current SIP drafts > > > > > > > > > > > > > > > > > > > > > Given the proliferation of SIP-related drafts, I've > > > > > created a summary of > > > > > > > efforts at > > > > > http://www.cs.columbia.edu/~hgs/sip/drafts.html > . This is > > > > > > > known to be incomplete, so I'd appreciate if you could > > > > > send me any > > > > > > > additions or corrections. (Jonathan Rosenberg provided > > > > > some of the text; > > > > > > > any mistakes or misrepresentations are mine.) > > > > > > > > > > > > > > It is fairly clear that there are a large number of drafts > > > > > that have not > > > > > > > changed materially for half a year or more. Maybe it's > > > > > time to have a WG > > > > > > > last call or two or ten... > > > > > > > > > > > > > > Henning > > > > > > > -- > > > > > > > Henning Schulzrinne http://www.cs.columbia.edu/~hgs > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > SIP mailing list > > > > > > > SIP@lists.bell-labs.com > > > > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > SIP mailing list > > > > > > > SIP@lists.bell-labs.com > > > > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > SIP mailing list > > > > > > SIP@lists.bell-labs.com > > > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > > > > > > _______________________________________________ > > > > > > SIP mailing list > > > > > > SIP@lists.bell-labs.com > > > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > SIP mailing list > > > > > SIP@lists.bell-labs.com > > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > > > > > > > > > > > >_______________________________________________ > > > >SIP mailing list > > > >SIP@lists.bell-labs.com > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > >_______________________________________________ > > > >SIP mailing list > > > >SIP@lists.bell-labs.com > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > >_______________________________________________ >SIP mailing list >SIP@lists.bell-labs.com >http://lists.bell-labs.com/mailman/listinfo/sip > > > >_______________________________________________ >SIP mailing list >SIP@lists.bell-labs.com >http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 4 16:35:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA01271 for ; Wed, 4 Oct 2000 16:35:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E859E443C4; Wed, 4 Oct 2000 15:35:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ckmso1.proxy.att.com (ckmso1.att.com [12.20.58.69]) by lists.bell-labs.com (Postfix) with ESMTP id 3FAB644356 for ; Wed, 4 Oct 2000 15:34:39 -0400 (EDT) Received: from gab200r1.ems.att.com ([135.37.94.32]) by ckmso1.proxy.att.com (AT&T IPNS/MSO-2.2) with ESMTP id QAA10717; Wed, 4 Oct 2000 16:34:27 -0400 (EDT) Received: from njb140bh1.ems.att.com by gab200r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2) id QAA15411; Wed, 4 Oct 2000 16:36:28 -0400 (EDT) Received: by njb140bh1.ems.att.com with Internet Mail Service (5.5.2652.35) id ; Wed, 4 Oct 2000 16:34:25 -0400 Message-ID: From: "Roy, Radhika R, ALCOO" To: Rohan Mahy Cc: Brian Stucker , sip@lists.bell-labs.com Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP Mobility ) MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 4 Oct 2000 16:34:20 -0400 Hi, Rohan: Again, let us go back to the basic: SIP is a session initiation protocol. What needs to be done, if any, in the SIP layer if the point of attachment is changed during the session. Best regards, Radhika R. Roy AT&T -----Original Message----- From: Rohan Mahy [mailto:rohan@cisco.com] Sent: Wednesday, October 04, 2000 4:14 PM To: Roy, Radhika R, ALCOO Cc: Brian Stucker; sip@lists.bell-labs.com Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP Mobility ) At 10:51 AM 9/29/00 , Roy, Radhika R, ALCOO wrote: >Hi, Brian: > >I guess that your mail has provided some technical inputs: 1. Inter-session >mobility and 2. Intra-session mobility. > >For inter-session mobility, you think that SIP in OK. > >For intra-session mobility, it appears that you are feeling comfortable, as >if, SIP is not designed to do this. > >Let us go to the basic: SIP is a session initiation protocol. It is the >mandate of SIP. So, we like to see that it MUST deal with mobility as well *NO* !! Part of SIPs mandate is *personal* mobility, as a user moves from device to device. Personal mobility is a good, useful thing. However, The SIP charter does *NOT* include solving the problem of a device moving through different layer 2 networks. This is a problem for a layer 3 protocol to solve generically. If Mobile IP doesn't do what we need it to, then lets extend it, fix it, or replace it. thanks, -rohan >because people will use it in mobile environment (for both intra- and >inter-session). > >For inter-session, I guess that there may be some involvement of REGISTER >and re-INVITE messages (because of change in location). > >That's all! > >All works are done in the lower layer and SIP is not involved (for example, >some one in the lower layer will find that the location has been changed, >accordingly the upper layer may take some actions, if needed). > >Hope this will clarify the things. > >Best regards, >Radhika R. Roy >AT&T > >-----Original Message----- >From: Brian Stucker [mailto:bstucker@nortelnetworks.com] >Sent: Friday, September 29, 2000 1:19 PM >To: sip@lists.bell-labs.com >Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP Mobility ) > > > >My intent isn't to confuse anyone. Quite the contrary. > >My point is that SIP, as an application, should not be concerned about the >vagaries of the underlying media it's being carried on. All applications >that use IP as a transport are going to have to contend with mobility in the >IP space on the intra-session timescale. So IP should solve the problem >because it's a general problem for IP. > >SIP does enough to handle inter-session mobility (I'm at my desk, I'm at >home), and not impede intra-session mobility. It's just simply not suited >for handling anything else because of the nature of the protocol. Any >intra-session mobility must be handled out-of-band as far as SIP is >concerned, and SIP must not make any requirements that would impede this. > >Again, to use wireless voice calls as an example, even with dedicated >transport links, thousands of pages of standards with CDMA/TDMA, IS-41, SS7, >and TCAP, a mobile switching center doesn't attempt to do what you guys are >talking about. It doesn't update the location of a mobile once it's handed >over to another switch in the location database until after your call has >completed, and the mobile registers on the system it moved into. Why? >Because the mobile could be handed back over to the first system, the >handoff could fail, etc. So they don't even attempt to keep the exact >location of the mobile up to date outside of the original switch until the >mobile is stable again, when the call ends. Instead, all incoming calls go >to the first switch, and that switch knows where to go from there to get the >call completed. > >SIP shouldn't be updating the location database every time a wireless >terminal moves around. Some sort of mobile IP proxy function, should instead >be used that knows how to currently find the terminal in it's mobile-aware >IP space. It should route based on the inbound packet's IP address only, and >not care what the payload data is either. > >That solves the problem for SIP, HTTP, FTP, POP3, RTP, you name it. Why >write an extension to every protocol that uses IP as a transport (and have >it solved, and debugged a million different ways) instead of just fixing the >problem at the IP layer (and have it solved, and debugged one way)? > >Brian Stucker >Nortel Networks > >-----Original Message----- >From: Roy, Radhika R, ALCOO [ mailto:rrroy@att.com ] >Sent: Friday, September 29, 2000 11:39 AM >To: hammer michael; Michael Thomas; Henry Sinnreich >Cc: Lewis Karl-QA3387; 'Henning Schulzrinne'; sip@lists.bell-labs.com >Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP >Mobility ) > > >Hi, Everyone: > >The need for addressing mobility is clear and SIP is only one part of the >whole equation. > >Let us not confuse people in the name of Pandora's box or otherwise. > >We have to meet the needs solving problems (not to show our back). > >For the SIP WG, it is the SIP session layer that needs to be addressed, if >it turns out that is a need to do some works. > >Best regards, >Radhika R. Roy >AT&T > >-----Original Message----- >From: hammer michael [ mailto:mhammer@cisco.com ] > >Sent: Friday, September 29, 2000 1:57 PM >To: Roy, Radhika R, ALCOO; Michael Thomas; Henry Sinnreich >Cc: Lewis Karl-QA3387; 'Henning Schulzrinne'; sip@lists.bell-labs.com >Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP >Mobility ) > > >I think Brian aptly pointed out the Pandora's box you open with "mobility." >That should be sufficient motivation to avoid that type of mobility in SIP. > >We are talking about different timescales, e.g.: per packet, per call, and >per registration. > >I thought your term "discrete" captured the idea that the type of >"mobility" you refer to is of the: call me at the office, then later, call >me at home, I'm here now "mobility." Because mobility conjures up so many >more issues, I like the word "presence" better. Presence management may be >more descriptive that mobility management. > >Mike > > >At 04:11 PM 09/28/2000 -0400, Roy, Radhika R, ALCOO wrote: > >Hi, Mike: > > > >Yes, we will have problems if we do not define the terms accurately. > > > >Let us assume that we are using SIP (RFC 2543) and its session layer as our > > >reference. Location, registration, and session are defined in SIP. > > > >Paging (and probably "path") has not been defined in SIP. I will not argue > >to take this abstraction in the SIP layer for now. > > > >Point of attachment has been used as a generic term to indicate "address of > > >the attachment." If we translate this abstraction in the SIP layer, it will > > >mean the addresses that are being used in the SIP layer (e.g., E.164, IP > >address, etc.). > > > >Now let us examine your points: Presence of a person or terminal, etc. > > > >In the SIP layer, I guess, that the presence of a person on a terminal >needs > >to be abstracted in terms of an "address." If that address is also related > >to the point of attachment, then it will also be related to mobility. > > > >(A person behind the terminal may have another ID to deal with personal > >mobility. Let us not address that personal mobility for now.) > > > >In this way, we can extend our analysis for each layer. > > > >Does this answer your question? > > > >Best regards, > >Radhika R. Roy > >AT&T > > > >-----Original Message----- > >From: hammer michael [ mailto:mhammer@cisco.com >] > >Sent: Thursday, September 28, 2000 6:29 PM > >To: Roy, Radhika R, ALCOO; Michael Thomas; Henry Sinnreich > >Cc: Lewis Karl-QA3387; 'Henning Schulzrinne'; sip@lists.bell-labs.com > >Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP > >Mobility ) > > > > > >Roy, > > > >I need to be very careful what word I choose. Session connection rather > >than path might have been more appropriate. I believe confusion can occur > >if the type of location, registration, location, paging, etc. is not > >accurately defined. I think that the intent of such services revolves > >about maintaining relationships between certain elements, such as between: > > > >user/application and terminal, > >terminal and network end-point, > >network end-point and link end-point, etc. > > > >The act of "registering" may mean different things at different layers and > >use different mechanisms to accomplish them. The question for me is > >whether these are handled independently or does one mechanism attempt to > >manage multiple associations or would one type of registration trigger > >another type at a different layer? > > > >Would SIP then manage the "presence" of a person on a terminal, where > >something else manages the "presence" of a terminal on the network? > > > >Mike Hammer > > > > > >At 12:28 PM 09/28/2000 -0400, Roy, Radhika R, ALCOO wrote: > > >Hi, Mike: > > > > > >You have made excellent points. In fact, you are in the heart of this > > >problem: How the communications path(s) needs to be established as the > >point > > >of attachment is changed during the contiguous mobility. > > > > > >I personally believe that SIP does not need to be involved to set up the > > >communications path(s) per se. > > > > > >However, SIP needs to be used to set up the session: re-INVITE (to the >new > > >address) may need to be used. > > > > > >In the process, location updates, paging, etc. are also involved. If the > > >location update does not have any impact in the SIP layer, I do not think > > > >that SIP should be aware of any change in the lower layer. For example, > > >mobile IP has the power of providing location transparency of the IP >layer > > >(although it has some problems to meet the performance requirements for >the > > >real-time communications like voice). > > > > > >In addition to IP addresses, there are also transport addresses (e.g., >UDP, > > >TCP) for media. One also needs to be careful how to deal with the TCP > > >connection. IP addresses change, but the TCP connections still remains >the > > >same. An update mechanism needs to be defined. In turn, does it mean that > > > >this updated information may also be propagated to the SIP layer (other > > >members may also provide comments on this) because SIP does have the > > >abstraction of the transport address? > > > > > >I have not yet talked about the link layer. > > > > > >I am not trying to solve the mobility problem here. > > > > > >All I am trying to show: If we try to analyze the situation doing an > > >end-to-end analysis, we can easily see what needs to be done in each >layer. > > >Finally, we can answer the question: Whether or not any new work is >needed > > >in the SIP layer to address both discrete and continuos mobility. > > > > > >But you are right that we MUST keep the involvement of the SIP layer to a > > > >minimal level (if possible, we should avoid it) to address the mobility > > >problem. > > > > > >Best regards, > > >Radhika R. Roy > > >AT&T > > > > > >-----Original Message----- > > >From: hammer michael [ mailto:mhammer@cisco.com > ] > > >Sent: Thursday, September 28, 2000 2:41 PM > > >To: Roy, Radhika R, ALCOO; Michael Thomas; Henry Sinnreich > > >Cc: Lewis Karl-QA3387; 'Henning Schulzrinne'; sip@lists.bell-labs.com > > >Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP > > >Mobility ) > > > > > > > > >Roy, > > > > > >Your use of the terms "discrete" and "continuous" strike to the heart of > > >the issue. In traditional mobile networks, there is an attempt to move >the > > >stream of media with the terminal as it crosses cell boundaries > > >(continuous). There are many papers related to voice and mobile-IP that > > >address how to move the communications path. > > > > > >The discrete case is more an issue of identification of the presence and > > >availability of recipients and the establishment of communications to > > >them. Because names and addresses denoting physical location are often > > >blurred, in essence, personal mobility involves the creation and deletion > > > >of recipients rather than their movement. > > > > > >As I understand it, SIP does not move existing communications so much as >it > > >destroys existing communications paths and replaces them with new ones. >In > > >that respect, some of the traditional mobility issues such as handover >are > > >avoided, but others, e.g. location updates and paging are still needed. > > > > > >While the telcos reverted to addressing hardware-oriented terminal >mobility > > >in PCS, the softer personal mobility is still open to definition. The >same > > >issues have appeared in the net world and each will need to be solved in > > >their respective layers. > > > > > >Mike > > > > > > > > >At 11:01 AM 09/28/2000 -0400, Roy, Radhika R, ALCOO wrote: > > > >Hi, Mike: > > > > > > > >In fact, this is the precisely the test why SIP should be involved or >to > >be > > > >enhanced to support mobility (discrete + continuos) in the case of >Voice, > > > >chat, IM, messaging, conferencing, games, and others. > > > > > > > >If it is found that SIP does not need to be involved, I do not think >that > > > >anyone will force it to do this. > > > > > > > >By the way, do you not see that how SIP (RFC 2543) has taken care of >many > > > >aspects of users' discrete mobility? Has it not been be an excellent >way > >of > > > >involving SIP to solve a kind of mobility in the first place (what >other > > > >applications like H.323 is yet to support)? > > > > > > > >Along the same line, if people come up with the ideas that it is better > > >to > > > >enhance SIP functionality to support other aspects of mobility (if > > > >alternative solutions are not there or not acceptable), I do not think > >that > > > >we should have any objections. > > > > > > > >Let us keep our mind open and judge each proposal with its own merits. > > > > > > > >Best regards, > > > >Radhika R. Roy > > > >AT&T > > > > > > > >-----Original Message----- > > > >From: Michael Thomas [ mailto:mat@cisco.com ] > > > >Sent: Wednesday, September 27, 2000 7:01 PM > > > >To: Henry Sinnreich > > > >Cc: Michael Thomas; Roy, Radhika R, ALCOO; Lewis Karl-QA3387; 'Henning > > > >Schulzrinne'; sip@lists.bell-labs.com > > > >Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP > > > >Mobility ) > > > > > > > > > > > >Henry Sinnreich writes: > > > > > >what seems clear is that there are a > > > > > >number of applications which won't be able to do > > > > > >that for a variety of reasons. > > > > > > > > > > Voice, chat, IM, messaging, conferencing, games, etc., are > > > > > plenty of reasons to justify the SIP approach to mobility. > > > > > > > > But what if you could do all of the same things > > > > and not need to modify or involve SIP and have the > > > > additional gain that things like http worked as well? > > > > > > > > Mike > > > > > > > > > > > > > > Henry > > > > > > > > > > >-----Original Message----- > > > > > >From: sip-admin@lists.bell-labs.com > > > > > >[ mailto:sip-admin@lists.bell-labs.com > ]On Behalf Of > > > > > >Michael Thomas > > > > > >Sent: Wednesday, September 27, 2000 8:33 PM > > > > > >To: Roy, Radhika R, ALCOO > > > > > >Cc: Michael Thomas; Lewis Karl-QA3387; 'Henning Schulzrinne'; > > > > > >sip@lists.bell-labs.com > > > > > >Subject: RE: [SIP] Attempt at summarizing current SIP > > > > > >drafts (SIP > > > > > >Mobility ) > > > > > > > > > > > > > > > > > > > > > > > >I guess what I'm having a hard time with is the > > > > > >starting point that assumes that SIP based > > > > > >application mobility is Good Thing. While it's > > > > > >clear that many applications *could* design in > > > > > >mobility, what seems clear is that there are a > > > > > >number of applications which won't be able to do > > > > > >that for a variety of reasons. Assuming that those > > > > > >applications are important too, then we're already > > > > > >stuck with needing to solve for the general > > > > > >problem. > > > > > > > > > > > >Starting out with the assumption that Mobile IP > > > > > >addresses the more general problem seems > > > > > >attractive because a good solution with fast > > > > > >handoff that addresses AAA and QoS would solve > > > > > >most of the application layer problems in a > > > > > >general way rather than just a SIP specific > > > > > >way. > > > > > > > > > > > >There also seems to be an implicit assumption in > > > > > >the draft of linkage of SIP to a AAA function. > > > > > >I'm going to guess that it is along the same line > > > > > >of thinking of the DQoS gate controller idea. The > > > > > >problem I have with that is that it is in the end > > > > > >an optimization on the normal RSVP/COPS pull > > > > > >model. However, things that don't fit into that > > > > > >model still have the non-optimized way of doing > > > > > >QoS authorization. That's probably not the fault > > > > > >of this draft, but it does seem to make the entire > > > > > >draft a cart-before-horse situation. > > > > > > > > > > > > Mike > > > > > > > > > > > >Roy, Radhika R, ALCOO writes: > > > > > > > Hi, Mike: > > > > > > > > > > > > > > I guess that SIP, as you rightly pointed out, is > > > > > >dealing with the signaling > > > > > > > mechanism in the application layer. So, SIP does > > > > > >not need to deal with L3 > > > > > > > media path. > > > > > > > > > > > > > > SIP does deal with addresses of the source and > > > > > >destination(s). > > > > > > > > > > > > > > In mobile environment, the point of attachment > > > > > >(i.e., addresses) changes: 1. > > > > > > > Between the sessions (discrete mobility) and 2. > > > > > >During the session > > > > > > > (continuous mobility). > > > > > > > > > > > > > > The problem that is being addressed is: What is the > > > > > >impact in SIP layer due > > > > > > > to these two kinds of mobility. > > > > > > > > > > > > > > I guess that for discrete mobility, SIP has > > > > > >probably addressed most of the > > > > > > > problems (others may also provide comments on this). > > > > > > > > > > > > > > For continuous mobility, there may need (or may > > > > > >not??) some works in the SIP > > > > > > > layer, if any (others may also provide comments). > > > > > > > > > > > > > > However, SIP can only address the mobility related > > > > > >problems in the > > > > > > > application layer. This alone may not be enough to > > > > > >solve all problems > > > > > > > because some L3 and L2 problems may also need to be > > > > > >addressed at the same > > > > > > > time to have the complete solution. > > > > > > > > > > > > > > In any solution, SIP mobility needs to be limited > > > > > >only to the application > > > > > > > layer (not L3, L2, etc.). > > > > > > > > > > > > > > Best regards, > > > > > > > Radhika R. Roy > > > > > > > AT&T > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Michael Thomas [ mailto:mat@cisco.com > ] > > > > > > > Sent: Wednesday, September 27, 2000 12:32 PM > > > > > > > To: Lewis Karl-QA3387 > > > > > > > Cc: 'Henning Schulzrinne'; sip@lists.bell-labs.com > > > > > > > Subject: RE: [SIP] Attempt at summarizing current SIP drafts > > > > > > > > > > > > > > > > > > > > > > > > > > > > While I'm more than willing to believe that there > > > > > > > are mobility issues that SIP needs to deal with, > > > > > > > this paper seems to be positing SIP as the means > > > > > > > of initiating data sessions altogether. To my > > > > > > > mind, that's a rather bellheaded way of thinking > > > > > > > about how you do what amounts to L3 admission > > > > > > > control. In fact, the IETF already has an L3 > > > > > > > admission control mechanism: RSVP. RSVP's main > > > > > > > advantage is that it follows actual network > > > > > > > topology. SIP is at a distinct disadvantage since > > > > > > > all it knows about is the signaling path which > > > > > > > in normal circumstances has nothing to do with > > > > > > > the actual data path. > > > > > > > > > > > > > > Maybe I'm misreading this whole paper, but it sure > > > > > > > looks like it to me. If my interpretation is > > > > > > > right, however, I'd like to know if the intention > > > > > > > is to signal the access routers providing the > > > > > > > L2/L3 bits using SIP instead of, say, COPS (or > > > > > > > DIAMETER). If so, I'd say that SIP truly has > > > > > > > arrived at becoming the new millenium's kitchen > > > > > > > sink if this is accepted. > > > > > > > > > > > > > > Mike > > > > > > > > > > > > > > Lewis Karl-QA3387 writes: > > > > > > > > I have just reviewed the Mobility Related drafts > > > > > >and am wondering if > > > > > > > anyone > > > > > > > > is aware of the current status of > > > > > >draft-itsumo-sip -mobility-req-01. In > > > > > > > > particular, several issues were identified such > > > > > >as Mobile IP not being > > > > > > > > sufficient for personal mobility and location > > > > > >services, completing > > > > > > > > registration in less than a few seconds, > > > > > >reconfiguration in milliseconds, > > > > > > > > providing location services, support of inter > > > > > >domain soft-hand and secure > > > > > > > > signaling. Have these issues been addressed or > > > > > >actively being worked? > > > > > > > > > > > > > > > > Karl > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Henning Schulzrinne > > > > > [ mailto:schulzrinne@cs.columbia.edu > ] > > > > > > > Sent: Monday, September 25, 2000 9:20 AM > > > > > > > To: sip@lists.bell-labs.com > > > > > > > Subject: [SIP] Attempt at summarizing current SIP drafts > > > > > > > > > > > > > > > > > > > > > Given the proliferation of SIP-related drafts, I've > > > > > created a summary of > > > > > > > efforts at > > > > > http://www.cs.columbia.edu/~hgs/sip/drafts.html > . This is > > > > > > > known to be incomplete, so I'd appreciate if you could > > > > > send me any > > > > > > > additions or corrections. (Jonathan Rosenberg provided > > > > > some of the text; > > > > > > > any mistakes or misrepresentations are mine.) > > > > > > > > > > > > > > It is fairly clear that there are a large number of drafts > > > > > that have not > > > > > > > changed materially for half a year or more. Maybe it's > > > > > time to have a WG > > > > > > > last call or two or ten... > > > > > > > > > > > > > > Henning > > > > > > > -- > > > > > > > Henning Schulzrinne http://www.cs.columbia.edu/~hgs > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > SIP mailing list > > > > > > > SIP@lists.bell-labs.com > > > > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > SIP mailing list > > > > > > > SIP@lists.bell-labs.com > > > > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > SIP mailing list > > > > > > SIP@lists.bell-labs.com > > > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > > > > > > _______________________________________________ > > > > > > SIP mailing list > > > > > > SIP@lists.bell-labs.com > > > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > SIP mailing list > > > > > SIP@lists.bell-labs.com > > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > > > > > > > > > > > >_______________________________________________ > > > >SIP mailing list > > > >SIP@lists.bell-labs.com > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > >_______________________________________________ > > > >SIP mailing list > > > >SIP@lists.bell-labs.com > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > >_______________________________________________ >SIP mailing list >SIP@lists.bell-labs.com >http://lists.bell-labs.com/mailman/listinfo/sip > > > >_______________________________________________ >SIP mailing list >SIP@lists.bell-labs.com >http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 4 16:47:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA01378 for ; Wed, 4 Oct 2000 16:47:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6A94F443DF; Wed, 4 Oct 2000 15:47:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from wusr3.mobilerain.com (sdsl-208-185-234-252.dsl.sjc.megapath.net [208.185.234.252]) by lists.bell-labs.com (Postfix) with ESMTP id C7E73443A9 for ; Wed, 4 Oct 2000 15:46:15 -0400 (EDT) Received: from mobilerain.com (IDENT:dsardana@localhost [127.0.0.1]) by wusr3.mobilerain.com (8.9.3/8.9.3) with ESMTP id NAA03927; Wed, 4 Oct 2000 13:44:47 -0700 Message-ID: <39DB96BE.C49B60F1@mobilerain.com> From: Bobby Sardana Organization: MobileRain Technologies, Inc. X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: "Roy, Radhika R, ALCOO" Cc: Rohan Mahy , Brian Stucker , sip@lists.bell-labs.com Subject: Re: [SIP] Attempt at summarizing current SIP drafts (SIP Mobility) References: Content-Type: multipart/mixed; boundary="------------C960EDD20F0CABA4964B4FF2" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 04 Oct 2000 13:44:47 -0700 This is a multi-part message in MIME format. --------------C960EDD20F0CABA4964B4FF2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello Radhika: "Roy, Radhika R, ALCOO" wrote: > Hi, Rohan: > > Again, let us go back to the basic: > > SIP is a session initiation protocol. What needs to be done, if any, in the > SIP layer if the point of attachment is changed during the session. IMHO, nothing should be done. Application layer protocols should be transparent to IP mobility changes which is a layer 3 problem. Regards, Bobby.Sardana@mobilerain.com > > > Best regards, > Radhika R. Roy > AT&T > > -----Original Message----- > From: Rohan Mahy [mailto:rohan@cisco.com] > Sent: Wednesday, October 04, 2000 4:14 PM > To: Roy, Radhika R, ALCOO > Cc: Brian Stucker; sip@lists.bell-labs.com > Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP > Mobility ) > > At 10:51 AM 9/29/00 , Roy, Radhika R, ALCOO wrote: > >Hi, Brian: > > > >I guess that your mail has provided some technical inputs: 1. Inter-session > >mobility and 2. Intra-session mobility. > > > >For inter-session mobility, you think that SIP in OK. > > > >For intra-session mobility, it appears that you are feeling comfortable, as > >if, SIP is not designed to do this. > > > >Let us go to the basic: SIP is a session initiation protocol. It is the > >mandate of SIP. So, we like to see that it MUST deal with mobility as well > > *NO* !! Part of SIPs mandate is *personal* mobility, as a user moves from > device to device. Personal mobility is a good, useful thing. However, The > SIP charter does *NOT* include solving the problem of a device moving > through different layer 2 networks. This is a problem for a layer 3 > protocol to solve generically. If Mobile IP doesn't do what we need it to, > then lets extend it, fix it, or replace it. > > thanks, > -rohan > > >because people will use it in mobile environment (for both intra- and > >inter-session). > > > > >For inter-session, I guess that there may be some involvement of REGISTER > >and re-INVITE messages (because of change in location). > > > >That's all! > > > >All works are done in the lower layer and SIP is not involved (for example, > >some one in the lower layer will find that the location has been changed, > >accordingly the upper layer may take some actions, if needed). > > > >Hope this will clarify the things. > > > >Best regards, > >Radhika R. Roy > >AT&T > > > >-----Original Message----- > >From: Brian Stucker [mailto:bstucker@nortelnetworks.com] > >Sent: Friday, September 29, 2000 1:19 PM > >To: sip@lists.bell-labs.com > >Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP Mobility > ) > > > > > > > >My intent isn't to confuse anyone. Quite the contrary. > > > >My point is that SIP, as an application, should not be concerned about the > >vagaries of the underlying media it's being carried on. All applications > >that use IP as a transport are going to have to contend with mobility in > the > >IP space on the intra-session timescale. So IP should solve the problem > >because it's a general problem for IP. > > > >SIP does enough to handle inter-session mobility (I'm at my desk, I'm at > >home), and not impede intra-session mobility. It's just simply not suited > >for handling anything else because of the nature of the protocol. Any > >intra-session mobility must be handled out-of-band as far as SIP is > >concerned, and SIP must not make any requirements that would impede this. > > > >Again, to use wireless voice calls as an example, even with dedicated > >transport links, thousands of pages of standards with CDMA/TDMA, IS-41, > SS7, > >and TCAP, a mobile switching center doesn't attempt to do what you guys are > >talking about. It doesn't update the location of a mobile once it's handed > >over to another switch in the location database until after your call has > >completed, and the mobile registers on the system it moved into. Why? > >Because the mobile could be handed back over to the first system, the > >handoff could fail, etc. So they don't even attempt to keep the exact > >location of the mobile up to date outside of the original switch until the > >mobile is stable again, when the call ends. Instead, all incoming calls go > >to the first switch, and that switch knows where to go from there to get > the > >call completed. > > > >SIP shouldn't be updating the location database every time a wireless > >terminal moves around. Some sort of mobile IP proxy function, should > instead > >be used that knows how to currently find the terminal in it's mobile-aware > >IP space. It should route based on the inbound packet's IP address only, > and > >not care what the payload data is either. > > > >That solves the problem for SIP, HTTP, FTP, POP3, RTP, you name it. Why > >write an extension to every protocol that uses IP as a transport (and have > >it solved, and debugged a million different ways) instead of just fixing > the > >problem at the IP layer (and have it solved, and debugged one way)? > > > >Brian Stucker > >Nortel Networks > > > >-----Original Message----- > >From: Roy, Radhika R, ALCOO [ mailto:rrroy@att.com ] > >Sent: Friday, September 29, 2000 11:39 AM > >To: hammer michael; Michael Thomas; Henry Sinnreich > >Cc: Lewis Karl-QA3387; 'Henning Schulzrinne'; sip@lists.bell-labs.com > >Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP > >Mobility ) > > > > > >Hi, Everyone: > > > >The need for addressing mobility is clear and SIP is only one part of the > >whole equation. > > > >Let us not confuse people in the name of Pandora's box or otherwise. > > > >We have to meet the needs solving problems (not to show our back). > > > >For the SIP WG, it is the SIP session layer that needs to be addressed, if > >it turns out that is a need to do some works. > > > >Best regards, > >Radhika R. Roy > >AT&T > > > >-----Original Message----- > >From: hammer michael [ mailto:mhammer@cisco.com > ] > > > >Sent: Friday, September 29, 2000 1:57 PM > >To: Roy, Radhika R, ALCOO; Michael Thomas; Henry Sinnreich > >Cc: Lewis Karl-QA3387; 'Henning Schulzrinne'; sip@lists.bell-labs.com > >Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP > >Mobility ) > > > > > >I think Brian aptly pointed out the Pandora's box you open with "mobility." > >That should be sufficient motivation to avoid that type of mobility in SIP. > > > >We are talking about different timescales, e.g.: per packet, per call, and > >per registration. > > > >I thought your term "discrete" captured the idea that the type of > >"mobility" you refer to is of the: call me at the office, then later, call > >me at home, I'm here now "mobility." Because mobility conjures up so many > >more issues, I like the word "presence" better. Presence management may be > >more descriptive that mobility management. > > > >Mike > > > > > >At 04:11 PM 09/28/2000 -0400, Roy, Radhika R, ALCOO wrote: > > >Hi, Mike: > > > > > >Yes, we will have problems if we do not define the terms accurately. > > > > > >Let us assume that we are using SIP (RFC 2543) and its session layer as > our > > > > >reference. Location, registration, and session are defined in SIP. > > > > > >Paging (and probably "path") has not been defined in SIP. I will not > argue > > >to take this abstraction in the SIP layer for now. > > > > > >Point of attachment has been used as a generic term to indicate "address > of > > > > >the attachment." If we translate this abstraction in the SIP layer, it > will > > > > >mean the addresses that are being used in the SIP layer (e.g., E.164, IP > > >address, etc.). > > > > > >Now let us examine your points: Presence of a person or terminal, etc. > > > > > >In the SIP layer, I guess, that the presence of a person on a terminal > >needs > > >to be abstracted in terms of an "address." If that address is also > related > > >to the point of attachment, then it will also be related to mobility. > > > > > >(A person behind the terminal may have another ID to deal with personal > > >mobility. Let us not address that personal mobility for now.) > > > > > >In this way, we can extend our analysis for each layer. > > > > > >Does this answer your question? > > > > > >Best regards, > > >Radhika R. Roy > > >AT&T > > > > > >-----Original Message----- > > >From: hammer michael [ mailto:mhammer@cisco.com > > >] > > >Sent: Thursday, September 28, 2000 6:29 PM > > >To: Roy, Radhika R, ALCOO; Michael Thomas; Henry Sinnreich > > >Cc: Lewis Karl-QA3387; 'Henning Schulzrinne'; sip@lists.bell-labs.com > > >Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP > > >Mobility ) > > > > > > > > >Roy, > > > > > >I need to be very careful what word I choose. Session connection rather > > >than path might have been more appropriate. I believe confusion can > occur > > >if the type of location, registration, location, paging, etc. is not > > >accurately defined. I think that the intent of such services revolves > > >about maintaining relationships between certain elements, such as > between: > > > > > >user/application and terminal, > > >terminal and network end-point, > > >network end-point and link end-point, etc. > > > > > >The act of "registering" may mean different things at different layers > and > > >use different mechanisms to accomplish them. The question for me is > > >whether these are handled independently or does one mechanism attempt to > > >manage multiple associations or would one type of registration trigger > > >another type at a different layer? > > > > > >Would SIP then manage the "presence" of a person on a terminal, where > > >something else manages the "presence" of a terminal on the network? > > > > > >Mike Hammer > > > > > > > > >At 12:28 PM 09/28/2000 -0400, Roy, Radhika R, ALCOO wrote: > > > >Hi, Mike: > > > > > > > >You have made excellent points. In fact, you are in the heart of this > > > >problem: How the communications path(s) needs to be established as the > > >point > > > >of attachment is changed during the contiguous mobility. > > > > > > > >I personally believe that SIP does not need to be involved to set up > the > > > >communications path(s) per se. > > > > > > > >However, SIP needs to be used to set up the session: re-INVITE (to the > >new > > > >address) may need to be used. > > > > > > > >In the process, location updates, paging, etc. are also involved. If > the > > > >location update does not have any impact in the SIP layer, I do not > think > > > > > >that SIP should be aware of any change in the lower layer. For example, > > > >mobile IP has the power of providing location transparency of the IP > >layer > > > >(although it has some problems to meet the performance requirements for > >the > > > >real-time communications like voice). > > > > > > > >In addition to IP addresses, there are also transport addresses (e.g., > >UDP, > > > >TCP) for media. One also needs to be careful how to deal with the TCP > > > >connection. IP addresses change, but the TCP connections still remains > >the > > > >same. An update mechanism needs to be defined. In turn, does it mean > that > > > > > >this updated information may also be propagated to the SIP layer (other > > > >members may also provide comments on this) because SIP does have the > > > >abstraction of the transport address? > > > > > > > >I have not yet talked about the link layer. > > > > > > > >I am not trying to solve the mobility problem here. > > > > > > > >All I am trying to show: If we try to analyze the situation doing an > > > >end-to-end analysis, we can easily see what needs to be done in each > >layer. > > > >Finally, we can answer the question: Whether or not any new work is > >needed > > > >in the SIP layer to address both discrete and continuos mobility. > > > > > > > >But you are right that we MUST keep the involvement of the SIP layer to > a > > > > > >minimal level (if possible, we should avoid it) to address the mobility > > > >problem. > > > > > > > >Best regards, > > > >Radhika R. Roy > > > >AT&T > > > > > > > >-----Original Message----- > > > >From: hammer michael [ mailto:mhammer@cisco.com > > ] > > > >Sent: Thursday, September 28, 2000 2:41 PM > > > >To: Roy, Radhika R, ALCOO; Michael Thomas; Henry Sinnreich > > > >Cc: Lewis Karl-QA3387; 'Henning Schulzrinne'; sip@lists.bell-labs.com > > > >Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP > > > >Mobility ) > > > > > > > > > > > >Roy, > > > > > > > >Your use of the terms "discrete" and "continuous" strike to the heart > of > > > >the issue. In traditional mobile networks, there is an attempt to move > >the > > > >stream of media with the terminal as it crosses cell boundaries > > > >(continuous). There are many papers related to voice and mobile-IP > that > > > >address how to move the communications path. > > > > > > > >The discrete case is more an issue of identification of the presence > and > > > >availability of recipients and the establishment of communications to > > > >them. Because names and addresses denoting physical location are often > > > >blurred, in essence, personal mobility involves the creation and > deletion > > > > > >of recipients rather than their movement. > > > > > > > >As I understand it, SIP does not move existing communications so much > as > >it > > > >destroys existing communications paths and replaces them with new ones. > >In > > > >that respect, some of the traditional mobility issues such as handover > >are > > > >avoided, but others, e.g. location updates and paging are still needed. > > > > > > > >While the telcos reverted to addressing hardware-oriented terminal > >mobility > > > >in PCS, the softer personal mobility is still open to definition. The > >same > > > >issues have appeared in the net world and each will need to be solved > in > > > >their respective layers. > > > > > > > >Mike > > > > > > > > > > > >At 11:01 AM 09/28/2000 -0400, Roy, Radhika R, ALCOO wrote: > > > > >Hi, Mike: > > > > > > > > > >In fact, this is the precisely the test why SIP should be involved or > >to > > >be > > > > >enhanced to support mobility (discrete + continuos) in the case of > >Voice, > > > > >chat, IM, messaging, conferencing, games, and others. > > > > > > > > > >If it is found that SIP does not need to be involved, I do not think > >that > > > > >anyone will force it to do this. > > > > > > > > > >By the way, do you not see that how SIP (RFC 2543) has taken care of > >many > > > > >aspects of users' discrete mobility? Has it not been be an excellent > >way > > >of > > > > >involving SIP to solve a kind of mobility in the first place (what > >other > > > > >applications like H.323 is yet to support)? > > > > > > > > > >Along the same line, if people come up with the ideas that it is > better > > > > >to > > > > >enhance SIP functionality to support other aspects of mobility (if > > > > >alternative solutions are not there or not acceptable), I do not > think > > >that > > > > >we should have any objections. > > > > > > > > > >Let us keep our mind open and judge each proposal with its own > merits. > > > > > > > > > >Best regards, > > > > >Radhika R. Roy > > > > >AT&T > > > > > > > > > >-----Original Message----- > > > > >From: Michael Thomas [ mailto:mat@cisco.com ] > > > > >Sent: Wednesday, September 27, 2000 7:01 PM > > > > >To: Henry Sinnreich > > > > >Cc: Michael Thomas; Roy, Radhika R, ALCOO; Lewis Karl-QA3387; > 'Henning > > > > >Schulzrinne'; sip@lists.bell-labs.com > > > > >Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP > > > > >Mobility ) > > > > > > > > > > > > > > >Henry Sinnreich writes: > > > > > > >what seems clear is that there are a > > > > > > >number of applications which won't be able to do > > > > > > >that for a variety of reasons. > > > > > > > > > > > > Voice, chat, IM, messaging, conferencing, games, etc., are > > > > > > plenty of reasons to justify the SIP approach to mobility. > > > > > > > > > > But what if you could do all of the same things > > > > > and not need to modify or involve SIP and have the > > > > > additional gain that things like http worked as well? > > > > > > > > > > Mike > > > > > > > > > > > > > > > > > Henry > > > > > > > > > > > > >-----Original Message----- > > > > > > >From: sip-admin@lists.bell-labs.com > > > > > > >[ mailto:sip-admin@lists.bell-labs.com > > ]On Behalf Of > > > > > > >Michael Thomas > > > > > > >Sent: Wednesday, September 27, 2000 8:33 PM > > > > > > >To: Roy, Radhika R, ALCOO > > > > > > >Cc: Michael Thomas; Lewis Karl-QA3387; 'Henning Schulzrinne'; > > > > > > >sip@lists.bell-labs.com > > > > > > >Subject: RE: [SIP] Attempt at summarizing current SIP > > > > > > >drafts (SIP > > > > > > >Mobility ) > > > > > > > > > > > > > > > > > > > > > > > > > > > >I guess what I'm having a hard time with is the > > > > > > >starting point that assumes that SIP based > > > > > > >application mobility is Good Thing. While it's > > > > > > >clear that many applications *could* design in > > > > > > >mobility, what seems clear is that there are a > > > > > > >number of applications which won't be able to do > > > > > > >that for a variety of reasons. Assuming that those > > > > > > >applications are important too, then we're already > > > > > > >stuck with needing to solve for the general > > > > > > >problem. > > > > > > > > > > > > > >Starting out with the assumption that Mobile IP > > > > > > >addresses the more general problem seems > > > > > > >attractive because a good solution with fast > > > > > > >handoff that addresses AAA and QoS would solve > > > > > > >most of the application layer problems in a > > > > > > >general way rather than just a SIP specific > > > > > > >way. > > > > > > > > > > > > > >There also seems to be an implicit assumption in > > > > > > >the draft of linkage of SIP to a AAA function. > > > > > > >I'm going to guess that it is along the same line > > > > > > >of thinking of the DQoS gate controller idea. The > > > > > > >problem I have with that is that it is in the end > > > > > > >an optimization on the normal RSVP/COPS pull > > > > > > >model. However, things that don't fit into that > > > > > > >model still have the non-optimized way of doing > > > > > > >QoS authorization. That's probably not the fault > > > > > > >of this draft, but it does seem to make the entire > > > > > > >draft a cart-before-horse situation. > > > > > > > > > > > > > > Mike > > > > > > > > > > > > > >Roy, Radhika R, ALCOO writes: > > > > > > > > Hi, Mike: > > > > > > > > > > > > > > > > I guess that SIP, as you rightly pointed out, is > > > > > > >dealing with the signaling > > > > > > > > mechanism in the application layer. So, SIP does > > > > > > >not need to deal with L3 > > > > > > > > media path. > > > > > > > > > > > > > > > > SIP does deal with addresses of the source and > > > > > > >destination(s). > > > > > > > > > > > > > > > > In mobile environment, the point of attachment > > > > > > >(i.e., addresses) changes: 1. > > > > > > > > Between the sessions (discrete mobility) and 2. > > > > > > >During the session > > > > > > > > (continuous mobility). > > > > > > > > > > > > > > > > The problem that is being addressed is: What is the > > > > > > >impact in SIP layer due > > > > > > > > to these two kinds of mobility. > > > > > > > > > > > > > > > > I guess that for discrete mobility, SIP has > > > > > > >probably addressed most of the > > > > > > > > problems (others may also provide comments on this). > > > > > > > > > > > > > > > > For continuous mobility, there may need (or may > > > > > > >not??) some works in the SIP > > > > > > > > layer, if any (others may also provide comments). > > > > > > > > > > > > > > > > However, SIP can only address the mobility related > > > > > > >problems in the > > > > > > > > application layer. This alone may not be enough to > > > > > > >solve all problems > > > > > > > > because some L3 and L2 problems may also need to be > > > > > > >addressed at the same > > > > > > > > time to have the complete solution. > > > > > > > > > > > > > > > > In any solution, SIP mobility needs to be limited > > > > > > >only to the application > > > > > > > > layer (not L3, L2, etc.). > > > > > > > > > > > > > > > > Best regards, > > > > > > > > Radhika R. Roy > > > > > > > > AT&T > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Michael Thomas [ mailto:mat@cisco.com > > ] > > > > > > > > Sent: Wednesday, September 27, 2000 12:32 PM > > > > > > > > To: Lewis Karl-QA3387 > > > > > > > > Cc: 'Henning Schulzrinne'; sip@lists.bell-labs.com > > > > > > > > Subject: RE: [SIP] Attempt at summarizing current SIP drafts > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > While I'm more than willing to believe that there > > > > > > > > are mobility issues that SIP needs to deal with, > > > > > > > > this paper seems to be positing SIP as the means > > > > > > > > of initiating data sessions altogether. To my > > > > > > > > mind, that's a rather bellheaded way of thinking > > > > > > > > about how you do what amounts to L3 admission > > > > > > > > control. In fact, the IETF already has an L3 > > > > > > > > admission control mechanism: RSVP. RSVP's main > > > > > > > > advantage is that it follows actual network > > > > > > > > topology. SIP is at a distinct disadvantage since > > > > > > > > all it knows about is the signaling path which > > > > > > > > in normal circumstances has nothing to do with > > > > > > > > the actual data path. > > > > > > > > > > > > > > > > Maybe I'm misreading this whole paper, but it sure > > > > > > > > looks like it to me. If my interpretation is > > > > > > > > right, however, I'd like to know if the intention > > > > > > > > is to signal the access routers providing the > > > > > > > > L2/L3 bits using SIP instead of, say, COPS (or > > > > > > > > DIAMETER). If so, I'd say that SIP truly has > > > > > > > > arrived at becoming the new millenium's kitchen > > > > > > > > sink if this is accepted. > > > > > > > > > > > > > > > > Mike > > > > > > > > > > > > > > > > Lewis Karl-QA3387 writes: > > > > > > > > > I have just reviewed the Mobility Related drafts > > > > > > >and am wondering if > > > > > > > > anyone > > > > > > > > > is aware of the current status of > > > > > > >draft-itsumo-sip -mobility-req-01. In > > > > > > > > > particular, several issues were identified such > > > > > > >as Mobile IP not being > > > > > > > > > sufficient for personal mobility and location > > > > > > >services, completing > > > > > > > > > registration in less than a few seconds, > > > > > > >reconfiguration in milliseconds, > > > > > > > > > providing location services, support of inter > > > > > > >domain soft-hand and secure > > > > > > > > > signaling. Have these issues been addressed or > > > > > > >actively being worked? > > > > > > > > > > > > > > > > > > Karl > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Henning Schulzrinne > > > > > > [ mailto:schulzrinne@cs.columbia.edu > > ] > > > > > > > > Sent: Monday, September 25, 2000 9:20 AM > > > > > > > > To: sip@lists.bell-labs.com > > > > > > > > Subject: [SIP] Attempt at summarizing current SIP drafts > > > > > > > > > > > > > > > > > > > > > > > > Given the proliferation of SIP-related drafts, I've > > > > > > created a summary of > > > > > > > > efforts at > > > > > > http://www.cs.columbia.edu/~hgs/sip/drafts.html > > . This is > > > > > > > > known to be incomplete, so I'd appreciate if you could > > > > > > send me any > > > > > > > > additions or corrections. (Jonathan Rosenberg provided > > > > > > some of the text; > > > > > > > > any mistakes or misrepresentations are mine.) > > > > > > > > > > > > > > > > It is fairly clear that there are a large number of drafts > > > > > > that have not > > > > > > > > changed materially for half a year or more. Maybe it's > > > > > > time to have a WG > > > > > > > > last call or two or ten... > > > > > > > > > > > > > > > > Henning > > > > > > > > -- > > > > > > > > Henning Schulzrinne http://www.cs.columbia.edu/~hgs > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > SIP mailing list > > > > > > > > SIP@lists.bell-labs.com > > > > > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > SIP mailing list > > > > > > > > SIP@lists.bell-labs.com > > > > > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > SIP mailing list > > > > > > > SIP@lists.bell-labs.com > > > > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > SIP mailing list > > > > > > > SIP@lists.bell-labs.com > > > > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > SIP mailing list > > > > > > SIP@lists.bell-labs.com > > > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > > > > > > > > > > > > > > > > >_______________________________________________ > > > > >SIP mailing list > > > > >SIP@lists.bell-labs.com > > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > > > > >_______________________________________________ > > > > >SIP mailing list > > > > >SIP@lists.bell-labs.com > > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > >_______________________________________________ > >SIP mailing list > >SIP@lists.bell-labs.com > >http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > >_______________________________________________ > >SIP mailing list > >SIP@lists.bell-labs.com > >http://lists.bell-labs.com/mailman/listinfo/sip > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip --------------C960EDD20F0CABA4964B4FF2 Content-Type: text/x-vcard; charset=us-ascii; name="bobby.sardana.vcf" Content-Description: Card for Bobby Sardana Content-Disposition: attachment; filename="bobby.sardana.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Sardana;Bobby x-mozilla-html:FALSE org:MobileRain Technologies, Inc.;Telecommunications adr:;;;;;; version:2.1 email;internet:bobby.sardana@mobilerain.com title:Engineer x-mozilla-cpt:;0 fn:Bobby Sardana end:vcard --------------C960EDD20F0CABA4964B4FF2-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 4 16:57:00 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA01591 for ; Wed, 4 Oct 2000 16:57:00 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id AB1CE443E5; Wed, 4 Oct 2000 15:57:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by lists.bell-labs.com (Postfix) with ESMTP id DF5D844356 for ; Wed, 4 Oct 2000 15:56:49 -0400 (EDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (motgate 2.1) with ESMTP id NAA09547 for ; Wed, 4 Oct 2000 13:56:45 -0700 (MST)] Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id NAA21168 for ; Wed, 4 Oct 2000 13:56:45 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2650.21) id ; Wed, 4 Oct 2000 15:56:45 -0500 Message-ID: From: Lewis Karl-QA3387 To: sip@lists.bell-labs.com Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP Mobility ) MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 4 Oct 2000 15:56:36 -0500 MobileIP is addressing this issue with drafts such as draft-elmalki-mobileip-fast-handoffs-03.txt and draft-soliman-mobileip-hmipv6-01.txt. -----Original Message----- From: Roy, Radhika R, ALCOO [mailto:rrroy@att.com] Sent: Wednesday, October 04, 2000 3:34 PM To: Rohan Mahy Cc: Brian Stucker; sip@lists.bell-labs.com Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP Mobility ) Hi, Rohan: Again, let us go back to the basic: SIP is a session initiation protocol. What needs to be done, if any, in the SIP layer if the point of attachment is changed during the session. Best regards, Radhika R. Roy AT&T -----Original Message----- From: Rohan Mahy [mailto:rohan@cisco.com] Sent: Wednesday, October 04, 2000 4:14 PM To: Roy, Radhika R, ALCOO Cc: Brian Stucker; sip@lists.bell-labs.com Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP Mobility ) At 10:51 AM 9/29/00 , Roy, Radhika R, ALCOO wrote: >Hi, Brian: > >I guess that your mail has provided some technical inputs: 1. Inter-session >mobility and 2. Intra-session mobility. > >For inter-session mobility, you think that SIP in OK. > >For intra-session mobility, it appears that you are feeling comfortable, as >if, SIP is not designed to do this. > >Let us go to the basic: SIP is a session initiation protocol. It is the >mandate of SIP. So, we like to see that it MUST deal with mobility as well *NO* !! Part of SIPs mandate is *personal* mobility, as a user moves from device to device. Personal mobility is a good, useful thing. However, The SIP charter does *NOT* include solving the problem of a device moving through different layer 2 networks. This is a problem for a layer 3 protocol to solve generically. If Mobile IP doesn't do what we need it to, then lets extend it, fix it, or replace it. thanks, -rohan >because people will use it in mobile environment (for both intra- and >inter-session). > >For inter-session, I guess that there may be some involvement of REGISTER >and re-INVITE messages (because of change in location). > >That's all! > >All works are done in the lower layer and SIP is not involved (for example, >some one in the lower layer will find that the location has been changed, >accordingly the upper layer may take some actions, if needed). > >Hope this will clarify the things. > >Best regards, >Radhika R. Roy >AT&T > >-----Original Message----- >From: Brian Stucker [mailto:bstucker@nortelnetworks.com] >Sent: Friday, September 29, 2000 1:19 PM >To: sip@lists.bell-labs.com >Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP Mobility ) > > > >My intent isn't to confuse anyone. Quite the contrary. > >My point is that SIP, as an application, should not be concerned about the >vagaries of the underlying media it's being carried on. All applications >that use IP as a transport are going to have to contend with mobility in the >IP space on the intra-session timescale. So IP should solve the problem >because it's a general problem for IP. > >SIP does enough to handle inter-session mobility (I'm at my desk, I'm at >home), and not impede intra-session mobility. It's just simply not suited >for handling anything else because of the nature of the protocol. Any >intra-session mobility must be handled out-of-band as far as SIP is >concerned, and SIP must not make any requirements that would impede this. > >Again, to use wireless voice calls as an example, even with dedicated >transport links, thousands of pages of standards with CDMA/TDMA, IS-41, SS7, >and TCAP, a mobile switching center doesn't attempt to do what you guys are >talking about. It doesn't update the location of a mobile once it's handed >over to another switch in the location database until after your call has >completed, and the mobile registers on the system it moved into. Why? >Because the mobile could be handed back over to the first system, the >handoff could fail, etc. So they don't even attempt to keep the exact >location of the mobile up to date outside of the original switch until the >mobile is stable again, when the call ends. Instead, all incoming calls go >to the first switch, and that switch knows where to go from there to get the >call completed. > >SIP shouldn't be updating the location database every time a wireless >terminal moves around. Some sort of mobile IP proxy function, should instead >be used that knows how to currently find the terminal in it's mobile-aware >IP space. It should route based on the inbound packet's IP address only, and >not care what the payload data is either. > >That solves the problem for SIP, HTTP, FTP, POP3, RTP, you name it. Why >write an extension to every protocol that uses IP as a transport (and have >it solved, and debugged a million different ways) instead of just fixing the >problem at the IP layer (and have it solved, and debugged one way)? > >Brian Stucker >Nortel Networks > >-----Original Message----- >From: Roy, Radhika R, ALCOO [ mailto:rrroy@att.com ] >Sent: Friday, September 29, 2000 11:39 AM >To: hammer michael; Michael Thomas; Henry Sinnreich >Cc: Lewis Karl-QA3387; 'Henning Schulzrinne'; sip@lists.bell-labs.com >Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP >Mobility ) > > >Hi, Everyone: > >The need for addressing mobility is clear and SIP is only one part of the >whole equation. > >Let us not confuse people in the name of Pandora's box or otherwise. > >We have to meet the needs solving problems (not to show our back). > >For the SIP WG, it is the SIP session layer that needs to be addressed, if >it turns out that is a need to do some works. > >Best regards, >Radhika R. Roy >AT&T > >-----Original Message----- >From: hammer michael [ mailto:mhammer@cisco.com ] > >Sent: Friday, September 29, 2000 1:57 PM >To: Roy, Radhika R, ALCOO; Michael Thomas; Henry Sinnreich >Cc: Lewis Karl-QA3387; 'Henning Schulzrinne'; sip@lists.bell-labs.com >Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP >Mobility ) > > >I think Brian aptly pointed out the Pandora's box you open with "mobility." >That should be sufficient motivation to avoid that type of mobility in SIP. > >We are talking about different timescales, e.g.: per packet, per call, and >per registration. > >I thought your term "discrete" captured the idea that the type of >"mobility" you refer to is of the: call me at the office, then later, call >me at home, I'm here now "mobility." Because mobility conjures up so many >more issues, I like the word "presence" better. Presence management may be >more descriptive that mobility management. > >Mike > > >At 04:11 PM 09/28/2000 -0400, Roy, Radhika R, ALCOO wrote: > >Hi, Mike: > > > >Yes, we will have problems if we do not define the terms accurately. > > > >Let us assume that we are using SIP (RFC 2543) and its session layer as our > > >reference. Location, registration, and session are defined in SIP. > > > >Paging (and probably "path") has not been defined in SIP. I will not argue > >to take this abstraction in the SIP layer for now. > > > >Point of attachment has been used as a generic term to indicate "address of > > >the attachment." If we translate this abstraction in the SIP layer, it will > > >mean the addresses that are being used in the SIP layer (e.g., E.164, IP > >address, etc.). > > > >Now let us examine your points: Presence of a person or terminal, etc. > > > >In the SIP layer, I guess, that the presence of a person on a terminal >needs > >to be abstracted in terms of an "address." If that address is also related > >to the point of attachment, then it will also be related to mobility. > > > >(A person behind the terminal may have another ID to deal with personal > >mobility. Let us not address that personal mobility for now.) > > > >In this way, we can extend our analysis for each layer. > > > >Does this answer your question? > > > >Best regards, > >Radhika R. Roy > >AT&T > > > >-----Original Message----- > >From: hammer michael [ mailto:mhammer@cisco.com >] > >Sent: Thursday, September 28, 2000 6:29 PM > >To: Roy, Radhika R, ALCOO; Michael Thomas; Henry Sinnreich > >Cc: Lewis Karl-QA3387; 'Henning Schulzrinne'; sip@lists.bell-labs.com > >Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP > >Mobility ) > > > > > >Roy, > > > >I need to be very careful what word I choose. Session connection rather > >than path might have been more appropriate. I believe confusion can occur > >if the type of location, registration, location, paging, etc. is not > >accurately defined. I think that the intent of such services revolves > >about maintaining relationships between certain elements, such as between: > > > >user/application and terminal, > >terminal and network end-point, > >network end-point and link end-point, etc. > > > >The act of "registering" may mean different things at different layers and > >use different mechanisms to accomplish them. The question for me is > >whether these are handled independently or does one mechanism attempt to > >manage multiple associations or would one type of registration trigger > >another type at a different layer? > > > >Would SIP then manage the "presence" of a person on a terminal, where > >something else manages the "presence" of a terminal on the network? > > > >Mike Hammer > > > > > >At 12:28 PM 09/28/2000 -0400, Roy, Radhika R, ALCOO wrote: > > >Hi, Mike: > > > > > >You have made excellent points. In fact, you are in the heart of this > > >problem: How the communications path(s) needs to be established as the > >point > > >of attachment is changed during the contiguous mobility. > > > > > >I personally believe that SIP does not need to be involved to set up the > > >communications path(s) per se. > > > > > >However, SIP needs to be used to set up the session: re-INVITE (to the >new > > >address) may need to be used. > > > > > >In the process, location updates, paging, etc. are also involved. If the > > >location update does not have any impact in the SIP layer, I do not think > > > >that SIP should be aware of any change in the lower layer. For example, > > >mobile IP has the power of providing location transparency of the IP >layer > > >(although it has some problems to meet the performance requirements for >the > > >real-time communications like voice). > > > > > >In addition to IP addresses, there are also transport addresses (e.g., >UDP, > > >TCP) for media. One also needs to be careful how to deal with the TCP > > >connection. IP addresses change, but the TCP connections still remains >the > > >same. An update mechanism needs to be defined. In turn, does it mean that > > > >this updated information may also be propagated to the SIP layer (other > > >members may also provide comments on this) because SIP does have the > > >abstraction of the transport address? > > > > > >I have not yet talked about the link layer. > > > > > >I am not trying to solve the mobility problem here. > > > > > >All I am trying to show: If we try to analyze the situation doing an > > >end-to-end analysis, we can easily see what needs to be done in each >layer. > > >Finally, we can answer the question: Whether or not any new work is >needed > > >in the SIP layer to address both discrete and continuos mobility. > > > > > >But you are right that we MUST keep the involvement of the SIP layer to a > > > >minimal level (if possible, we should avoid it) to address the mobility > > >problem. > > > > > >Best regards, > > >Radhika R. Roy > > >AT&T > > > > > >-----Original Message----- > > >From: hammer michael [ mailto:mhammer@cisco.com > ] > > >Sent: Thursday, September 28, 2000 2:41 PM > > >To: Roy, Radhika R, ALCOO; Michael Thomas; Henry Sinnreich > > >Cc: Lewis Karl-QA3387; 'Henning Schulzrinne'; sip@lists.bell-labs.com > > >Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP > > >Mobility ) > > > > > > > > >Roy, > > > > > >Your use of the terms "discrete" and "continuous" strike to the heart of > > >the issue. In traditional mobile networks, there is an attempt to move >the > > >stream of media with the terminal as it crosses cell boundaries > > >(continuous). There are many papers related to voice and mobile-IP that > > >address how to move the communications path. > > > > > >The discrete case is more an issue of identification of the presence and > > >availability of recipients and the establishment of communications to > > >them. Because names and addresses denoting physical location are often > > >blurred, in essence, personal mobility involves the creation and deletion > > > >of recipients rather than their movement. > > > > > >As I understand it, SIP does not move existing communications so much as >it > > >destroys existing communications paths and replaces them with new ones. >In > > >that respect, some of the traditional mobility issues such as handover >are > > >avoided, but others, e.g. location updates and paging are still needed. > > > > > >While the telcos reverted to addressing hardware-oriented terminal >mobility > > >in PCS, the softer personal mobility is still open to definition. The >same > > >issues have appeared in the net world and each will need to be solved in > > >their respective layers. > > > > > >Mike > > > > > > > > >At 11:01 AM 09/28/2000 -0400, Roy, Radhika R, ALCOO wrote: > > > >Hi, Mike: > > > > > > > >In fact, this is the precisely the test why SIP should be involved or >to > >be > > > >enhanced to support mobility (discrete + continuos) in the case of >Voice, > > > >chat, IM, messaging, conferencing, games, and others. > > > > > > > >If it is found that SIP does not need to be involved, I do not think >that > > > >anyone will force it to do this. > > > > > > > >By the way, do you not see that how SIP (RFC 2543) has taken care of >many > > > >aspects of users' discrete mobility? Has it not been be an excellent >way > >of > > > >involving SIP to solve a kind of mobility in the first place (what >other > > > >applications like H.323 is yet to support)? > > > > > > > >Along the same line, if people come up with the ideas that it is better > > >to > > > >enhance SIP functionality to support other aspects of mobility (if > > > >alternative solutions are not there or not acceptable), I do not think > >that > > > >we should have any objections. > > > > > > > >Let us keep our mind open and judge each proposal with its own merits. > > > > > > > >Best regards, > > > >Radhika R. Roy > > > >AT&T > > > > > > > >-----Original Message----- > > > >From: Michael Thomas [ mailto:mat@cisco.com ] > > > >Sent: Wednesday, September 27, 2000 7:01 PM > > > >To: Henry Sinnreich > > > >Cc: Michael Thomas; Roy, Radhika R, ALCOO; Lewis Karl-QA3387; 'Henning > > > >Schulzrinne'; sip@lists.bell-labs.com > > > >Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP > > > >Mobility ) > > > > > > > > > > > >Henry Sinnreich writes: > > > > > >what seems clear is that there are a > > > > > >number of applications which won't be able to do > > > > > >that for a variety of reasons. > > > > > > > > > > Voice, chat, IM, messaging, conferencing, games, etc., are > > > > > plenty of reasons to justify the SIP approach to mobility. > > > > > > > > But what if you could do all of the same things > > > > and not need to modify or involve SIP and have the > > > > additional gain that things like http worked as well? > > > > > > > > Mike > > > > > > > > > > > > > > Henry > > > > > > > > > > >-----Original Message----- > > > > > >From: sip-admin@lists.bell-labs.com > > > > > >[ mailto:sip-admin@lists.bell-labs.com > ]On Behalf Of > > > > > >Michael Thomas > > > > > >Sent: Wednesday, September 27, 2000 8:33 PM > > > > > >To: Roy, Radhika R, ALCOO > > > > > >Cc: Michael Thomas; Lewis Karl-QA3387; 'Henning Schulzrinne'; > > > > > >sip@lists.bell-labs.com > > > > > >Subject: RE: [SIP] Attempt at summarizing current SIP > > > > > >drafts (SIP > > > > > >Mobility ) > > > > > > > > > > > > > > > > > > > > > > > >I guess what I'm having a hard time with is the > > > > > >starting point that assumes that SIP based > > > > > >application mobility is Good Thing. While it's > > > > > >clear that many applications *could* design in > > > > > >mobility, what seems clear is that there are a > > > > > >number of applications which won't be able to do > > > > > >that for a variety of reasons. Assuming that those > > > > > >applications are important too, then we're already > > > > > >stuck with needing to solve for the general > > > > > >problem. > > > > > > > > > > > >Starting out with the assumption that Mobile IP > > > > > >addresses the more general problem seems > > > > > >attractive because a good solution with fast > > > > > >handoff that addresses AAA and QoS would solve > > > > > >most of the application layer problems in a > > > > > >general way rather than just a SIP specific > > > > > >way. > > > > > > > > > > > >There also seems to be an implicit assumption in > > > > > >the draft of linkage of SIP to a AAA function. > > > > > >I'm going to guess that it is along the same line > > > > > >of thinking of the DQoS gate controller idea. The > > > > > >problem I have with that is that it is in the end > > > > > >an optimization on the normal RSVP/COPS pull > > > > > >model. However, things that don't fit into that > > > > > >model still have the non-optimized way of doing > > > > > >QoS authorization. That's probably not the fault > > > > > >of this draft, but it does seem to make the entire > > > > > >draft a cart-before-horse situation. > > > > > > > > > > > > Mike > > > > > > > > > > > >Roy, Radhika R, ALCOO writes: > > > > > > > Hi, Mike: > > > > > > > > > > > > > > I guess that SIP, as you rightly pointed out, is > > > > > >dealing with the signaling > > > > > > > mechanism in the application layer. So, SIP does > > > > > >not need to deal with L3 > > > > > > > media path. > > > > > > > > > > > > > > SIP does deal with addresses of the source and > > > > > >destination(s). > > > > > > > > > > > > > > In mobile environment, the point of attachment > > > > > >(i.e., addresses) changes: 1. > > > > > > > Between the sessions (discrete mobility) and 2. > > > > > >During the session > > > > > > > (continuous mobility). > > > > > > > > > > > > > > The problem that is being addressed is: What is the > > > > > >impact in SIP layer due > > > > > > > to these two kinds of mobility. > > > > > > > > > > > > > > I guess that for discrete mobility, SIP has > > > > > >probably addressed most of the > > > > > > > problems (others may also provide comments on this). > > > > > > > > > > > > > > For continuous mobility, there may need (or may > > > > > >not??) some works in the SIP > > > > > > > layer, if any (others may also provide comments). > > > > > > > > > > > > > > However, SIP can only address the mobility related > > > > > >problems in the > > > > > > > application layer. This alone may not be enough to > > > > > >solve all problems > > > > > > > because some L3 and L2 problems may also need to be > > > > > >addressed at the same > > > > > > > time to have the complete solution. > > > > > > > > > > > > > > In any solution, SIP mobility needs to be limited > > > > > >only to the application > > > > > > > layer (not L3, L2, etc.). > > > > > > > > > > > > > > Best regards, > > > > > > > Radhika R. Roy > > > > > > > AT&T > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Michael Thomas [ mailto:mat@cisco.com > ] > > > > > > > Sent: Wednesday, September 27, 2000 12:32 PM > > > > > > > To: Lewis Karl-QA3387 > > > > > > > Cc: 'Henning Schulzrinne'; sip@lists.bell-labs.com > > > > > > > Subject: RE: [SIP] Attempt at summarizing current SIP drafts > > > > > > > > > > > > > > > > > > > > > > > > > > > > While I'm more than willing to believe that there > > > > > > > are mobility issues that SIP needs to deal with, > > > > > > > this paper seems to be positing SIP as the means > > > > > > > of initiating data sessions altogether. To my > > > > > > > mind, that's a rather bellheaded way of thinking > > > > > > > about how you do what amounts to L3 admission > > > > > > > control. In fact, the IETF already has an L3 > > > > > > > admission control mechanism: RSVP. RSVP's main > > > > > > > advantage is that it follows actual network > > > > > > > topology. SIP is at a distinct disadvantage since > > > > > > > all it knows about is the signaling path which > > > > > > > in normal circumstances has nothing to do with > > > > > > > the actual data path. > > > > > > > > > > > > > > Maybe I'm misreading this whole paper, but it sure > > > > > > > looks like it to me. If my interpretation is > > > > > > > right, however, I'd like to know if the intention > > > > > > > is to signal the access routers providing the > > > > > > > L2/L3 bits using SIP instead of, say, COPS (or > > > > > > > DIAMETER). If so, I'd say that SIP truly has > > > > > > > arrived at becoming the new millenium's kitchen > > > > > > > sink if this is accepted. > > > > > > > > > > > > > > Mike > > > > > > > > > > > > > > Lewis Karl-QA3387 writes: > > > > > > > > I have just reviewed the Mobility Related drafts > > > > > >and am wondering if > > > > > > > anyone > > > > > > > > is aware of the current status of > > > > > >draft-itsumo-sip -mobility-req-01. In > > > > > > > > particular, several issues were identified such > > > > > >as Mobile IP not being > > > > > > > > sufficient for personal mobility and location > > > > > >services, completing > > > > > > > > registration in less than a few seconds, > > > > > >reconfiguration in milliseconds, > > > > > > > > providing location services, support of inter > > > > > >domain soft-hand and secure > > > > > > > > signaling. Have these issues been addressed or > > > > > >actively being worked? > > > > > > > > > > > > > > > > Karl > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Henning Schulzrinne > > > > > [ mailto:schulzrinne@cs.columbia.edu > ] > > > > > > > Sent: Monday, September 25, 2000 9:20 AM > > > > > > > To: sip@lists.bell-labs.com > > > > > > > Subject: [SIP] Attempt at summarizing current SIP drafts > > > > > > > > > > > > > > > > > > > > > Given the proliferation of SIP-related drafts, I've > > > > > created a summary of > > > > > > > efforts at > > > > > http://www.cs.columbia.edu/~hgs/sip/drafts.html > . This is > > > > > > > known to be incomplete, so I'd appreciate if you could > > > > > send me any > > > > > > > additions or corrections. (Jonathan Rosenberg provided > > > > > some of the text; > > > > > > > any mistakes or misrepresentations are mine.) > > > > > > > > > > > > > > It is fairly clear that there are a large number of drafts > > > > > that have not > > > > > > > changed materially for half a year or more. Maybe it's > > > > > time to have a WG > > > > > > > last call or two or ten... > > > > > > > > > > > > > > Henning > > > > > > > -- > > > > > > > Henning Schulzrinne http://www.cs.columbia.edu/~hgs > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > SIP mailing list > > > > > > > SIP@lists.bell-labs.com > > > > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > SIP mailing list > > > > > > > SIP@lists.bell-labs.com > > > > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > SIP mailing list > > > > > > SIP@lists.bell-labs.com > > > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > > > > > > _______________________________________________ > > > > > > SIP mailing list > > > > > > SIP@lists.bell-labs.com > > > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > SIP mailing list > > > > > SIP@lists.bell-labs.com > > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > > > > > > > > > > > >_______________________________________________ > > > >SIP mailing list > > > >SIP@lists.bell-labs.com > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > >_______________________________________________ > > > >SIP mailing list > > > >SIP@lists.bell-labs.com > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > >_______________________________________________ >SIP mailing list >SIP@lists.bell-labs.com >http://lists.bell-labs.com/mailman/listinfo/sip > > > >_______________________________________________ >SIP mailing list >SIP@lists.bell-labs.com >http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 4 17:00:12 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA01643 for ; Wed, 4 Oct 2000 17:00:11 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 64475443DC; Wed, 4 Oct 2000 16:00:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from kcmso1.proxy.att.com (kcmso1.att.com [192.128.133.69]) by lists.bell-labs.com (Postfix) with ESMTP id 62661443A9 for ; Wed, 4 Oct 2000 15:59:26 -0400 (EDT) Received: from gab200r1.ems.att.com ([135.37.94.32]) by kcmso1.proxy.att.com (AT&T IPNS/MSO-2.2) with ESMTP id QAA09926; Wed, 4 Oct 2000 16:59:22 -0400 (EDT) Received: from njb140bh1.ems.att.com by gab200r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2) id RAA28397; Wed, 4 Oct 2000 17:01:24 -0400 (EDT) Received: by njb140bh1.ems.att.com with Internet Mail Service (5.5.2652.35) id ; Wed, 4 Oct 2000 16:59:21 -0400 Message-ID: From: "Roy, Radhika R, ALCOO" To: Bobby Sardana Cc: Rohan Mahy , Brian Stucker , sip@lists.bell-labs.com Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP Mobility ) MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 4 Oct 2000 16:59:15 -0400 Hi, Bobby: I doubt it because SIP has an abstraction of addresses (i.e., point of attachments). The messages may go to the wrong places unless it is fixed. So, re-REGISTER and re-INVITE have been suggested (some I-Ds are there). Best regards, Radhika R. Roy AT&T -----Original Message----- From: Bobby Sardana [mailto:bobby.sardana@mobilerain.com] Sent: Wednesday, October 04, 2000 4:45 PM To: Roy, Radhika R, ALCOO Cc: Rohan Mahy; Brian Stucker; sip@lists.bell-labs.com Subject: Re: [SIP] Attempt at summarizing current SIP drafts (SIP Mobility) Hello Radhika: "Roy, Radhika R, ALCOO" wrote: > Hi, Rohan: > > Again, let us go back to the basic: > > SIP is a session initiation protocol. What needs to be done, if any, in the > SIP layer if the point of attachment is changed during the session. IMHO, nothing should be done. Application layer protocols should be transparent to IP mobility changes which is a layer 3 problem. Regards, Bobby.Sardana@mobilerain.com > > > Best regards, > Radhika R. Roy > AT&T > > -----Original Message----- > From: Rohan Mahy [mailto:rohan@cisco.com] > Sent: Wednesday, October 04, 2000 4:14 PM > To: Roy, Radhika R, ALCOO > Cc: Brian Stucker; sip@lists.bell-labs.com > Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP > Mobility ) > > At 10:51 AM 9/29/00 , Roy, Radhika R, ALCOO wrote: > >Hi, Brian: > > > >I guess that your mail has provided some technical inputs: 1. Inter-session > >mobility and 2. Intra-session mobility. > > > >For inter-session mobility, you think that SIP in OK. > > > >For intra-session mobility, it appears that you are feeling comfortable, as > >if, SIP is not designed to do this. > > > >Let us go to the basic: SIP is a session initiation protocol. It is the > >mandate of SIP. So, we like to see that it MUST deal with mobility as well > > *NO* !! Part of SIPs mandate is *personal* mobility, as a user moves from > device to device. Personal mobility is a good, useful thing. However, The > SIP charter does *NOT* include solving the problem of a device moving > through different layer 2 networks. This is a problem for a layer 3 > protocol to solve generically. If Mobile IP doesn't do what we need it to, > then lets extend it, fix it, or replace it. > > thanks, > -rohan > > >because people will use it in mobile environment (for both intra- and > >inter-session). > > > > >For inter-session, I guess that there may be some involvement of REGISTER > >and re-INVITE messages (because of change in location). > > > >That's all! > > > >All works are done in the lower layer and SIP is not involved (for example, > >some one in the lower layer will find that the location has been changed, > >accordingly the upper layer may take some actions, if needed). > > > >Hope this will clarify the things. > > > >Best regards, > >Radhika R. Roy > >AT&T > > > >-----Original Message----- > >From: Brian Stucker [mailto:bstucker@nortelnetworks.com] > >Sent: Friday, September 29, 2000 1:19 PM > >To: sip@lists.bell-labs.com > >Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP Mobility > ) > > > > > > > >My intent isn't to confuse anyone. Quite the contrary. > > > >My point is that SIP, as an application, should not be concerned about the > >vagaries of the underlying media it's being carried on. All applications > >that use IP as a transport are going to have to contend with mobility in > the > >IP space on the intra-session timescale. So IP should solve the problem > >because it's a general problem for IP. > > > >SIP does enough to handle inter-session mobility (I'm at my desk, I'm at > >home), and not impede intra-session mobility. It's just simply not suited > >for handling anything else because of the nature of the protocol. Any > >intra-session mobility must be handled out-of-band as far as SIP is > >concerned, and SIP must not make any requirements that would impede this. > > > >Again, to use wireless voice calls as an example, even with dedicated > >transport links, thousands of pages of standards with CDMA/TDMA, IS-41, > SS7, > >and TCAP, a mobile switching center doesn't attempt to do what you guys are > >talking about. It doesn't update the location of a mobile once it's handed > >over to another switch in the location database until after your call has > >completed, and the mobile registers on the system it moved into. Why? > >Because the mobile could be handed back over to the first system, the > >handoff could fail, etc. So they don't even attempt to keep the exact > >location of the mobile up to date outside of the original switch until the > >mobile is stable again, when the call ends. Instead, all incoming calls go > >to the first switch, and that switch knows where to go from there to get > the > >call completed. > > > >SIP shouldn't be updating the location database every time a wireless > >terminal moves around. Some sort of mobile IP proxy function, should > instead > >be used that knows how to currently find the terminal in it's mobile-aware > >IP space. It should route based on the inbound packet's IP address only, > and > >not care what the payload data is either. > > > >That solves the problem for SIP, HTTP, FTP, POP3, RTP, you name it. Why > >write an extension to every protocol that uses IP as a transport (and have > >it solved, and debugged a million different ways) instead of just fixing > the > >problem at the IP layer (and have it solved, and debugged one way)? > > > >Brian Stucker > >Nortel Networks > > > >-----Original Message----- > >From: Roy, Radhika R, ALCOO [ mailto:rrroy@att.com ] > >Sent: Friday, September 29, 2000 11:39 AM > >To: hammer michael; Michael Thomas; Henry Sinnreich > >Cc: Lewis Karl-QA3387; 'Henning Schulzrinne'; sip@lists.bell-labs.com > >Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP > >Mobility ) > > > > > >Hi, Everyone: > > > >The need for addressing mobility is clear and SIP is only one part of the > >whole equation. > > > >Let us not confuse people in the name of Pandora's box or otherwise. > > > >We have to meet the needs solving problems (not to show our back). > > > >For the SIP WG, it is the SIP session layer that needs to be addressed, if > >it turns out that is a need to do some works. > > > >Best regards, > >Radhika R. Roy > >AT&T > > > >-----Original Message----- > >From: hammer michael [ mailto:mhammer@cisco.com > ] > > > >Sent: Friday, September 29, 2000 1:57 PM > >To: Roy, Radhika R, ALCOO; Michael Thomas; Henry Sinnreich > >Cc: Lewis Karl-QA3387; 'Henning Schulzrinne'; sip@lists.bell-labs.com > >Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP > >Mobility ) > > > > > >I think Brian aptly pointed out the Pandora's box you open with "mobility." > >That should be sufficient motivation to avoid that type of mobility in SIP. > > > >We are talking about different timescales, e.g.: per packet, per call, and > >per registration. > > > >I thought your term "discrete" captured the idea that the type of > >"mobility" you refer to is of the: call me at the office, then later, call > >me at home, I'm here now "mobility." Because mobility conjures up so many > >more issues, I like the word "presence" better. Presence management may be > >more descriptive that mobility management. > > > >Mike > > > > > >At 04:11 PM 09/28/2000 -0400, Roy, Radhika R, ALCOO wrote: > > >Hi, Mike: > > > > > >Yes, we will have problems if we do not define the terms accurately. > > > > > >Let us assume that we are using SIP (RFC 2543) and its session layer as > our > > > > >reference. Location, registration, and session are defined in SIP. > > > > > >Paging (and probably "path") has not been defined in SIP. I will not > argue > > >to take this abstraction in the SIP layer for now. > > > > > >Point of attachment has been used as a generic term to indicate "address > of > > > > >the attachment." If we translate this abstraction in the SIP layer, it > will > > > > >mean the addresses that are being used in the SIP layer (e.g., E.164, IP > > >address, etc.). > > > > > >Now let us examine your points: Presence of a person or terminal, etc. > > > > > >In the SIP layer, I guess, that the presence of a person on a terminal > >needs > > >to be abstracted in terms of an "address." If that address is also > related > > >to the point of attachment, then it will also be related to mobility. > > > > > >(A person behind the terminal may have another ID to deal with personal > > >mobility. Let us not address that personal mobility for now.) > > > > > >In this way, we can extend our analysis for each layer. > > > > > >Does this answer your question? > > > > > >Best regards, > > >Radhika R. Roy > > >AT&T > > > > > >-----Original Message----- > > >From: hammer michael [ mailto:mhammer@cisco.com > > >] > > >Sent: Thursday, September 28, 2000 6:29 PM > > >To: Roy, Radhika R, ALCOO; Michael Thomas; Henry Sinnreich > > >Cc: Lewis Karl-QA3387; 'Henning Schulzrinne'; sip@lists.bell-labs.com > > >Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP > > >Mobility ) > > > > > > > > >Roy, > > > > > >I need to be very careful what word I choose. Session connection rather > > >than path might have been more appropriate. I believe confusion can > occur > > >if the type of location, registration, location, paging, etc. is not > > >accurately defined. I think that the intent of such services revolves > > >about maintaining relationships between certain elements, such as > between: > > > > > >user/application and terminal, > > >terminal and network end-point, > > >network end-point and link end-point, etc. > > > > > >The act of "registering" may mean different things at different layers > and > > >use different mechanisms to accomplish them. The question for me is > > >whether these are handled independently or does one mechanism attempt to > > >manage multiple associations or would one type of registration trigger > > >another type at a different layer? > > > > > >Would SIP then manage the "presence" of a person on a terminal, where > > >something else manages the "presence" of a terminal on the network? > > > > > >Mike Hammer > > > > > > > > >At 12:28 PM 09/28/2000 -0400, Roy, Radhika R, ALCOO wrote: > > > >Hi, Mike: > > > > > > > >You have made excellent points. In fact, you are in the heart of this > > > >problem: How the communications path(s) needs to be established as the > > >point > > > >of attachment is changed during the contiguous mobility. > > > > > > > >I personally believe that SIP does not need to be involved to set up > the > > > >communications path(s) per se. > > > > > > > >However, SIP needs to be used to set up the session: re-INVITE (to the > >new > > > >address) may need to be used. > > > > > > > >In the process, location updates, paging, etc. are also involved. If > the > > > >location update does not have any impact in the SIP layer, I do not > think > > > > > >that SIP should be aware of any change in the lower layer. For example, > > > >mobile IP has the power of providing location transparency of the IP > >layer > > > >(although it has some problems to meet the performance requirements for > >the > > > >real-time communications like voice). > > > > > > > >In addition to IP addresses, there are also transport addresses (e.g., > >UDP, > > > >TCP) for media. One also needs to be careful how to deal with the TCP > > > >connection. IP addresses change, but the TCP connections still remains > >the > > > >same. An update mechanism needs to be defined. In turn, does it mean > that > > > > > >this updated information may also be propagated to the SIP layer (other > > > >members may also provide comments on this) because SIP does have the > > > >abstraction of the transport address? > > > > > > > >I have not yet talked about the link layer. > > > > > > > >I am not trying to solve the mobility problem here. > > > > > > > >All I am trying to show: If we try to analyze the situation doing an > > > >end-to-end analysis, we can easily see what needs to be done in each > >layer. > > > >Finally, we can answer the question: Whether or not any new work is > >needed > > > >in the SIP layer to address both discrete and continuos mobility. > > > > > > > >But you are right that we MUST keep the involvement of the SIP layer to > a > > > > > >minimal level (if possible, we should avoid it) to address the mobility > > > >problem. > > > > > > > >Best regards, > > > >Radhika R. Roy > > > >AT&T > > > > > > > >-----Original Message----- > > > >From: hammer michael [ mailto:mhammer@cisco.com > > ] > > > >Sent: Thursday, September 28, 2000 2:41 PM > > > >To: Roy, Radhika R, ALCOO; Michael Thomas; Henry Sinnreich > > > >Cc: Lewis Karl-QA3387; 'Henning Schulzrinne'; sip@lists.bell-labs.com > > > >Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP > > > >Mobility ) > > > > > > > > > > > >Roy, > > > > > > > >Your use of the terms "discrete" and "continuous" strike to the heart > of > > > >the issue. In traditional mobile networks, there is an attempt to move > >the > > > >stream of media with the terminal as it crosses cell boundaries > > > >(continuous). There are many papers related to voice and mobile-IP > that > > > >address how to move the communications path. > > > > > > > >The discrete case is more an issue of identification of the presence > and > > > >availability of recipients and the establishment of communications to > > > >them. Because names and addresses denoting physical location are often > > > >blurred, in essence, personal mobility involves the creation and > deletion > > > > > >of recipients rather than their movement. > > > > > > > >As I understand it, SIP does not move existing communications so much > as > >it > > > >destroys existing communications paths and replaces them with new ones. > >In > > > >that respect, some of the traditional mobility issues such as handover > >are > > > >avoided, but others, e.g. location updates and paging are still needed. > > > > > > > >While the telcos reverted to addressing hardware-oriented terminal > >mobility > > > >in PCS, the softer personal mobility is still open to definition. The > >same > > > >issues have appeared in the net world and each will need to be solved > in > > > >their respective layers. > > > > > > > >Mike > > > > > > > > > > > >At 11:01 AM 09/28/2000 -0400, Roy, Radhika R, ALCOO wrote: > > > > >Hi, Mike: > > > > > > > > > >In fact, this is the precisely the test why SIP should be involved or > >to > > >be > > > > >enhanced to support mobility (discrete + continuos) in the case of > >Voice, > > > > >chat, IM, messaging, conferencing, games, and others. > > > > > > > > > >If it is found that SIP does not need to be involved, I do not think > >that > > > > >anyone will force it to do this. > > > > > > > > > >By the way, do you not see that how SIP (RFC 2543) has taken care of > >many > > > > >aspects of users' discrete mobility? Has it not been be an excellent > >way > > >of > > > > >involving SIP to solve a kind of mobility in the first place (what > >other > > > > >applications like H.323 is yet to support)? > > > > > > > > > >Along the same line, if people come up with the ideas that it is > better > > > > >to > > > > >enhance SIP functionality to support other aspects of mobility (if > > > > >alternative solutions are not there or not acceptable), I do not > think > > >that > > > > >we should have any objections. > > > > > > > > > >Let us keep our mind open and judge each proposal with its own > merits. > > > > > > > > > >Best regards, > > > > >Radhika R. Roy > > > > >AT&T > > > > > > > > > >-----Original Message----- > > > > >From: Michael Thomas [ mailto:mat@cisco.com ] > > > > >Sent: Wednesday, September 27, 2000 7:01 PM > > > > >To: Henry Sinnreich > > > > >Cc: Michael Thomas; Roy, Radhika R, ALCOO; Lewis Karl-QA3387; > 'Henning > > > > >Schulzrinne'; sip@lists.bell-labs.com > > > > >Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP > > > > >Mobility ) > > > > > > > > > > > > > > >Henry Sinnreich writes: > > > > > > >what seems clear is that there are a > > > > > > >number of applications which won't be able to do > > > > > > >that for a variety of reasons. > > > > > > > > > > > > Voice, chat, IM, messaging, conferencing, games, etc., are > > > > > > plenty of reasons to justify the SIP approach to mobility. > > > > > > > > > > But what if you could do all of the same things > > > > > and not need to modify or involve SIP and have the > > > > > additional gain that things like http worked as well? > > > > > > > > > > Mike > > > > > > > > > > > > > > > > > Henry > > > > > > > > > > > > >-----Original Message----- > > > > > > >From: sip-admin@lists.bell-labs.com > > > > > > >[ mailto:sip-admin@lists.bell-labs.com > > ]On Behalf Of > > > > > > >Michael Thomas > > > > > > >Sent: Wednesday, September 27, 2000 8:33 PM > > > > > > >To: Roy, Radhika R, ALCOO > > > > > > >Cc: Michael Thomas; Lewis Karl-QA3387; 'Henning Schulzrinne'; > > > > > > >sip@lists.bell-labs.com > > > > > > >Subject: RE: [SIP] Attempt at summarizing current SIP > > > > > > >drafts (SIP > > > > > > >Mobility ) > > > > > > > > > > > > > > > > > > > > > > > > > > > >I guess what I'm having a hard time with is the > > > > > > >starting point that assumes that SIP based > > > > > > >application mobility is Good Thing. While it's > > > > > > >clear that many applications *could* design in > > > > > > >mobility, what seems clear is that there are a > > > > > > >number of applications which won't be able to do > > > > > > >that for a variety of reasons. Assuming that those > > > > > > >applications are important too, then we're already > > > > > > >stuck with needing to solve for the general > > > > > > >problem. > > > > > > > > > > > > > >Starting out with the assumption that Mobile IP > > > > > > >addresses the more general problem seems > > > > > > >attractive because a good solution with fast > > > > > > >handoff that addresses AAA and QoS would solve > > > > > > >most of the application layer problems in a > > > > > > >general way rather than just a SIP specific > > > > > > >way. > > > > > > > > > > > > > >There also seems to be an implicit assumption in > > > > > > >the draft of linkage of SIP to a AAA function. > > > > > > >I'm going to guess that it is along the same line > > > > > > >of thinking of the DQoS gate controller idea. The > > > > > > >problem I have with that is that it is in the end > > > > > > >an optimization on the normal RSVP/COPS pull > > > > > > >model. However, things that don't fit into that > > > > > > >model still have the non-optimized way of doing > > > > > > >QoS authorization. That's probably not the fault > > > > > > >of this draft, but it does seem to make the entire > > > > > > >draft a cart-before-horse situation. > > > > > > > > > > > > > > Mike > > > > > > > > > > > > > >Roy, Radhika R, ALCOO writes: > > > > > > > > Hi, Mike: > > > > > > > > > > > > > > > > I guess that SIP, as you rightly pointed out, is > > > > > > >dealing with the signaling > > > > > > > > mechanism in the application layer. So, SIP does > > > > > > >not need to deal with L3 > > > > > > > > media path. > > > > > > > > > > > > > > > > SIP does deal with addresses of the source and > > > > > > >destination(s). > > > > > > > > > > > > > > > > In mobile environment, the point of attachment > > > > > > >(i.e., addresses) changes: 1. > > > > > > > > Between the sessions (discrete mobility) and 2. > > > > > > >During the session > > > > > > > > (continuous mobility). > > > > > > > > > > > > > > > > The problem that is being addressed is: What is the > > > > > > >impact in SIP layer due > > > > > > > > to these two kinds of mobility. > > > > > > > > > > > > > > > > I guess that for discrete mobility, SIP has > > > > > > >probably addressed most of the > > > > > > > > problems (others may also provide comments on this). > > > > > > > > > > > > > > > > For continuous mobility, there may need (or may > > > > > > >not??) some works in the SIP > > > > > > > > layer, if any (others may also provide comments). > > > > > > > > > > > > > > > > However, SIP can only address the mobility related > > > > > > >problems in the > > > > > > > > application layer. This alone may not be enough to > > > > > > >solve all problems > > > > > > > > because some L3 and L2 problems may also need to be > > > > > > >addressed at the same > > > > > > > > time to have the complete solution. > > > > > > > > > > > > > > > > In any solution, SIP mobility needs to be limited > > > > > > >only to the application > > > > > > > > layer (not L3, L2, etc.). > > > > > > > > > > > > > > > > Best regards, > > > > > > > > Radhika R. Roy > > > > > > > > AT&T > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Michael Thomas [ mailto:mat@cisco.com > > ] > > > > > > > > Sent: Wednesday, September 27, 2000 12:32 PM > > > > > > > > To: Lewis Karl-QA3387 > > > > > > > > Cc: 'Henning Schulzrinne'; sip@lists.bell-labs.com > > > > > > > > Subject: RE: [SIP] Attempt at summarizing current SIP drafts > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > While I'm more than willing to believe that there > > > > > > > > are mobility issues that SIP needs to deal with, > > > > > > > > this paper seems to be positing SIP as the means > > > > > > > > of initiating data sessions altogether. To my > > > > > > > > mind, that's a rather bellheaded way of thinking > > > > > > > > about how you do what amounts to L3 admission > > > > > > > > control. In fact, the IETF already has an L3 > > > > > > > > admission control mechanism: RSVP. RSVP's main > > > > > > > > advantage is that it follows actual network > > > > > > > > topology. SIP is at a distinct disadvantage since > > > > > > > > all it knows about is the signaling path which > > > > > > > > in normal circumstances has nothing to do with > > > > > > > > the actual data path. > > > > > > > > > > > > > > > > Maybe I'm misreading this whole paper, but it sure > > > > > > > > looks like it to me. If my interpretation is > > > > > > > > right, however, I'd like to know if the intention > > > > > > > > is to signal the access routers providing the > > > > > > > > L2/L3 bits using SIP instead of, say, COPS (or > > > > > > > > DIAMETER). If so, I'd say that SIP truly has > > > > > > > > arrived at becoming the new millenium's kitchen > > > > > > > > sink if this is accepted. > > > > > > > > > > > > > > > > Mike > > > > > > > > > > > > > > > > Lewis Karl-QA3387 writes: > > > > > > > > > I have just reviewed the Mobility Related drafts > > > > > > >and am wondering if > > > > > > > > anyone > > > > > > > > > is aware of the current status of > > > > > > >draft-itsumo-sip -mobility-req-01. In > > > > > > > > > particular, several issues were identified such > > > > > > >as Mobile IP not being > > > > > > > > > sufficient for personal mobility and location > > > > > > >services, completing > > > > > > > > > registration in less than a few seconds, > > > > > > >reconfiguration in milliseconds, > > > > > > > > > providing location services, support of inter > > > > > > >domain soft-hand and secure > > > > > > > > > signaling. Have these issues been addressed or > > > > > > >actively being worked? > > > > > > > > > > > > > > > > > > Karl > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Henning Schulzrinne > > > > > > [ mailto:schulzrinne@cs.columbia.edu > > ] > > > > > > > > Sent: Monday, September 25, 2000 9:20 AM > > > > > > > > To: sip@lists.bell-labs.com > > > > > > > > Subject: [SIP] Attempt at summarizing current SIP drafts > > > > > > > > > > > > > > > > > > > > > > > > Given the proliferation of SIP-related drafts, I've > > > > > > created a summary of > > > > > > > > efforts at > > > > > > http://www.cs.columbia.edu/~hgs/sip/drafts.html > > . This is > > > > > > > > known to be incomplete, so I'd appreciate if you could > > > > > > send me any > > > > > > > > additions or corrections. (Jonathan Rosenberg provided > > > > > > some of the text; > > > > > > > > any mistakes or misrepresentations are mine.) > > > > > > > > > > > > > > > > It is fairly clear that there are a large number of drafts > > > > > > that have not > > > > > > > > changed materially for half a year or more. Maybe it's > > > > > > time to have a WG > > > > > > > > last call or two or ten... > > > > > > > > > > > > > > > > Henning > > > > > > > > -- > > > > > > > > Henning Schulzrinne http://www.cs.columbia.edu/~hgs > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > SIP mailing list > > > > > > > > SIP@lists.bell-labs.com > > > > > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > SIP mailing list > > > > > > > > SIP@lists.bell-labs.com > > > > > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > SIP mailing list > > > > > > > SIP@lists.bell-labs.com > > > > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > SIP mailing list > > > > > > > SIP@lists.bell-labs.com > > > > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > SIP mailing list > > > > > > SIP@lists.bell-labs.com > > > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > > > > > > > > > > > > > > > > >_______________________________________________ > > > > >SIP mailing list > > > > >SIP@lists.bell-labs.com > > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > > > > >_______________________________________________ > > > > >SIP mailing list > > > > >SIP@lists.bell-labs.com > > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > >_______________________________________________ > >SIP mailing list > >SIP@lists.bell-labs.com > >http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > >_______________________________________________ > >SIP mailing list > >SIP@lists.bell-labs.com > >http://lists.bell-labs.com/mailman/listinfo/sip > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 4 17:04:08 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA01764 for ; Wed, 4 Oct 2000 17:04:07 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A0D90443DB; Wed, 4 Oct 2000 16:04:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from almso1.proxy.att.com (almso1.att.com [192.128.167.69]) by lists.bell-labs.com (Postfix) with ESMTP id 7B121443A9 for ; Wed, 4 Oct 2000 16:03:36 -0400 (EDT) Received: from njb140r1.ems.att.com ([135.65.202.58]) by almso1.proxy.att.com (AT&T IPNS/MSO-2.2) with ESMTP id RAA23444; Wed, 4 Oct 2000 17:03:32 -0400 (EDT) Received: from njb140bh2.ems.att.com by njb140r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2) id RAA03807; Wed, 4 Oct 2000 17:02:09 -0400 (EDT) Received: by njb140bh2.ems.att.com with Internet Mail Service (5.5.2652.35) id ; Wed, 4 Oct 2000 17:03:31 -0400 Message-ID: From: "Roy, Radhika R, ALCOO" To: Lewis Karl-QA3387 , sip@lists.bell-labs.com Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP Mobility ) MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 4 Oct 2000 17:03:27 -0400 I guess that it is needed in L3. I-Ds show that still there may be a need for re-REGISTER and re-INVITE messages in the SIP layer. -----Original Message----- From: Lewis Karl-QA3387 [mailto:K.Lewis@motorola.com] Sent: Wednesday, October 04, 2000 4:57 PM To: sip@lists.bell-labs.com Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP Mobility ) MobileIP is addressing this issue with drafts such as draft-elmalki-mobileip-fast-handoffs-03.txt and draft-soliman-mobileip-hmipv6-01.txt. -----Original Message----- From: Roy, Radhika R, ALCOO [mailto:rrroy@att.com] Sent: Wednesday, October 04, 2000 3:34 PM To: Rohan Mahy Cc: Brian Stucker; sip@lists.bell-labs.com Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP Mobility ) Hi, Rohan: Again, let us go back to the basic: SIP is a session initiation protocol. What needs to be done, if any, in the SIP layer if the point of attachment is changed during the session. Best regards, Radhika R. Roy AT&T -----Original Message----- From: Rohan Mahy [mailto:rohan@cisco.com] Sent: Wednesday, October 04, 2000 4:14 PM To: Roy, Radhika R, ALCOO Cc: Brian Stucker; sip@lists.bell-labs.com Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP Mobility ) At 10:51 AM 9/29/00 , Roy, Radhika R, ALCOO wrote: >Hi, Brian: > >I guess that your mail has provided some technical inputs: 1. Inter-session >mobility and 2. Intra-session mobility. > >For inter-session mobility, you think that SIP in OK. > >For intra-session mobility, it appears that you are feeling comfortable, as >if, SIP is not designed to do this. > >Let us go to the basic: SIP is a session initiation protocol. It is the >mandate of SIP. So, we like to see that it MUST deal with mobility as well *NO* !! Part of SIPs mandate is *personal* mobility, as a user moves from device to device. Personal mobility is a good, useful thing. However, The SIP charter does *NOT* include solving the problem of a device moving through different layer 2 networks. This is a problem for a layer 3 protocol to solve generically. If Mobile IP doesn't do what we need it to, then lets extend it, fix it, or replace it. thanks, -rohan >because people will use it in mobile environment (for both intra- and >inter-session). > >For inter-session, I guess that there may be some involvement of REGISTER >and re-INVITE messages (because of change in location). > >That's all! > >All works are done in the lower layer and SIP is not involved (for example, >some one in the lower layer will find that the location has been changed, >accordingly the upper layer may take some actions, if needed). > >Hope this will clarify the things. > >Best regards, >Radhika R. Roy >AT&T > >-----Original Message----- >From: Brian Stucker [mailto:bstucker@nortelnetworks.com] >Sent: Friday, September 29, 2000 1:19 PM >To: sip@lists.bell-labs.com >Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP Mobility ) > > > >My intent isn't to confuse anyone. Quite the contrary. > >My point is that SIP, as an application, should not be concerned about the >vagaries of the underlying media it's being carried on. All applications >that use IP as a transport are going to have to contend with mobility in the >IP space on the intra-session timescale. So IP should solve the problem >because it's a general problem for IP. > >SIP does enough to handle inter-session mobility (I'm at my desk, I'm at >home), and not impede intra-session mobility. It's just simply not suited >for handling anything else because of the nature of the protocol. Any >intra-session mobility must be handled out-of-band as far as SIP is >concerned, and SIP must not make any requirements that would impede this. > >Again, to use wireless voice calls as an example, even with dedicated >transport links, thousands of pages of standards with CDMA/TDMA, IS-41, SS7, >and TCAP, a mobile switching center doesn't attempt to do what you guys are >talking about. It doesn't update the location of a mobile once it's handed >over to another switch in the location database until after your call has >completed, and the mobile registers on the system it moved into. Why? >Because the mobile could be handed back over to the first system, the >handoff could fail, etc. So they don't even attempt to keep the exact >location of the mobile up to date outside of the original switch until the >mobile is stable again, when the call ends. Instead, all incoming calls go >to the first switch, and that switch knows where to go from there to get the >call completed. > >SIP shouldn't be updating the location database every time a wireless >terminal moves around. Some sort of mobile IP proxy function, should instead >be used that knows how to currently find the terminal in it's mobile-aware >IP space. It should route based on the inbound packet's IP address only, and >not care what the payload data is either. > >That solves the problem for SIP, HTTP, FTP, POP3, RTP, you name it. Why >write an extension to every protocol that uses IP as a transport (and have >it solved, and debugged a million different ways) instead of just fixing the >problem at the IP layer (and have it solved, and debugged one way)? > >Brian Stucker >Nortel Networks > >-----Original Message----- >From: Roy, Radhika R, ALCOO [ mailto:rrroy@att.com ] >Sent: Friday, September 29, 2000 11:39 AM >To: hammer michael; Michael Thomas; Henry Sinnreich >Cc: Lewis Karl-QA3387; 'Henning Schulzrinne'; sip@lists.bell-labs.com >Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP >Mobility ) > > >Hi, Everyone: > >The need for addressing mobility is clear and SIP is only one part of the >whole equation. > >Let us not confuse people in the name of Pandora's box or otherwise. > >We have to meet the needs solving problems (not to show our back). > >For the SIP WG, it is the SIP session layer that needs to be addressed, if >it turns out that is a need to do some works. > >Best regards, >Radhika R. Roy >AT&T > >-----Original Message----- >From: hammer michael [ mailto:mhammer@cisco.com ] > >Sent: Friday, September 29, 2000 1:57 PM >To: Roy, Radhika R, ALCOO; Michael Thomas; Henry Sinnreich >Cc: Lewis Karl-QA3387; 'Henning Schulzrinne'; sip@lists.bell-labs.com >Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP >Mobility ) > > >I think Brian aptly pointed out the Pandora's box you open with "mobility." >That should be sufficient motivation to avoid that type of mobility in SIP. > >We are talking about different timescales, e.g.: per packet, per call, and >per registration. > >I thought your term "discrete" captured the idea that the type of >"mobility" you refer to is of the: call me at the office, then later, call >me at home, I'm here now "mobility." Because mobility conjures up so many >more issues, I like the word "presence" better. Presence management may be >more descriptive that mobility management. > >Mike > > >At 04:11 PM 09/28/2000 -0400, Roy, Radhika R, ALCOO wrote: > >Hi, Mike: > > > >Yes, we will have problems if we do not define the terms accurately. > > > >Let us assume that we are using SIP (RFC 2543) and its session layer as our > > >reference. Location, registration, and session are defined in SIP. > > > >Paging (and probably "path") has not been defined in SIP. I will not argue > >to take this abstraction in the SIP layer for now. > > > >Point of attachment has been used as a generic term to indicate "address of > > >the attachment." If we translate this abstraction in the SIP layer, it will > > >mean the addresses that are being used in the SIP layer (e.g., E.164, IP > >address, etc.). > > > >Now let us examine your points: Presence of a person or terminal, etc. > > > >In the SIP layer, I guess, that the presence of a person on a terminal >needs > >to be abstracted in terms of an "address." If that address is also related > >to the point of attachment, then it will also be related to mobility. > > > >(A person behind the terminal may have another ID to deal with personal > >mobility. Let us not address that personal mobility for now.) > > > >In this way, we can extend our analysis for each layer. > > > >Does this answer your question? > > > >Best regards, > >Radhika R. Roy > >AT&T > > > >-----Original Message----- > >From: hammer michael [ mailto:mhammer@cisco.com >] > >Sent: Thursday, September 28, 2000 6:29 PM > >To: Roy, Radhika R, ALCOO; Michael Thomas; Henry Sinnreich > >Cc: Lewis Karl-QA3387; 'Henning Schulzrinne'; sip@lists.bell-labs.com > >Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP > >Mobility ) > > > > > >Roy, > > > >I need to be very careful what word I choose. Session connection rather > >than path might have been more appropriate. I believe confusion can occur > >if the type of location, registration, location, paging, etc. is not > >accurately defined. I think that the intent of such services revolves > >about maintaining relationships between certain elements, such as between: > > > >user/application and terminal, > >terminal and network end-point, > >network end-point and link end-point, etc. > > > >The act of "registering" may mean different things at different layers and > >use different mechanisms to accomplish them. The question for me is > >whether these are handled independently or does one mechanism attempt to > >manage multiple associations or would one type of registration trigger > >another type at a different layer? > > > >Would SIP then manage the "presence" of a person on a terminal, where > >something else manages the "presence" of a terminal on the network? > > > >Mike Hammer > > > > > >At 12:28 PM 09/28/2000 -0400, Roy, Radhika R, ALCOO wrote: > > >Hi, Mike: > > > > > >You have made excellent points. In fact, you are in the heart of this > > >problem: How the communications path(s) needs to be established as the > >point > > >of attachment is changed during the contiguous mobility. > > > > > >I personally believe that SIP does not need to be involved to set up the > > >communications path(s) per se. > > > > > >However, SIP needs to be used to set up the session: re-INVITE (to the >new > > >address) may need to be used. > > > > > >In the process, location updates, paging, etc. are also involved. If the > > >location update does not have any impact in the SIP layer, I do not think > > > >that SIP should be aware of any change in the lower layer. For example, > > >mobile IP has the power of providing location transparency of the IP >layer > > >(although it has some problems to meet the performance requirements for >the > > >real-time communications like voice). > > > > > >In addition to IP addresses, there are also transport addresses (e.g., >UDP, > > >TCP) for media. One also needs to be careful how to deal with the TCP > > >connection. IP addresses change, but the TCP connections still remains >the > > >same. An update mechanism needs to be defined. In turn, does it mean that > > > >this updated information may also be propagated to the SIP layer (other > > >members may also provide comments on this) because SIP does have the > > >abstraction of the transport address? > > > > > >I have not yet talked about the link layer. > > > > > >I am not trying to solve the mobility problem here. > > > > > >All I am trying to show: If we try to analyze the situation doing an > > >end-to-end analysis, we can easily see what needs to be done in each >layer. > > >Finally, we can answer the question: Whether or not any new work is >needed > > >in the SIP layer to address both discrete and continuos mobility. > > > > > >But you are right that we MUST keep the involvement of the SIP layer to a > > > >minimal level (if possible, we should avoid it) to address the mobility > > >problem. > > > > > >Best regards, > > >Radhika R. Roy > > >AT&T > > > > > >-----Original Message----- > > >From: hammer michael [ mailto:mhammer@cisco.com > ] > > >Sent: Thursday, September 28, 2000 2:41 PM > > >To: Roy, Radhika R, ALCOO; Michael Thomas; Henry Sinnreich > > >Cc: Lewis Karl-QA3387; 'Henning Schulzrinne'; sip@lists.bell-labs.com > > >Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP > > >Mobility ) > > > > > > > > >Roy, > > > > > >Your use of the terms "discrete" and "continuous" strike to the heart of > > >the issue. In traditional mobile networks, there is an attempt to move >the > > >stream of media with the terminal as it crosses cell boundaries > > >(continuous). There are many papers related to voice and mobile-IP that > > >address how to move the communications path. > > > > > >The discrete case is more an issue of identification of the presence and > > >availability of recipients and the establishment of communications to > > >them. Because names and addresses denoting physical location are often > > >blurred, in essence, personal mobility involves the creation and deletion > > > >of recipients rather than their movement. > > > > > >As I understand it, SIP does not move existing communications so much as >it > > >destroys existing communications paths and replaces them with new ones. >In > > >that respect, some of the traditional mobility issues such as handover >are > > >avoided, but others, e.g. location updates and paging are still needed. > > > > > >While the telcos reverted to addressing hardware-oriented terminal >mobility > > >in PCS, the softer personal mobility is still open to definition. The >same > > >issues have appeared in the net world and each will need to be solved in > > >their respective layers. > > > > > >Mike > > > > > > > > >At 11:01 AM 09/28/2000 -0400, Roy, Radhika R, ALCOO wrote: > > > >Hi, Mike: > > > > > > > >In fact, this is the precisely the test why SIP should be involved or >to > >be > > > >enhanced to support mobility (discrete + continuos) in the case of >Voice, > > > >chat, IM, messaging, conferencing, games, and others. > > > > > > > >If it is found that SIP does not need to be involved, I do not think >that > > > >anyone will force it to do this. > > > > > > > >By the way, do you not see that how SIP (RFC 2543) has taken care of >many > > > >aspects of users' discrete mobility? Has it not been be an excellent >way > >of > > > >involving SIP to solve a kind of mobility in the first place (what >other > > > >applications like H.323 is yet to support)? > > > > > > > >Along the same line, if people come up with the ideas that it is better > > >to > > > >enhance SIP functionality to support other aspects of mobility (if > > > >alternative solutions are not there or not acceptable), I do not think > >that > > > >we should have any objections. > > > > > > > >Let us keep our mind open and judge each proposal with its own merits. > > > > > > > >Best regards, > > > >Radhika R. Roy > > > >AT&T > > > > > > > >-----Original Message----- > > > >From: Michael Thomas [ mailto:mat@cisco.com ] > > > >Sent: Wednesday, September 27, 2000 7:01 PM > > > >To: Henry Sinnreich > > > >Cc: Michael Thomas; Roy, Radhika R, ALCOO; Lewis Karl-QA3387; 'Henning > > > >Schulzrinne'; sip@lists.bell-labs.com > > > >Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP > > > >Mobility ) > > > > > > > > > > > >Henry Sinnreich writes: > > > > > >what seems clear is that there are a > > > > > >number of applications which won't be able to do > > > > > >that for a variety of reasons. > > > > > > > > > > Voice, chat, IM, messaging, conferencing, games, etc., are > > > > > plenty of reasons to justify the SIP approach to mobility. > > > > > > > > But what if you could do all of the same things > > > > and not need to modify or involve SIP and have the > > > > additional gain that things like http worked as well? > > > > > > > > Mike > > > > > > > > > > > > > > Henry > > > > > > > > > > >-----Original Message----- > > > > > >From: sip-admin@lists.bell-labs.com > > > > > >[ mailto:sip-admin@lists.bell-labs.com > ]On Behalf Of > > > > > >Michael Thomas > > > > > >Sent: Wednesday, September 27, 2000 8:33 PM > > > > > >To: Roy, Radhika R, ALCOO > > > > > >Cc: Michael Thomas; Lewis Karl-QA3387; 'Henning Schulzrinne'; > > > > > >sip@lists.bell-labs.com > > > > > >Subject: RE: [SIP] Attempt at summarizing current SIP > > > > > >drafts (SIP > > > > > >Mobility ) > > > > > > > > > > > > > > > > > > > > > > > >I guess what I'm having a hard time with is the > > > > > >starting point that assumes that SIP based > > > > > >application mobility is Good Thing. While it's > > > > > >clear that many applications *could* design in > > > > > >mobility, what seems clear is that there are a > > > > > >number of applications which won't be able to do > > > > > >that for a variety of reasons. Assuming that those > > > > > >applications are important too, then we're already > > > > > >stuck with needing to solve for the general > > > > > >problem. > > > > > > > > > > > >Starting out with the assumption that Mobile IP > > > > > >addresses the more general problem seems > > > > > >attractive because a good solution with fast > > > > > >handoff that addresses AAA and QoS would solve > > > > > >most of the application layer problems in a > > > > > >general way rather than just a SIP specific > > > > > >way. > > > > > > > > > > > >There also seems to be an implicit assumption in > > > > > >the draft of linkage of SIP to a AAA function. > > > > > >I'm going to guess that it is along the same line > > > > > >of thinking of the DQoS gate controller idea. The > > > > > >problem I have with that is that it is in the end > > > > > >an optimization on the normal RSVP/COPS pull > > > > > >model. However, things that don't fit into that > > > > > >model still have the non-optimized way of doing > > > > > >QoS authorization. That's probably not the fault > > > > > >of this draft, but it does seem to make the entire > > > > > >draft a cart-before-horse situation. > > > > > > > > > > > > Mike > > > > > > > > > > > >Roy, Radhika R, ALCOO writes: > > > > > > > Hi, Mike: > > > > > > > > > > > > > > I guess that SIP, as you rightly pointed out, is > > > > > >dealing with the signaling > > > > > > > mechanism in the application layer. So, SIP does > > > > > >not need to deal with L3 > > > > > > > media path. > > > > > > > > > > > > > > SIP does deal with addresses of the source and > > > > > >destination(s). > > > > > > > > > > > > > > In mobile environment, the point of attachment > > > > > >(i.e., addresses) changes: 1. > > > > > > > Between the sessions (discrete mobility) and 2. > > > > > >During the session > > > > > > > (continuous mobility). > > > > > > > > > > > > > > The problem that is being addressed is: What is the > > > > > >impact in SIP layer due > > > > > > > to these two kinds of mobility. > > > > > > > > > > > > > > I guess that for discrete mobility, SIP has > > > > > >probably addressed most of the > > > > > > > problems (others may also provide comments on this). > > > > > > > > > > > > > > For continuous mobility, there may need (or may > > > > > >not??) some works in the SIP > > > > > > > layer, if any (others may also provide comments). > > > > > > > > > > > > > > However, SIP can only address the mobility related > > > > > >problems in the > > > > > > > application layer. This alone may not be enough to > > > > > >solve all problems > > > > > > > because some L3 and L2 problems may also need to be > > > > > >addressed at the same > > > > > > > time to have the complete solution. > > > > > > > > > > > > > > In any solution, SIP mobility needs to be limited > > > > > >only to the application > > > > > > > layer (not L3, L2, etc.). > > > > > > > > > > > > > > Best regards, > > > > > > > Radhika R. Roy > > > > > > > AT&T > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Michael Thomas [ mailto:mat@cisco.com > ] > > > > > > > Sent: Wednesday, September 27, 2000 12:32 PM > > > > > > > To: Lewis Karl-QA3387 > > > > > > > Cc: 'Henning Schulzrinne'; sip@lists.bell-labs.com > > > > > > > Subject: RE: [SIP] Attempt at summarizing current SIP drafts > > > > > > > > > > > > > > > > > > > > > > > > > > > > While I'm more than willing to believe that there > > > > > > > are mobility issues that SIP needs to deal with, > > > > > > > this paper seems to be positing SIP as the means > > > > > > > of initiating data sessions altogether. To my > > > > > > > mind, that's a rather bellheaded way of thinking > > > > > > > about how you do what amounts to L3 admission > > > > > > > control. In fact, the IETF already has an L3 > > > > > > > admission control mechanism: RSVP. RSVP's main > > > > > > > advantage is that it follows actual network > > > > > > > topology. SIP is at a distinct disadvantage since > > > > > > > all it knows about is the signaling path which > > > > > > > in normal circumstances has nothing to do with > > > > > > > the actual data path. > > > > > > > > > > > > > > Maybe I'm misreading this whole paper, but it sure > > > > > > > looks like it to me. If my interpretation is > > > > > > > right, however, I'd like to know if the intention > > > > > > > is to signal the access routers providing the > > > > > > > L2/L3 bits using SIP instead of, say, COPS (or > > > > > > > DIAMETER). If so, I'd say that SIP truly has > > > > > > > arrived at becoming the new millenium's kitchen > > > > > > > sink if this is accepted. > > > > > > > > > > > > > > Mike > > > > > > > > > > > > > > Lewis Karl-QA3387 writes: > > > > > > > > I have just reviewed the Mobility Related drafts > > > > > >and am wondering if > > > > > > > anyone > > > > > > > > is aware of the current status of > > > > > >draft-itsumo-sip -mobility-req-01. In > > > > > > > > particular, several issues were identified such > > > > > >as Mobile IP not being > > > > > > > > sufficient for personal mobility and location > > > > > >services, completing > > > > > > > > registration in less than a few seconds, > > > > > >reconfiguration in milliseconds, > > > > > > > > providing location services, support of inter > > > > > >domain soft-hand and secure > > > > > > > > signaling. Have these issues been addressed or > > > > > >actively being worked? > > > > > > > > > > > > > > > > Karl > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Henning Schulzrinne > > > > > [ mailto:schulzrinne@cs.columbia.edu > ] > > > > > > > Sent: Monday, September 25, 2000 9:20 AM > > > > > > > To: sip@lists.bell-labs.com > > > > > > > Subject: [SIP] Attempt at summarizing current SIP drafts > > > > > > > > > > > > > > > > > > > > > Given the proliferation of SIP-related drafts, I've > > > > > created a summary of > > > > > > > efforts at > > > > > http://www.cs.columbia.edu/~hgs/sip/drafts.html > . This is > > > > > > > known to be incomplete, so I'd appreciate if you could > > > > > send me any > > > > > > > additions or corrections. (Jonathan Rosenberg provided > > > > > some of the text; > > > > > > > any mistakes or misrepresentations are mine.) > > > > > > > > > > > > > > It is fairly clear that there are a large number of drafts > > > > > that have not > > > > > > > changed materially for half a year or more. Maybe it's > > > > > time to have a WG > > > > > > > last call or two or ten... > > > > > > > > > > > > > > Henning > > > > > > > -- > > > > > > > Henning Schulzrinne http://www.cs.columbia.edu/~hgs > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > SIP mailing list > > > > > > > SIP@lists.bell-labs.com > > > > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > SIP mailing list > > > > > > > SIP@lists.bell-labs.com > > > > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > SIP mailing list > > > > > > SIP@lists.bell-labs.com > > > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > > > > > > _______________________________________________ > > > > > > SIP mailing list > > > > > > SIP@lists.bell-labs.com > > > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > SIP mailing list > > > > > SIP@lists.bell-labs.com > > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > > > > > > > > > > > >_______________________________________________ > > > >SIP mailing list > > > >SIP@lists.bell-labs.com > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > >_______________________________________________ > > > >SIP mailing list > > > >SIP@lists.bell-labs.com > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > >_______________________________________________ >SIP mailing list >SIP@lists.bell-labs.com >http://lists.bell-labs.com/mailman/listinfo/sip > > > >_______________________________________________ >SIP mailing list >SIP@lists.bell-labs.com >http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 4 17:09:09 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA01829 for ; Wed, 4 Oct 2000 17:09:09 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id DAB63443E5; Wed, 4 Oct 2000 16:09:01 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by lists.bell-labs.com (Postfix) with ESMTP id 623CB443E5 for ; Wed, 4 Oct 2000 16:08:00 -0400 (EDT) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate2.mot.com (motgate2 2.1) with ESMTP id OAA20197 for ; Wed, 4 Oct 2000 14:07:36 -0700 (MST)] Received: [from il35exm01.cig.mot.com (IL35EXM01.cig.mot.com [160.19.16.101]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id OAA04381 for ; Wed, 4 Oct 2000 14:07:36 -0700 (MST)] Received: by IL35EXM01.cig.mot.com with Internet Mail Service (5.5.2650.21) id ; Wed, 4 Oct 2000 16:07:36 -0500 Message-ID: From: Lewis Karl-QA3387 To: "'Roy, Radhika R, ALCOO'" , Lewis Karl-QA3387 , sip@lists.bell-labs.com Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP Mobility ) MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 4 Oct 2000 16:07:35 -0500 I don't understand why you need to involve SIP if L3 is addressing this issue. For instance, packets can still be routed to the new destination when the point of attachment changes. -----Original Message----- From: Roy, Radhika R, ALCOO [mailto:rrroy@att.com] Sent: Wednesday, October 04, 2000 4:03 PM To: Lewis Karl-QA3387; sip@lists.bell-labs.com Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP Mobility ) I guess that it is needed in L3. I-Ds show that still there may be a need for re-REGISTER and re-INVITE messages in the SIP layer. -----Original Message----- From: Lewis Karl-QA3387 [mailto:K.Lewis@motorola.com] Sent: Wednesday, October 04, 2000 4:57 PM To: sip@lists.bell-labs.com Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP Mobility ) MobileIP is addressing this issue with drafts such as draft-elmalki-mobileip-fast-handoffs-03.txt and draft-soliman-mobileip-hmipv6-01.txt. -----Original Message----- From: Roy, Radhika R, ALCOO [mailto:rrroy@att.com] Sent: Wednesday, October 04, 2000 3:34 PM To: Rohan Mahy Cc: Brian Stucker; sip@lists.bell-labs.com Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP Mobility ) Hi, Rohan: Again, let us go back to the basic: SIP is a session initiation protocol. What needs to be done, if any, in the SIP layer if the point of attachment is changed during the session. Best regards, Radhika R. Roy AT&T -----Original Message----- From: Rohan Mahy [mailto:rohan@cisco.com] Sent: Wednesday, October 04, 2000 4:14 PM To: Roy, Radhika R, ALCOO Cc: Brian Stucker; sip@lists.bell-labs.com Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP Mobility ) At 10:51 AM 9/29/00 , Roy, Radhika R, ALCOO wrote: >Hi, Brian: > >I guess that your mail has provided some technical inputs: 1. Inter-session >mobility and 2. Intra-session mobility. > >For inter-session mobility, you think that SIP in OK. > >For intra-session mobility, it appears that you are feeling comfortable, as >if, SIP is not designed to do this. > >Let us go to the basic: SIP is a session initiation protocol. It is the >mandate of SIP. So, we like to see that it MUST deal with mobility as well *NO* !! Part of SIPs mandate is *personal* mobility, as a user moves from device to device. Personal mobility is a good, useful thing. However, The SIP charter does *NOT* include solving the problem of a device moving through different layer 2 networks. This is a problem for a layer 3 protocol to solve generically. If Mobile IP doesn't do what we need it to, then lets extend it, fix it, or replace it. thanks, -rohan >because people will use it in mobile environment (for both intra- and >inter-session). > >For inter-session, I guess that there may be some involvement of REGISTER >and re-INVITE messages (because of change in location). > >That's all! > >All works are done in the lower layer and SIP is not involved (for example, >some one in the lower layer will find that the location has been changed, >accordingly the upper layer may take some actions, if needed). > >Hope this will clarify the things. > >Best regards, >Radhika R. Roy >AT&T > >-----Original Message----- >From: Brian Stucker [mailto:bstucker@nortelnetworks.com] >Sent: Friday, September 29, 2000 1:19 PM >To: sip@lists.bell-labs.com >Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP Mobility ) > > > >My intent isn't to confuse anyone. Quite the contrary. > >My point is that SIP, as an application, should not be concerned about the >vagaries of the underlying media it's being carried on. All applications >that use IP as a transport are going to have to contend with mobility in the >IP space on the intra-session timescale. So IP should solve the problem >because it's a general problem for IP. > >SIP does enough to handle inter-session mobility (I'm at my desk, I'm at >home), and not impede intra-session mobility. It's just simply not suited >for handling anything else because of the nature of the protocol. Any >intra-session mobility must be handled out-of-band as far as SIP is >concerned, and SIP must not make any requirements that would impede this. > >Again, to use wireless voice calls as an example, even with dedicated >transport links, thousands of pages of standards with CDMA/TDMA, IS-41, SS7, >and TCAP, a mobile switching center doesn't attempt to do what you guys are >talking about. It doesn't update the location of a mobile once it's handed >over to another switch in the location database until after your call has >completed, and the mobile registers on the system it moved into. Why? >Because the mobile could be handed back over to the first system, the >handoff could fail, etc. So they don't even attempt to keep the exact >location of the mobile up to date outside of the original switch until the >mobile is stable again, when the call ends. Instead, all incoming calls go >to the first switch, and that switch knows where to go from there to get the >call completed. > >SIP shouldn't be updating the location database every time a wireless >terminal moves around. Some sort of mobile IP proxy function, should instead >be used that knows how to currently find the terminal in it's mobile-aware >IP space. It should route based on the inbound packet's IP address only, and >not care what the payload data is either. > >That solves the problem for SIP, HTTP, FTP, POP3, RTP, you name it. Why >write an extension to every protocol that uses IP as a transport (and have >it solved, and debugged a million different ways) instead of just fixing the >problem at the IP layer (and have it solved, and debugged one way)? > >Brian Stucker >Nortel Networks > >-----Original Message----- >From: Roy, Radhika R, ALCOO [ mailto:rrroy@att.com ] >Sent: Friday, September 29, 2000 11:39 AM >To: hammer michael; Michael Thomas; Henry Sinnreich >Cc: Lewis Karl-QA3387; 'Henning Schulzrinne'; sip@lists.bell-labs.com >Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP >Mobility ) > > >Hi, Everyone: > >The need for addressing mobility is clear and SIP is only one part of the >whole equation. > >Let us not confuse people in the name of Pandora's box or otherwise. > >We have to meet the needs solving problems (not to show our back). > >For the SIP WG, it is the SIP session layer that needs to be addressed, if >it turns out that is a need to do some works. > >Best regards, >Radhika R. Roy >AT&T > >-----Original Message----- >From: hammer michael [ mailto:mhammer@cisco.com ] > >Sent: Friday, September 29, 2000 1:57 PM >To: Roy, Radhika R, ALCOO; Michael Thomas; Henry Sinnreich >Cc: Lewis Karl-QA3387; 'Henning Schulzrinne'; sip@lists.bell-labs.com >Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP >Mobility ) > > >I think Brian aptly pointed out the Pandora's box you open with "mobility." >That should be sufficient motivation to avoid that type of mobility in SIP. > >We are talking about different timescales, e.g.: per packet, per call, and >per registration. > >I thought your term "discrete" captured the idea that the type of >"mobility" you refer to is of the: call me at the office, then later, call >me at home, I'm here now "mobility." Because mobility conjures up so many >more issues, I like the word "presence" better. Presence management may be >more descriptive that mobility management. > >Mike > > >At 04:11 PM 09/28/2000 -0400, Roy, Radhika R, ALCOO wrote: > >Hi, Mike: > > > >Yes, we will have problems if we do not define the terms accurately. > > > >Let us assume that we are using SIP (RFC 2543) and its session layer as our > > >reference. Location, registration, and session are defined in SIP. > > > >Paging (and probably "path") has not been defined in SIP. I will not argue > >to take this abstraction in the SIP layer for now. > > > >Point of attachment has been used as a generic term to indicate "address of > > >the attachment." If we translate this abstraction in the SIP layer, it will > > >mean the addresses that are being used in the SIP layer (e.g., E.164, IP > >address, etc.). > > > >Now let us examine your points: Presence of a person or terminal, etc. > > > >In the SIP layer, I guess, that the presence of a person on a terminal >needs > >to be abstracted in terms of an "address." If that address is also related > >to the point of attachment, then it will also be related to mobility. > > > >(A person behind the terminal may have another ID to deal with personal > >mobility. Let us not address that personal mobility for now.) > > > >In this way, we can extend our analysis for each layer. > > > >Does this answer your question? > > > >Best regards, > >Radhika R. Roy > >AT&T > > > >-----Original Message----- > >From: hammer michael [ mailto:mhammer@cisco.com >] > >Sent: Thursday, September 28, 2000 6:29 PM > >To: Roy, Radhika R, ALCOO; Michael Thomas; Henry Sinnreich > >Cc: Lewis Karl-QA3387; 'Henning Schulzrinne'; sip@lists.bell-labs.com > >Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP > >Mobility ) > > > > > >Roy, > > > >I need to be very careful what word I choose. Session connection rather > >than path might have been more appropriate. I believe confusion can occur > >if the type of location, registration, location, paging, etc. is not > >accurately defined. I think that the intent of such services revolves > >about maintaining relationships between certain elements, such as between: > > > >user/application and terminal, > >terminal and network end-point, > >network end-point and link end-point, etc. > > > >The act of "registering" may mean different things at different layers and > >use different mechanisms to accomplish them. The question for me is > >whether these are handled independently or does one mechanism attempt to > >manage multiple associations or would one type of registration trigger > >another type at a different layer? > > > >Would SIP then manage the "presence" of a person on a terminal, where > >something else manages the "presence" of a terminal on the network? > > > >Mike Hammer > > > > > >At 12:28 PM 09/28/2000 -0400, Roy, Radhika R, ALCOO wrote: > > >Hi, Mike: > > > > > >You have made excellent points. In fact, you are in the heart of this > > >problem: How the communications path(s) needs to be established as the > >point > > >of attachment is changed during the contiguous mobility. > > > > > >I personally believe that SIP does not need to be involved to set up the > > >communications path(s) per se. > > > > > >However, SIP needs to be used to set up the session: re-INVITE (to the >new > > >address) may need to be used. > > > > > >In the process, location updates, paging, etc. are also involved. If the > > >location update does not have any impact in the SIP layer, I do not think > > > >that SIP should be aware of any change in the lower layer. For example, > > >mobile IP has the power of providing location transparency of the IP >layer > > >(although it has some problems to meet the performance requirements for >the > > >real-time communications like voice). > > > > > >In addition to IP addresses, there are also transport addresses (e.g., >UDP, > > >TCP) for media. One also needs to be careful how to deal with the TCP > > >connection. IP addresses change, but the TCP connections still remains >the > > >same. An update mechanism needs to be defined. In turn, does it mean that > > > >this updated information may also be propagated to the SIP layer (other > > >members may also provide comments on this) because SIP does have the > > >abstraction of the transport address? > > > > > >I have not yet talked about the link layer. > > > > > >I am not trying to solve the mobility problem here. > > > > > >All I am trying to show: If we try to analyze the situation doing an > > >end-to-end analysis, we can easily see what needs to be done in each >layer. > > >Finally, we can answer the question: Whether or not any new work is >needed > > >in the SIP layer to address both discrete and continuos mobility. > > > > > >But you are right that we MUST keep the involvement of the SIP layer to a > > > >minimal level (if possible, we should avoid it) to address the mobility > > >problem. > > > > > >Best regards, > > >Radhika R. Roy > > >AT&T > > > > > >-----Original Message----- > > >From: hammer michael [ mailto:mhammer@cisco.com > ] > > >Sent: Thursday, September 28, 2000 2:41 PM > > >To: Roy, Radhika R, ALCOO; Michael Thomas; Henry Sinnreich > > >Cc: Lewis Karl-QA3387; 'Henning Schulzrinne'; sip@lists.bell-labs.com > > >Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP > > >Mobility ) > > > > > > > > >Roy, > > > > > >Your use of the terms "discrete" and "continuous" strike to the heart of > > >the issue. In traditional mobile networks, there is an attempt to move >the > > >stream of media with the terminal as it crosses cell boundaries > > >(continuous). There are many papers related to voice and mobile-IP that > > >address how to move the communications path. > > > > > >The discrete case is more an issue of identification of the presence and > > >availability of recipients and the establishment of communications to > > >them. Because names and addresses denoting physical location are often > > >blurred, in essence, personal mobility involves the creation and deletion > > > >of recipients rather than their movement. > > > > > >As I understand it, SIP does not move existing communications so much as >it > > >destroys existing communications paths and replaces them with new ones. >In > > >that respect, some of the traditional mobility issues such as handover >are > > >avoided, but others, e.g. location updates and paging are still needed. > > > > > >While the telcos reverted to addressing hardware-oriented terminal >mobility > > >in PCS, the softer personal mobility is still open to definition. The >same > > >issues have appeared in the net world and each will need to be solved in > > >their respective layers. > > > > > >Mike > > > > > > > > >At 11:01 AM 09/28/2000 -0400, Roy, Radhika R, ALCOO wrote: > > > >Hi, Mike: > > > > > > > >In fact, this is the precisely the test why SIP should be involved or >to > >be > > > >enhanced to support mobility (discrete + continuos) in the case of >Voice, > > > >chat, IM, messaging, conferencing, games, and others. > > > > > > > >If it is found that SIP does not need to be involved, I do not think >that > > > >anyone will force it to do this. > > > > > > > >By the way, do you not see that how SIP (RFC 2543) has taken care of >many > > > >aspects of users' discrete mobility? Has it not been be an excellent >way > >of > > > >involving SIP to solve a kind of mobility in the first place (what >other > > > >applications like H.323 is yet to support)? > > > > > > > >Along the same line, if people come up with the ideas that it is better > > >to > > > >enhance SIP functionality to support other aspects of mobility (if > > > >alternative solutions are not there or not acceptable), I do not think > >that > > > >we should have any objections. > > > > > > > >Let us keep our mind open and judge each proposal with its own merits. > > > > > > > >Best regards, > > > >Radhika R. Roy > > > >AT&T > > > > > > > >-----Original Message----- > > > >From: Michael Thomas [ mailto:mat@cisco.com ] > > > >Sent: Wednesday, September 27, 2000 7:01 PM > > > >To: Henry Sinnreich > > > >Cc: Michael Thomas; Roy, Radhika R, ALCOO; Lewis Karl-QA3387; 'Henning > > > >Schulzrinne'; sip@lists.bell-labs.com > > > >Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP > > > >Mobility ) > > > > > > > > > > > >Henry Sinnreich writes: > > > > > >what seems clear is that there are a > > > > > >number of applications which won't be able to do > > > > > >that for a variety of reasons. > > > > > > > > > > Voice, chat, IM, messaging, conferencing, games, etc., are > > > > > plenty of reasons to justify the SIP approach to mobility. > > > > > > > > But what if you could do all of the same things > > > > and not need to modify or involve SIP and have the > > > > additional gain that things like http worked as well? > > > > > > > > Mike > > > > > > > > > > > > > > Henry > > > > > > > > > > >-----Original Message----- > > > > > >From: sip-admin@lists.bell-labs.com > > > > > >[ mailto:sip-admin@lists.bell-labs.com > ]On Behalf Of > > > > > >Michael Thomas > > > > > >Sent: Wednesday, September 27, 2000 8:33 PM > > > > > >To: Roy, Radhika R, ALCOO > > > > > >Cc: Michael Thomas; Lewis Karl-QA3387; 'Henning Schulzrinne'; > > > > > >sip@lists.bell-labs.com > > > > > >Subject: RE: [SIP] Attempt at summarizing current SIP > > > > > >drafts (SIP > > > > > >Mobility ) > > > > > > > > > > > > > > > > > > > > > > > >I guess what I'm having a hard time with is the > > > > > >starting point that assumes that SIP based > > > > > >application mobility is Good Thing. While it's > > > > > >clear that many applications *could* design in > > > > > >mobility, what seems clear is that there are a > > > > > >number of applications which won't be able to do > > > > > >that for a variety of reasons. Assuming that those > > > > > >applications are important too, then we're already > > > > > >stuck with needing to solve for the general > > > > > >problem. > > > > > > > > > > > >Starting out with the assumption that Mobile IP > > > > > >addresses the more general problem seems > > > > > >attractive because a good solution with fast > > > > > >handoff that addresses AAA and QoS would solve > > > > > >most of the application layer problems in a > > > > > >general way rather than just a SIP specific > > > > > >way. > > > > > > > > > > > >There also seems to be an implicit assumption in > > > > > >the draft of linkage of SIP to a AAA function. > > > > > >I'm going to guess that it is along the same line > > > > > >of thinking of the DQoS gate controller idea. The > > > > > >problem I have with that is that it is in the end > > > > > >an optimization on the normal RSVP/COPS pull > > > > > >model. However, things that don't fit into that > > > > > >model still have the non-optimized way of doing > > > > > >QoS authorization. That's probably not the fault > > > > > >of this draft, but it does seem to make the entire > > > > > >draft a cart-before-horse situation. > > > > > > > > > > > > Mike > > > > > > > > > > > >Roy, Radhika R, ALCOO writes: > > > > > > > Hi, Mike: > > > > > > > > > > > > > > I guess that SIP, as you rightly pointed out, is > > > > > >dealing with the signaling > > > > > > > mechanism in the application layer. So, SIP does > > > > > >not need to deal with L3 > > > > > > > media path. > > > > > > > > > > > > > > SIP does deal with addresses of the source and > > > > > >destination(s). > > > > > > > > > > > > > > In mobile environment, the point of attachment > > > > > >(i.e., addresses) changes: 1. > > > > > > > Between the sessions (discrete mobility) and 2. > > > > > >During the session > > > > > > > (continuous mobility). > > > > > > > > > > > > > > The problem that is being addressed is: What is the > > > > > >impact in SIP layer due > > > > > > > to these two kinds of mobility. > > > > > > > > > > > > > > I guess that for discrete mobility, SIP has > > > > > >probably addressed most of the > > > > > > > problems (others may also provide comments on this). > > > > > > > > > > > > > > For continuous mobility, there may need (or may > > > > > >not??) some works in the SIP > > > > > > > layer, if any (others may also provide comments). > > > > > > > > > > > > > > However, SIP can only address the mobility related > > > > > >problems in the > > > > > > > application layer. This alone may not be enough to > > > > > >solve all problems > > > > > > > because some L3 and L2 problems may also need to be > > > > > >addressed at the same > > > > > > > time to have the complete solution. > > > > > > > > > > > > > > In any solution, SIP mobility needs to be limited > > > > > >only to the application > > > > > > > layer (not L3, L2, etc.). > > > > > > > > > > > > > > Best regards, > > > > > > > Radhika R. Roy > > > > > > > AT&T > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Michael Thomas [ mailto:mat@cisco.com > ] > > > > > > > Sent: Wednesday, September 27, 2000 12:32 PM > > > > > > > To: Lewis Karl-QA3387 > > > > > > > Cc: 'Henning Schulzrinne'; sip@lists.bell-labs.com > > > > > > > Subject: RE: [SIP] Attempt at summarizing current SIP drafts > > > > > > > > > > > > > > > > > > > > > > > > > > > > While I'm more than willing to believe that there > > > > > > > are mobility issues that SIP needs to deal with, > > > > > > > this paper seems to be positing SIP as the means > > > > > > > of initiating data sessions altogether. To my > > > > > > > mind, that's a rather bellheaded way of thinking > > > > > > > about how you do what amounts to L3 admission > > > > > > > control. In fact, the IETF already has an L3 > > > > > > > admission control mechanism: RSVP. RSVP's main > > > > > > > advantage is that it follows actual network > > > > > > > topology. SIP is at a distinct disadvantage since > > > > > > > all it knows about is the signaling path which > > > > > > > in normal circumstances has nothing to do with > > > > > > > the actual data path. > > > > > > > > > > > > > > Maybe I'm misreading this whole paper, but it sure > > > > > > > looks like it to me. If my interpretation is > > > > > > > right, however, I'd like to know if the intention > > > > > > > is to signal the access routers providing the > > > > > > > L2/L3 bits using SIP instead of, say, COPS (or > > > > > > > DIAMETER). If so, I'd say that SIP truly has > > > > > > > arrived at becoming the new millenium's kitchen > > > > > > > sink if this is accepted. > > > > > > > > > > > > > > Mike > > > > > > > > > > > > > > Lewis Karl-QA3387 writes: > > > > > > > > I have just reviewed the Mobility Related drafts > > > > > >and am wondering if > > > > > > > anyone > > > > > > > > is aware of the current status of > > > > > >draft-itsumo-sip -mobility-req-01. In > > > > > > > > particular, several issues were identified such > > > > > >as Mobile IP not being > > > > > > > > sufficient for personal mobility and location > > > > > >services, completing > > > > > > > > registration in less than a few seconds, > > > > > >reconfiguration in milliseconds, > > > > > > > > providing location services, support of inter > > > > > >domain soft-hand and secure > > > > > > > > signaling. Have these issues been addressed or > > > > > >actively being worked? > > > > > > > > > > > > > > > > Karl > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Henning Schulzrinne > > > > > [ mailto:schulzrinne@cs.columbia.edu > ] > > > > > > > Sent: Monday, September 25, 2000 9:20 AM > > > > > > > To: sip@lists.bell-labs.com > > > > > > > Subject: [SIP] Attempt at summarizing current SIP drafts > > > > > > > > > > > > > > > > > > > > > Given the proliferation of SIP-related drafts, I've > > > > > created a summary of > > > > > > > efforts at > > > > > http://www.cs.columbia.edu/~hgs/sip/drafts.html > . This is > > > > > > > known to be incomplete, so I'd appreciate if you could > > > > > send me any > > > > > > > additions or corrections. (Jonathan Rosenberg provided > > > > > some of the text; > > > > > > > any mistakes or misrepresentations are mine.) > > > > > > > > > > > > > > It is fairly clear that there are a large number of drafts > > > > > that have not > > > > > > > changed materially for half a year or more. Maybe it's > > > > > time to have a WG > > > > > > > last call or two or ten... > > > > > > > > > > > > > > Henning > > > > > > > -- > > > > > > > Henning Schulzrinne http://www.cs.columbia.edu/~hgs > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > SIP mailing list > > > > > > > SIP@lists.bell-labs.com > > > > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > SIP mailing list > > > > > > > SIP@lists.bell-labs.com > > > > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > SIP mailing list > > > > > > SIP@lists.bell-labs.com > > > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > > > > > > _______________________________________________ > > > > > > SIP mailing list > > > > > > SIP@lists.bell-labs.com > > > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > SIP mailing list > > > > > SIP@lists.bell-labs.com > > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > > > > > > > > > > > >_______________________________________________ > > > >SIP mailing list > > > >SIP@lists.bell-labs.com > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > >_______________________________________________ > > > >SIP mailing list > > > >SIP@lists.bell-labs.com > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > >_______________________________________________ >SIP mailing list >SIP@lists.bell-labs.com >http://lists.bell-labs.com/mailman/listinfo/sip > > > >_______________________________________________ >SIP mailing list >SIP@lists.bell-labs.com >http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 4 17:20:06 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA01951 for ; Wed, 4 Oct 2000 17:20:05 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7586A443C4; Wed, 4 Oct 2000 16:20:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from almso1.proxy.att.com (almso1.att.com [192.128.167.69]) by lists.bell-labs.com (Postfix) with ESMTP id A7F55443BF for ; Wed, 4 Oct 2000 16:19:55 -0400 (EDT) Received: from njb140r1.ems.att.com ([135.65.202.58]) by almso1.proxy.att.com (AT&T IPNS/MSO-2.2) with ESMTP id RAA28297; Wed, 4 Oct 2000 17:19:51 -0400 (EDT) Received: from njb140bh1.ems.att.com by njb140r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2) id RAA17589; Wed, 4 Oct 2000 17:18:28 -0400 (EDT) Received: by njb140bh1.ems.att.com with Internet Mail Service (5.5.2652.35) id ; Wed, 4 Oct 2000 17:19:49 -0400 Message-ID: From: "Roy, Radhika R, ALCOO" To: Lewis Karl-QA3387 , Lewis Karl-QA3387 , sip@lists.bell-labs.com Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP Mobility ) MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 4 Oct 2000 17:19:41 -0400 May be several reasons: Register may need to be have the current updated information. Session may need to be established to the right addresses optimizing resources. (Point of attachment may have the abstraction from L1 through L7) -----Original Message----- From: Lewis Karl-QA3387 [mailto:K.Lewis@motorola.com] Sent: Wednesday, October 04, 2000 5:08 PM To: Roy, Radhika R, ALCOO; Lewis Karl-QA3387; sip@lists.bell-labs.com Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP Mobility ) I don't understand why you need to involve SIP if L3 is addressing this issue. For instance, packets can still be routed to the new destination when the point of attachment changes. -----Original Message----- From: Roy, Radhika R, ALCOO [mailto:rrroy@att.com] Sent: Wednesday, October 04, 2000 4:03 PM To: Lewis Karl-QA3387; sip@lists.bell-labs.com Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP Mobility ) I guess that it is needed in L3. I-Ds show that still there may be a need for re-REGISTER and re-INVITE messages in the SIP layer. -----Original Message----- From: Lewis Karl-QA3387 [mailto:K.Lewis@motorola.com] Sent: Wednesday, October 04, 2000 4:57 PM To: sip@lists.bell-labs.com Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP Mobility ) MobileIP is addressing this issue with drafts such as draft-elmalki-mobileip-fast-handoffs-03.txt and draft-soliman-mobileip-hmipv6-01.txt. -----Original Message----- From: Roy, Radhika R, ALCOO [mailto:rrroy@att.com] Sent: Wednesday, October 04, 2000 3:34 PM To: Rohan Mahy Cc: Brian Stucker; sip@lists.bell-labs.com Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP Mobility ) Hi, Rohan: Again, let us go back to the basic: SIP is a session initiation protocol. What needs to be done, if any, in the SIP layer if the point of attachment is changed during the session. Best regards, Radhika R. Roy AT&T -----Original Message----- From: Rohan Mahy [mailto:rohan@cisco.com] Sent: Wednesday, October 04, 2000 4:14 PM To: Roy, Radhika R, ALCOO Cc: Brian Stucker; sip@lists.bell-labs.com Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP Mobility ) At 10:51 AM 9/29/00 , Roy, Radhika R, ALCOO wrote: >Hi, Brian: > >I guess that your mail has provided some technical inputs: 1. Inter-session >mobility and 2. Intra-session mobility. > >For inter-session mobility, you think that SIP in OK. > >For intra-session mobility, it appears that you are feeling comfortable, as >if, SIP is not designed to do this. > >Let us go to the basic: SIP is a session initiation protocol. It is the >mandate of SIP. So, we like to see that it MUST deal with mobility as well *NO* !! Part of SIPs mandate is *personal* mobility, as a user moves from device to device. Personal mobility is a good, useful thing. However, The SIP charter does *NOT* include solving the problem of a device moving through different layer 2 networks. This is a problem for a layer 3 protocol to solve generically. If Mobile IP doesn't do what we need it to, then lets extend it, fix it, or replace it. thanks, -rohan >because people will use it in mobile environment (for both intra- and >inter-session). > >For inter-session, I guess that there may be some involvement of REGISTER >and re-INVITE messages (because of change in location). > >That's all! > >All works are done in the lower layer and SIP is not involved (for example, >some one in the lower layer will find that the location has been changed, >accordingly the upper layer may take some actions, if needed). > >Hope this will clarify the things. > >Best regards, >Radhika R. Roy >AT&T > >-----Original Message----- >From: Brian Stucker [mailto:bstucker@nortelnetworks.com] >Sent: Friday, September 29, 2000 1:19 PM >To: sip@lists.bell-labs.com >Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP Mobility ) > > > >My intent isn't to confuse anyone. Quite the contrary. > >My point is that SIP, as an application, should not be concerned about the >vagaries of the underlying media it's being carried on. All applications >that use IP as a transport are going to have to contend with mobility in the >IP space on the intra-session timescale. So IP should solve the problem >because it's a general problem for IP. > >SIP does enough to handle inter-session mobility (I'm at my desk, I'm at >home), and not impede intra-session mobility. It's just simply not suited >for handling anything else because of the nature of the protocol. Any >intra-session mobility must be handled out-of-band as far as SIP is >concerned, and SIP must not make any requirements that would impede this. > >Again, to use wireless voice calls as an example, even with dedicated >transport links, thousands of pages of standards with CDMA/TDMA, IS-41, SS7, >and TCAP, a mobile switching center doesn't attempt to do what you guys are >talking about. It doesn't update the location of a mobile once it's handed >over to another switch in the location database until after your call has >completed, and the mobile registers on the system it moved into. Why? >Because the mobile could be handed back over to the first system, the >handoff could fail, etc. So they don't even attempt to keep the exact >location of the mobile up to date outside of the original switch until the >mobile is stable again, when the call ends. Instead, all incoming calls go >to the first switch, and that switch knows where to go from there to get the >call completed. > >SIP shouldn't be updating the location database every time a wireless >terminal moves around. Some sort of mobile IP proxy function, should instead >be used that knows how to currently find the terminal in it's mobile-aware >IP space. It should route based on the inbound packet's IP address only, and >not care what the payload data is either. > >That solves the problem for SIP, HTTP, FTP, POP3, RTP, you name it. Why >write an extension to every protocol that uses IP as a transport (and have >it solved, and debugged a million different ways) instead of just fixing the >problem at the IP layer (and have it solved, and debugged one way)? > >Brian Stucker >Nortel Networks > >-----Original Message----- >From: Roy, Radhika R, ALCOO [ mailto:rrroy@att.com ] >Sent: Friday, September 29, 2000 11:39 AM >To: hammer michael; Michael Thomas; Henry Sinnreich >Cc: Lewis Karl-QA3387; 'Henning Schulzrinne'; sip@lists.bell-labs.com >Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP >Mobility ) > > >Hi, Everyone: > >The need for addressing mobility is clear and SIP is only one part of the >whole equation. > >Let us not confuse people in the name of Pandora's box or otherwise. > >We have to meet the needs solving problems (not to show our back). > >For the SIP WG, it is the SIP session layer that needs to be addressed, if >it turns out that is a need to do some works. > >Best regards, >Radhika R. Roy >AT&T > >-----Original Message----- >From: hammer michael [ mailto:mhammer@cisco.com ] > >Sent: Friday, September 29, 2000 1:57 PM >To: Roy, Radhika R, ALCOO; Michael Thomas; Henry Sinnreich >Cc: Lewis Karl-QA3387; 'Henning Schulzrinne'; sip@lists.bell-labs.com >Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP >Mobility ) > > >I think Brian aptly pointed out the Pandora's box you open with "mobility." >That should be sufficient motivation to avoid that type of mobility in SIP. > >We are talking about different timescales, e.g.: per packet, per call, and >per registration. > >I thought your term "discrete" captured the idea that the type of >"mobility" you refer to is of the: call me at the office, then later, call >me at home, I'm here now "mobility." Because mobility conjures up so many >more issues, I like the word "presence" better. Presence management may be >more descriptive that mobility management. > >Mike > > >At 04:11 PM 09/28/2000 -0400, Roy, Radhika R, ALCOO wrote: > >Hi, Mike: > > > >Yes, we will have problems if we do not define the terms accurately. > > > >Let us assume that we are using SIP (RFC 2543) and its session layer as our > > >reference. Location, registration, and session are defined in SIP. > > > >Paging (and probably "path") has not been defined in SIP. I will not argue > >to take this abstraction in the SIP layer for now. > > > >Point of attachment has been used as a generic term to indicate "address of > > >the attachment." If we translate this abstraction in the SIP layer, it will > > >mean the addresses that are being used in the SIP layer (e.g., E.164, IP > >address, etc.). > > > >Now let us examine your points: Presence of a person or terminal, etc. > > > >In the SIP layer, I guess, that the presence of a person on a terminal >needs > >to be abstracted in terms of an "address." If that address is also related > >to the point of attachment, then it will also be related to mobility. > > > >(A person behind the terminal may have another ID to deal with personal > >mobility. Let us not address that personal mobility for now.) > > > >In this way, we can extend our analysis for each layer. > > > >Does this answer your question? > > > >Best regards, > >Radhika R. Roy > >AT&T > > > >-----Original Message----- > >From: hammer michael [ mailto:mhammer@cisco.com >] > >Sent: Thursday, September 28, 2000 6:29 PM > >To: Roy, Radhika R, ALCOO; Michael Thomas; Henry Sinnreich > >Cc: Lewis Karl-QA3387; 'Henning Schulzrinne'; sip@lists.bell-labs.com > >Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP > >Mobility ) > > > > > >Roy, > > > >I need to be very careful what word I choose. Session connection rather > >than path might have been more appropriate. I believe confusion can occur > >if the type of location, registration, location, paging, etc. is not > >accurately defined. I think that the intent of such services revolves > >about maintaining relationships between certain elements, such as between: > > > >user/application and terminal, > >terminal and network end-point, > >network end-point and link end-point, etc. > > > >The act of "registering" may mean different things at different layers and > >use different mechanisms to accomplish them. The question for me is > >whether these are handled independently or does one mechanism attempt to > >manage multiple associations or would one type of registration trigger > >another type at a different layer? > > > >Would SIP then manage the "presence" of a person on a terminal, where > >something else manages the "presence" of a terminal on the network? > > > >Mike Hammer > > > > > >At 12:28 PM 09/28/2000 -0400, Roy, Radhika R, ALCOO wrote: > > >Hi, Mike: > > > > > >You have made excellent points. In fact, you are in the heart of this > > >problem: How the communications path(s) needs to be established as the > >point > > >of attachment is changed during the contiguous mobility. > > > > > >I personally believe that SIP does not need to be involved to set up the > > >communications path(s) per se. > > > > > >However, SIP needs to be used to set up the session: re-INVITE (to the >new > > >address) may need to be used. > > > > > >In the process, location updates, paging, etc. are also involved. If the > > >location update does not have any impact in the SIP layer, I do not think > > > >that SIP should be aware of any change in the lower layer. For example, > > >mobile IP has the power of providing location transparency of the IP >layer > > >(although it has some problems to meet the performance requirements for >the > > >real-time communications like voice). > > > > > >In addition to IP addresses, there are also transport addresses (e.g., >UDP, > > >TCP) for media. One also needs to be careful how to deal with the TCP > > >connection. IP addresses change, but the TCP connections still remains >the > > >same. An update mechanism needs to be defined. In turn, does it mean that > > > >this updated information may also be propagated to the SIP layer (other > > >members may also provide comments on this) because SIP does have the > > >abstraction of the transport address? > > > > > >I have not yet talked about the link layer. > > > > > >I am not trying to solve the mobility problem here. > > > > > >All I am trying to show: If we try to analyze the situation doing an > > >end-to-end analysis, we can easily see what needs to be done in each >layer. > > >Finally, we can answer the question: Whether or not any new work is >needed > > >in the SIP layer to address both discrete and continuos mobility. > > > > > >But you are right that we MUST keep the involvement of the SIP layer to a > > > >minimal level (if possible, we should avoid it) to address the mobility > > >problem. > > > > > >Best regards, > > >Radhika R. Roy > > >AT&T > > > > > >-----Original Message----- > > >From: hammer michael [ mailto:mhammer@cisco.com > ] > > >Sent: Thursday, September 28, 2000 2:41 PM > > >To: Roy, Radhika R, ALCOO; Michael Thomas; Henry Sinnreich > > >Cc: Lewis Karl-QA3387; 'Henning Schulzrinne'; sip@lists.bell-labs.com > > >Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP > > >Mobility ) > > > > > > > > >Roy, > > > > > >Your use of the terms "discrete" and "continuous" strike to the heart of > > >the issue. In traditional mobile networks, there is an attempt to move >the > > >stream of media with the terminal as it crosses cell boundaries > > >(continuous). There are many papers related to voice and mobile-IP that > > >address how to move the communications path. > > > > > >The discrete case is more an issue of identification of the presence and > > >availability of recipients and the establishment of communications to > > >them. Because names and addresses denoting physical location are often > > >blurred, in essence, personal mobility involves the creation and deletion > > > >of recipients rather than their movement. > > > > > >As I understand it, SIP does not move existing communications so much as >it > > >destroys existing communications paths and replaces them with new ones. >In > > >that respect, some of the traditional mobility issues such as handover >are > > >avoided, but others, e.g. location updates and paging are still needed. > > > > > >While the telcos reverted to addressing hardware-oriented terminal >mobility > > >in PCS, the softer personal mobility is still open to definition. The >same > > >issues have appeared in the net world and each will need to be solved in > > >their respective layers. > > > > > >Mike > > > > > > > > >At 11:01 AM 09/28/2000 -0400, Roy, Radhika R, ALCOO wrote: > > > >Hi, Mike: > > > > > > > >In fact, this is the precisely the test why SIP should be involved or >to > >be > > > >enhanced to support mobility (discrete + continuos) in the case of >Voice, > > > >chat, IM, messaging, conferencing, games, and others. > > > > > > > >If it is found that SIP does not need to be involved, I do not think >that > > > >anyone will force it to do this. > > > > > > > >By the way, do you not see that how SIP (RFC 2543) has taken care of >many > > > >aspects of users' discrete mobility? Has it not been be an excellent >way > >of > > > >involving SIP to solve a kind of mobility in the first place (what >other > > > >applications like H.323 is yet to support)? > > > > > > > >Along the same line, if people come up with the ideas that it is better > > >to > > > >enhance SIP functionality to support other aspects of mobility (if > > > >alternative solutions are not there or not acceptable), I do not think > >that > > > >we should have any objections. > > > > > > > >Let us keep our mind open and judge each proposal with its own merits. > > > > > > > >Best regards, > > > >Radhika R. Roy > > > >AT&T > > > > > > > >-----Original Message----- > > > >From: Michael Thomas [ mailto:mat@cisco.com ] > > > >Sent: Wednesday, September 27, 2000 7:01 PM > > > >To: Henry Sinnreich > > > >Cc: Michael Thomas; Roy, Radhika R, ALCOO; Lewis Karl-QA3387; 'Henning > > > >Schulzrinne'; sip@lists.bell-labs.com > > > >Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP > > > >Mobility ) > > > > > > > > > > > >Henry Sinnreich writes: > > > > > >what seems clear is that there are a > > > > > >number of applications which won't be able to do > > > > > >that for a variety of reasons. > > > > > > > > > > Voice, chat, IM, messaging, conferencing, games, etc., are > > > > > plenty of reasons to justify the SIP approach to mobility. > > > > > > > > But what if you could do all of the same things > > > > and not need to modify or involve SIP and have the > > > > additional gain that things like http worked as well? > > > > > > > > Mike > > > > > > > > > > > > > > Henry > > > > > > > > > > >-----Original Message----- > > > > > >From: sip-admin@lists.bell-labs.com > > > > > >[ mailto:sip-admin@lists.bell-labs.com > ]On Behalf Of > > > > > >Michael Thomas > > > > > >Sent: Wednesday, September 27, 2000 8:33 PM > > > > > >To: Roy, Radhika R, ALCOO > > > > > >Cc: Michael Thomas; Lewis Karl-QA3387; 'Henning Schulzrinne'; > > > > > >sip@lists.bell-labs.com > > > > > >Subject: RE: [SIP] Attempt at summarizing current SIP > > > > > >drafts (SIP > > > > > >Mobility ) > > > > > > > > > > > > > > > > > > > > > > > >I guess what I'm having a hard time with is the > > > > > >starting point that assumes that SIP based > > > > > >application mobility is Good Thing. While it's > > > > > >clear that many applications *could* design in > > > > > >mobility, what seems clear is that there are a > > > > > >number of applications which won't be able to do > > > > > >that for a variety of reasons. Assuming that those > > > > > >applications are important too, then we're already > > > > > >stuck with needing to solve for the general > > > > > >problem. > > > > > > > > > > > >Starting out with the assumption that Mobile IP > > > > > >addresses the more general problem seems > > > > > >attractive because a good solution with fast > > > > > >handoff that addresses AAA and QoS would solve > > > > > >most of the application layer problems in a > > > > > >general way rather than just a SIP specific > > > > > >way. > > > > > > > > > > > >There also seems to be an implicit assumption in > > > > > >the draft of linkage of SIP to a AAA function. > > > > > >I'm going to guess that it is along the same line > > > > > >of thinking of the DQoS gate controller idea. The > > > > > >problem I have with that is that it is in the end > > > > > >an optimization on the normal RSVP/COPS pull > > > > > >model. However, things that don't fit into that > > > > > >model still have the non-optimized way of doing > > > > > >QoS authorization. That's probably not the fault > > > > > >of this draft, but it does seem to make the entire > > > > > >draft a cart-before-horse situation. > > > > > > > > > > > > Mike > > > > > > > > > > > >Roy, Radhika R, ALCOO writes: > > > > > > > Hi, Mike: > > > > > > > > > > > > > > I guess that SIP, as you rightly pointed out, is > > > > > >dealing with the signaling > > > > > > > mechanism in the application layer. So, SIP does > > > > > >not need to deal with L3 > > > > > > > media path. > > > > > > > > > > > > > > SIP does deal with addresses of the source and > > > > > >destination(s). > > > > > > > > > > > > > > In mobile environment, the point of attachment > > > > > >(i.e., addresses) changes: 1. > > > > > > > Between the sessions (discrete mobility) and 2. > > > > > >During the session > > > > > > > (continuous mobility). > > > > > > > > > > > > > > The problem that is being addressed is: What is the > > > > > >impact in SIP layer due > > > > > > > to these two kinds of mobility. > > > > > > > > > > > > > > I guess that for discrete mobility, SIP has > > > > > >probably addressed most of the > > > > > > > problems (others may also provide comments on this). > > > > > > > > > > > > > > For continuous mobility, there may need (or may > > > > > >not??) some works in the SIP > > > > > > > layer, if any (others may also provide comments). > > > > > > > > > > > > > > However, SIP can only address the mobility related > > > > > >problems in the > > > > > > > application layer. This alone may not be enough to > > > > > >solve all problems > > > > > > > because some L3 and L2 problems may also need to be > > > > > >addressed at the same > > > > > > > time to have the complete solution. > > > > > > > > > > > > > > In any solution, SIP mobility needs to be limited > > > > > >only to the application > > > > > > > layer (not L3, L2, etc.). > > > > > > > > > > > > > > Best regards, > > > > > > > Radhika R. Roy > > > > > > > AT&T > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Michael Thomas [ mailto:mat@cisco.com > ] > > > > > > > Sent: Wednesday, September 27, 2000 12:32 PM > > > > > > > To: Lewis Karl-QA3387 > > > > > > > Cc: 'Henning Schulzrinne'; sip@lists.bell-labs.com > > > > > > > Subject: RE: [SIP] Attempt at summarizing current SIP drafts > > > > > > > > > > > > > > > > > > > > > > > > > > > > While I'm more than willing to believe that there > > > > > > > are mobility issues that SIP needs to deal with, > > > > > > > this paper seems to be positing SIP as the means > > > > > > > of initiating data sessions altogether. To my > > > > > > > mind, that's a rather bellheaded way of thinking > > > > > > > about how you do what amounts to L3 admission > > > > > > > control. In fact, the IETF already has an L3 > > > > > > > admission control mechanism: RSVP. RSVP's main > > > > > > > advantage is that it follows actual network > > > > > > > topology. SIP is at a distinct disadvantage since > > > > > > > all it knows about is the signaling path which > > > > > > > in normal circumstances has nothing to do with > > > > > > > the actual data path. > > > > > > > > > > > > > > Maybe I'm misreading this whole paper, but it sure > > > > > > > looks like it to me. If my interpretation is > > > > > > > right, however, I'd like to know if the intention > > > > > > > is to signal the access routers providing the > > > > > > > L2/L3 bits using SIP instead of, say, COPS (or > > > > > > > DIAMETER). If so, I'd say that SIP truly has > > > > > > > arrived at becoming the new millenium's kitchen > > > > > > > sink if this is accepted. > > > > > > > > > > > > > > Mike > > > > > > > > > > > > > > Lewis Karl-QA3387 writes: > > > > > > > > I have just reviewed the Mobility Related drafts > > > > > >and am wondering if > > > > > > > anyone > > > > > > > > is aware of the current status of > > > > > >draft-itsumo-sip -mobility-req-01. In > > > > > > > > particular, several issues were identified such > > > > > >as Mobile IP not being > > > > > > > > sufficient for personal mobility and location > > > > > >services, completing > > > > > > > > registration in less than a few seconds, > > > > > >reconfiguration in milliseconds, > > > > > > > > providing location services, support of inter > > > > > >domain soft-hand and secure > > > > > > > > signaling. Have these issues been addressed or > > > > > >actively being worked? > > > > > > > > > > > > > > > > Karl > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Henning Schulzrinne > > > > > [ mailto:schulzrinne@cs.columbia.edu > ] > > > > > > > Sent: Monday, September 25, 2000 9:20 AM > > > > > > > To: sip@lists.bell-labs.com > > > > > > > Subject: [SIP] Attempt at summarizing current SIP drafts > > > > > > > > > > > > > > > > > > > > > Given the proliferation of SIP-related drafts, I've > > > > > created a summary of > > > > > > > efforts at > > > > > http://www.cs.columbia.edu/~hgs/sip/drafts.html > . This is > > > > > > > known to be incomplete, so I'd appreciate if you could > > > > > send me any > > > > > > > additions or corrections. (Jonathan Rosenberg provided > > > > > some of the text; > > > > > > > any mistakes or misrepresentations are mine.) > > > > > > > > > > > > > > It is fairly clear that there are a large number of drafts > > > > > that have not > > > > > > > changed materially for half a year or more. Maybe it's > > > > > time to have a WG > > > > > > > last call or two or ten... > > > > > > > > > > > > > > Henning > > > > > > > -- > > > > > > > Henning Schulzrinne http://www.cs.columbia.edu/~hgs > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > SIP mailing list > > > > > > > SIP@lists.bell-labs.com > > > > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > SIP mailing list > > > > > > > SIP@lists.bell-labs.com > > > > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > SIP mailing list > > > > > > SIP@lists.bell-labs.com > > > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > > > > > > _______________________________________________ > > > > > > SIP mailing list > > > > > > SIP@lists.bell-labs.com > > > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > SIP mailing list > > > > > SIP@lists.bell-labs.com > > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > > > > > > > > > > > >_______________________________________________ > > > >SIP mailing list > > > >SIP@lists.bell-labs.com > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > >_______________________________________________ > > > >SIP mailing list > > > >SIP@lists.bell-labs.com > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > >_______________________________________________ >SIP mailing list >SIP@lists.bell-labs.com >http://lists.bell-labs.com/mailman/listinfo/sip > > > >_______________________________________________ >SIP mailing list >SIP@lists.bell-labs.com >http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 4 17:24:46 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA02108 for ; Wed, 4 Oct 2000 17:24:46 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2EDFA443E5; Wed, 4 Oct 2000 16:22:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from charlie.cns.iit.edu (charlie.cns.iit.edu [216.47.143.70]) by lists.bell-labs.com (Postfix) with ESMTP id 0A2E7443E5 for ; Wed, 4 Oct 2000 16:21:20 -0400 (EDT) Received: (from pantdee@localhost) by charlie.cns.iit.edu (SGI-8.9.3/8.9.3) id QAA37366 for sip@lists.bell-labs.com; Wed, 4 Oct 2000 16:20:50 -0500 (CDT) From: Deepak Pant Message-Id: <200010042120.QAA37366@charlie.cns.iit.edu> To: sip@lists.bell-labs.com X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] Question about UA behaviour to 407 response Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 4 Oct 2000 16:20:49 -0500 (CDT) Content-Transfer-Encoding: 7bit rfc2543bis-02 says (Pg 93 , Sec 14.1 ) "When a UAC resubmits a request with its credentials after receiving a 401 or 407 response, it MUST increment the CSeq header field as it would normally do when sending updated request." However 407 is a final response and all the SIP proxy should expect after sending a 407 (in response to INVITE) is an ACK and a new INVITE message with a new CallID. The sip call flows draft is more in line with the reasoning. Does the explanation in the rfc conflict the call flows? For the authentication for REGISTER messages, if a SIP proxy accepts a registration message from a UA on behalf of a third party, how should the UA be authenticated. Should the registration message be forwarded to the home proxy and whatever challenge is issued by the home proxy proxied back to the UA or should the SIP proxy use an alternate mechanism as well. Thanks -Deepak _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 4 17:28:39 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA02174 for ; Wed, 4 Oct 2000 17:28:39 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4B4B8443FB; Wed, 4 Oct 2000 16:24:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by lists.bell-labs.com (Postfix) with ESMTP id 0931E443FB for ; Wed, 4 Oct 2000 16:22:47 -0400 (EDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (motgate 2.1) with ESMTP id OAA02541 for ; Wed, 4 Oct 2000 14:22:42 -0700 (MST)] Received: [from il75exm02.cig.mot.com (IL75EXM02.cig.mot.com [136.182.110.102]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id OAA15733 for ; Wed, 4 Oct 2000 14:22:42 -0700 (MST)] Received: by IL75EXM02.cig.mot.com with Internet Mail Service (5.5.2650.21) id ; Wed, 4 Oct 2000 16:22:41 -0500 Message-ID: From: Lewis Karl-QA3387 To: "'Roy, Radhika R, ALCOO'" , Lewis Karl-QA3387 , Lewis Karl-QA3387 , sip@lists.bell-labs.com Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP Mobility ) MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 4 Oct 2000 16:22:39 -0500 Are you saying that every time the point of attachment changes a reregister is needed? -----Original Message----- From: Roy, Radhika R, ALCOO [mailto:rrroy@att.com] Sent: Wednesday, October 04, 2000 4:20 PM To: Lewis Karl-QA3387; Lewis Karl-QA3387; sip@lists.bell-labs.com Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP Mobility ) May be several reasons: Register may need to be have the current updated information. Session may need to be established to the right addresses optimizing resources. (Point of attachment may have the abstraction from L1 through L7) -----Original Message----- From: Lewis Karl-QA3387 [mailto:K.Lewis@motorola.com] Sent: Wednesday, October 04, 2000 5:08 PM To: Roy, Radhika R, ALCOO; Lewis Karl-QA3387; sip@lists.bell-labs.com Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP Mobility ) I don't understand why you need to involve SIP if L3 is addressing this issue. For instance, packets can still be routed to the new destination when the point of attachment changes. -----Original Message----- From: Roy, Radhika R, ALCOO [mailto:rrroy@att.com] Sent: Wednesday, October 04, 2000 4:03 PM To: Lewis Karl-QA3387; sip@lists.bell-labs.com Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP Mobility ) I guess that it is needed in L3. I-Ds show that still there may be a need for re-REGISTER and re-INVITE messages in the SIP layer. -----Original Message----- From: Lewis Karl-QA3387 [mailto:K.Lewis@motorola.com] Sent: Wednesday, October 04, 2000 4:57 PM To: sip@lists.bell-labs.com Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP Mobility ) MobileIP is addressing this issue with drafts such as draft-elmalki-mobileip-fast-handoffs-03.txt and draft-soliman-mobileip-hmipv6-01.txt. -----Original Message----- From: Roy, Radhika R, ALCOO [mailto:rrroy@att.com] Sent: Wednesday, October 04, 2000 3:34 PM To: Rohan Mahy Cc: Brian Stucker; sip@lists.bell-labs.com Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP Mobility ) Hi, Rohan: Again, let us go back to the basic: SIP is a session initiation protocol. What needs to be done, if any, in the SIP layer if the point of attachment is changed during the session. Best regards, Radhika R. Roy AT&T -----Original Message----- From: Rohan Mahy [mailto:rohan@cisco.com] Sent: Wednesday, October 04, 2000 4:14 PM To: Roy, Radhika R, ALCOO Cc: Brian Stucker; sip@lists.bell-labs.com Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP Mobility ) At 10:51 AM 9/29/00 , Roy, Radhika R, ALCOO wrote: >Hi, Brian: > >I guess that your mail has provided some technical inputs: 1. Inter-session >mobility and 2. Intra-session mobility. > >For inter-session mobility, you think that SIP in OK. > >For intra-session mobility, it appears that you are feeling comfortable, as >if, SIP is not designed to do this. > >Let us go to the basic: SIP is a session initiation protocol. It is the >mandate of SIP. So, we like to see that it MUST deal with mobility as well *NO* !! Part of SIPs mandate is *personal* mobility, as a user moves from device to device. Personal mobility is a good, useful thing. However, The SIP charter does *NOT* include solving the problem of a device moving through different layer 2 networks. This is a problem for a layer 3 protocol to solve generically. If Mobile IP doesn't do what we need it to, then lets extend it, fix it, or replace it. thanks, -rohan >because people will use it in mobile environment (for both intra- and >inter-session). > >For inter-session, I guess that there may be some involvement of REGISTER >and re-INVITE messages (because of change in location). > >That's all! > >All works are done in the lower layer and SIP is not involved (for example, >some one in the lower layer will find that the location has been changed, >accordingly the upper layer may take some actions, if needed). > >Hope this will clarify the things. > >Best regards, >Radhika R. Roy >AT&T > >-----Original Message----- >From: Brian Stucker [mailto:bstucker@nortelnetworks.com] >Sent: Friday, September 29, 2000 1:19 PM >To: sip@lists.bell-labs.com >Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP Mobility ) > > > >My intent isn't to confuse anyone. Quite the contrary. > >My point is that SIP, as an application, should not be concerned about the >vagaries of the underlying media it's being carried on. All applications >that use IP as a transport are going to have to contend with mobility in the >IP space on the intra-session timescale. So IP should solve the problem >because it's a general problem for IP. > >SIP does enough to handle inter-session mobility (I'm at my desk, I'm at >home), and not impede intra-session mobility. It's just simply not suited >for handling anything else because of the nature of the protocol. Any >intra-session mobility must be handled out-of-band as far as SIP is >concerned, and SIP must not make any requirements that would impede this. > >Again, to use wireless voice calls as an example, even with dedicated >transport links, thousands of pages of standards with CDMA/TDMA, IS-41, SS7, >and TCAP, a mobile switching center doesn't attempt to do what you guys are >talking about. It doesn't update the location of a mobile once it's handed >over to another switch in the location database until after your call has >completed, and the mobile registers on the system it moved into. Why? >Because the mobile could be handed back over to the first system, the >handoff could fail, etc. So they don't even attempt to keep the exact >location of the mobile up to date outside of the original switch until the >mobile is stable again, when the call ends. Instead, all incoming calls go >to the first switch, and that switch knows where to go from there to get the >call completed. > >SIP shouldn't be updating the location database every time a wireless >terminal moves around. Some sort of mobile IP proxy function, should instead >be used that knows how to currently find the terminal in it's mobile-aware >IP space. It should route based on the inbound packet's IP address only, and >not care what the payload data is either. > >That solves the problem for SIP, HTTP, FTP, POP3, RTP, you name it. Why >write an extension to every protocol that uses IP as a transport (and have >it solved, and debugged a million different ways) instead of just fixing the >problem at the IP layer (and have it solved, and debugged one way)? > >Brian Stucker >Nortel Networks > >-----Original Message----- >From: Roy, Radhika R, ALCOO [ mailto:rrroy@att.com ] >Sent: Friday, September 29, 2000 11:39 AM >To: hammer michael; Michael Thomas; Henry Sinnreich >Cc: Lewis Karl-QA3387; 'Henning Schulzrinne'; sip@lists.bell-labs.com >Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP >Mobility ) > > >Hi, Everyone: > >The need for addressing mobility is clear and SIP is only one part of the >whole equation. > >Let us not confuse people in the name of Pandora's box or otherwise. > >We have to meet the needs solving problems (not to show our back). > >For the SIP WG, it is the SIP session layer that needs to be addressed, if >it turns out that is a need to do some works. > >Best regards, >Radhika R. Roy >AT&T > >-----Original Message----- >From: hammer michael [ mailto:mhammer@cisco.com ] > >Sent: Friday, September 29, 2000 1:57 PM >To: Roy, Radhika R, ALCOO; Michael Thomas; Henry Sinnreich >Cc: Lewis Karl-QA3387; 'Henning Schulzrinne'; sip@lists.bell-labs.com >Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP >Mobility ) > > >I think Brian aptly pointed out the Pandora's box you open with "mobility." >That should be sufficient motivation to avoid that type of mobility in SIP. > >We are talking about different timescales, e.g.: per packet, per call, and >per registration. > >I thought your term "discrete" captured the idea that the type of >"mobility" you refer to is of the: call me at the office, then later, call >me at home, I'm here now "mobility." Because mobility conjures up so many >more issues, I like the word "presence" better. Presence management may be >more descriptive that mobility management. > >Mike > > >At 04:11 PM 09/28/2000 -0400, Roy, Radhika R, ALCOO wrote: > >Hi, Mike: > > > >Yes, we will have problems if we do not define the terms accurately. > > > >Let us assume that we are using SIP (RFC 2543) and its session layer as our > > >reference. Location, registration, and session are defined in SIP. > > > >Paging (and probably "path") has not been defined in SIP. I will not argue > >to take this abstraction in the SIP layer for now. > > > >Point of attachment has been used as a generic term to indicate "address of > > >the attachment." If we translate this abstraction in the SIP layer, it will > > >mean the addresses that are being used in the SIP layer (e.g., E.164, IP > >address, etc.). > > > >Now let us examine your points: Presence of a person or terminal, etc. > > > >In the SIP layer, I guess, that the presence of a person on a terminal >needs > >to be abstracted in terms of an "address." If that address is also related > >to the point of attachment, then it will also be related to mobility. > > > >(A person behind the terminal may have another ID to deal with personal > >mobility. Let us not address that personal mobility for now.) > > > >In this way, we can extend our analysis for each layer. > > > >Does this answer your question? > > > >Best regards, > >Radhika R. Roy > >AT&T > > > >-----Original Message----- > >From: hammer michael [ mailto:mhammer@cisco.com >] > >Sent: Thursday, September 28, 2000 6:29 PM > >To: Roy, Radhika R, ALCOO; Michael Thomas; Henry Sinnreich > >Cc: Lewis Karl-QA3387; 'Henning Schulzrinne'; sip@lists.bell-labs.com > >Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP > >Mobility ) > > > > > >Roy, > > > >I need to be very careful what word I choose. Session connection rather > >than path might have been more appropriate. I believe confusion can occur > >if the type of location, registration, location, paging, etc. is not > >accurately defined. I think that the intent of such services revolves > >about maintaining relationships between certain elements, such as between: > > > >user/application and terminal, > >terminal and network end-point, > >network end-point and link end-point, etc. > > > >The act of "registering" may mean different things at different layers and > >use different mechanisms to accomplish them. The question for me is > >whether these are handled independently or does one mechanism attempt to > >manage multiple associations or would one type of registration trigger > >another type at a different layer? > > > >Would SIP then manage the "presence" of a person on a terminal, where > >something else manages the "presence" of a terminal on the network? > > > >Mike Hammer > > > > > >At 12:28 PM 09/28/2000 -0400, Roy, Radhika R, ALCOO wrote: > > >Hi, Mike: > > > > > >You have made excellent points. In fact, you are in the heart of this > > >problem: How the communications path(s) needs to be established as the > >point > > >of attachment is changed during the contiguous mobility. > > > > > >I personally believe that SIP does not need to be involved to set up the > > >communications path(s) per se. > > > > > >However, SIP needs to be used to set up the session: re-INVITE (to the >new > > >address) may need to be used. > > > > > >In the process, location updates, paging, etc. are also involved. If the > > >location update does not have any impact in the SIP layer, I do not think > > > >that SIP should be aware of any change in the lower layer. For example, > > >mobile IP has the power of providing location transparency of the IP >layer > > >(although it has some problems to meet the performance requirements for >the > > >real-time communications like voice). > > > > > >In addition to IP addresses, there are also transport addresses (e.g., >UDP, > > >TCP) for media. One also needs to be careful how to deal with the TCP > > >connection. IP addresses change, but the TCP connections still remains >the > > >same. An update mechanism needs to be defined. In turn, does it mean that > > > >this updated information may also be propagated to the SIP layer (other > > >members may also provide comments on this) because SIP does have the > > >abstraction of the transport address? > > > > > >I have not yet talked about the link layer. > > > > > >I am not trying to solve the mobility problem here. > > > > > >All I am trying to show: If we try to analyze the situation doing an > > >end-to-end analysis, we can easily see what needs to be done in each >layer. > > >Finally, we can answer the question: Whether or not any new work is >needed > > >in the SIP layer to address both discrete and continuos mobility. > > > > > >But you are right that we MUST keep the involvement of the SIP layer to a > > > >minimal level (if possible, we should avoid it) to address the mobility > > >problem. > > > > > >Best regards, > > >Radhika R. Roy > > >AT&T > > > > > >-----Original Message----- > > >From: hammer michael [ mailto:mhammer@cisco.com > ] > > >Sent: Thursday, September 28, 2000 2:41 PM > > >To: Roy, Radhika R, ALCOO; Michael Thomas; Henry Sinnreich > > >Cc: Lewis Karl-QA3387; 'Henning Schulzrinne'; sip@lists.bell-labs.com > > >Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP > > >Mobility ) > > > > > > > > >Roy, > > > > > >Your use of the terms "discrete" and "continuous" strike to the heart of > > >the issue. In traditional mobile networks, there is an attempt to move >the > > >stream of media with the terminal as it crosses cell boundaries > > >(continuous). There are many papers related to voice and mobile-IP that > > >address how to move the communications path. > > > > > >The discrete case is more an issue of identification of the presence and > > >availability of recipients and the establishment of communications to > > >them. Because names and addresses denoting physical location are often > > >blurred, in essence, personal mobility involves the creation and deletion > > > >of recipients rather than their movement. > > > > > >As I understand it, SIP does not move existing communications so much as >it > > >destroys existing communications paths and replaces them with new ones. >In > > >that respect, some of the traditional mobility issues such as handover >are > > >avoided, but others, e.g. location updates and paging are still needed. > > > > > >While the telcos reverted to addressing hardware-oriented terminal >mobility > > >in PCS, the softer personal mobility is still open to definition. The >same > > >issues have appeared in the net world and each will need to be solved in > > >their respective layers. > > > > > >Mike > > > > > > > > >At 11:01 AM 09/28/2000 -0400, Roy, Radhika R, ALCOO wrote: > > > >Hi, Mike: > > > > > > > >In fact, this is the precisely the test why SIP should be involved or >to > >be > > > >enhanced to support mobility (discrete + continuos) in the case of >Voice, > > > >chat, IM, messaging, conferencing, games, and others. > > > > > > > >If it is found that SIP does not need to be involved, I do not think >that > > > >anyone will force it to do this. > > > > > > > >By the way, do you not see that how SIP (RFC 2543) has taken care of >many > > > >aspects of users' discrete mobility? Has it not been be an excellent >way > >of > > > >involving SIP to solve a kind of mobility in the first place (what >other > > > >applications like H.323 is yet to support)? > > > > > > > >Along the same line, if people come up with the ideas that it is better > > >to > > > >enhance SIP functionality to support other aspects of mobility (if > > > >alternative solutions are not there or not acceptable), I do not think > >that > > > >we should have any objections. > > > > > > > >Let us keep our mind open and judge each proposal with its own merits. > > > > > > > >Best regards, > > > >Radhika R. Roy > > > >AT&T > > > > > > > >-----Original Message----- > > > >From: Michael Thomas [ mailto:mat@cisco.com ] > > > >Sent: Wednesday, September 27, 2000 7:01 PM > > > >To: Henry Sinnreich > > > >Cc: Michael Thomas; Roy, Radhika R, ALCOO; Lewis Karl-QA3387; 'Henning > > > >Schulzrinne'; sip@lists.bell-labs.com > > > >Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP > > > >Mobility ) > > > > > > > > > > > >Henry Sinnreich writes: > > > > > >what seems clear is that there are a > > > > > >number of applications which won't be able to do > > > > > >that for a variety of reasons. > > > > > > > > > > Voice, chat, IM, messaging, conferencing, games, etc., are > > > > > plenty of reasons to justify the SIP approach to mobility. > > > > > > > > But what if you could do all of the same things > > > > and not need to modify or involve SIP and have the > > > > additional gain that things like http worked as well? > > > > > > > > Mike > > > > > > > > > > > > > > Henry > > > > > > > > > > >-----Original Message----- > > > > > >From: sip-admin@lists.bell-labs.com > > > > > >[ mailto:sip-admin@lists.bell-labs.com > ]On Behalf Of > > > > > >Michael Thomas > > > > > >Sent: Wednesday, September 27, 2000 8:33 PM > > > > > >To: Roy, Radhika R, ALCOO > > > > > >Cc: Michael Thomas; Lewis Karl-QA3387; 'Henning Schulzrinne'; > > > > > >sip@lists.bell-labs.com > > > > > >Subject: RE: [SIP] Attempt at summarizing current SIP > > > > > >drafts (SIP > > > > > >Mobility ) > > > > > > > > > > > > > > > > > > > > > > > >I guess what I'm having a hard time with is the > > > > > >starting point that assumes that SIP based > > > > > >application mobility is Good Thing. While it's > > > > > >clear that many applications *could* design in > > > > > >mobility, what seems clear is that there are a > > > > > >number of applications which won't be able to do > > > > > >that for a variety of reasons. Assuming that those > > > > > >applications are important too, then we're already > > > > > >stuck with needing to solve for the general > > > > > >problem. > > > > > > > > > > > >Starting out with the assumption that Mobile IP > > > > > >addresses the more general problem seems > > > > > >attractive because a good solution with fast > > > > > >handoff that addresses AAA and QoS would solve > > > > > >most of the application layer problems in a > > > > > >general way rather than just a SIP specific > > > > > >way. > > > > > > > > > > > >There also seems to be an implicit assumption in > > > > > >the draft of linkage of SIP to a AAA function. > > > > > >I'm going to guess that it is along the same line > > > > > >of thinking of the DQoS gate controller idea. The > > > > > >problem I have with that is that it is in the end > > > > > >an optimization on the normal RSVP/COPS pull > > > > > >model. However, things that don't fit into that > > > > > >model still have the non-optimized way of doing > > > > > >QoS authorization. That's probably not the fault > > > > > >of this draft, but it does seem to make the entire > > > > > >draft a cart-before-horse situation. > > > > > > > > > > > > Mike > > > > > > > > > > > >Roy, Radhika R, ALCOO writes: > > > > > > > Hi, Mike: > > > > > > > > > > > > > > I guess that SIP, as you rightly pointed out, is > > > > > >dealing with the signaling > > > > > > > mechanism in the application layer. So, SIP does > > > > > >not need to deal with L3 > > > > > > > media path. > > > > > > > > > > > > > > SIP does deal with addresses of the source and > > > > > >destination(s). > > > > > > > > > > > > > > In mobile environment, the point of attachment > > > > > >(i.e., addresses) changes: 1. > > > > > > > Between the sessions (discrete mobility) and 2. > > > > > >During the session > > > > > > > (continuous mobility). > > > > > > > > > > > > > > The problem that is being addressed is: What is the > > > > > >impact in SIP layer due > > > > > > > to these two kinds of mobility. > > > > > > > > > > > > > > I guess that for discrete mobility, SIP has > > > > > >probably addressed most of the > > > > > > > problems (others may also provide comments on this). > > > > > > > > > > > > > > For continuous mobility, there may need (or may > > > > > >not??) some works in the SIP > > > > > > > layer, if any (others may also provide comments). > > > > > > > > > > > > > > However, SIP can only address the mobility related > > > > > >problems in the > > > > > > > application layer. This alone may not be enough to > > > > > >solve all problems > > > > > > > because some L3 and L2 problems may also need to be > > > > > >addressed at the same > > > > > > > time to have the complete solution. > > > > > > > > > > > > > > In any solution, SIP mobility needs to be limited > > > > > >only to the application > > > > > > > layer (not L3, L2, etc.). > > > > > > > > > > > > > > Best regards, > > > > > > > Radhika R. Roy > > > > > > > AT&T > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Michael Thomas [ mailto:mat@cisco.com > ] > > > > > > > Sent: Wednesday, September 27, 2000 12:32 PM > > > > > > > To: Lewis Karl-QA3387 > > > > > > > Cc: 'Henning Schulzrinne'; sip@lists.bell-labs.com > > > > > > > Subject: RE: [SIP] Attempt at summarizing current SIP drafts > > > > > > > > > > > > > > > > > > > > > > > > > > > > While I'm more than willing to believe that there > > > > > > > are mobility issues that SIP needs to deal with, > > > > > > > this paper seems to be positing SIP as the means > > > > > > > of initiating data sessions altogether. To my > > > > > > > mind, that's a rather bellheaded way of thinking > > > > > > > about how you do what amounts to L3 admission > > > > > > > control. In fact, the IETF already has an L3 > > > > > > > admission control mechanism: RSVP. RSVP's main > > > > > > > advantage is that it follows actual network > > > > > > > topology. SIP is at a distinct disadvantage since > > > > > > > all it knows about is the signaling path which > > > > > > > in normal circumstances has nothing to do with > > > > > > > the actual data path. > > > > > > > > > > > > > > Maybe I'm misreading this whole paper, but it sure > > > > > > > looks like it to me. If my interpretation is > > > > > > > right, however, I'd like to know if the intention > > > > > > > is to signal the access routers providing the > > > > > > > L2/L3 bits using SIP instead of, say, COPS (or > > > > > > > DIAMETER). If so, I'd say that SIP truly has > > > > > > > arrived at becoming the new millenium's kitchen > > > > > > > sink if this is accepted. > > > > > > > > > > > > > > Mike > > > > > > > > > > > > > > Lewis Karl-QA3387 writes: > > > > > > > > I have just reviewed the Mobility Related drafts > > > > > >and am wondering if > > > > > > > anyone > > > > > > > > is aware of the current status of > > > > > >draft-itsumo-sip -mobility-req-01. In > > > > > > > > particular, several issues were identified such > > > > > >as Mobile IP not being > > > > > > > > sufficient for personal mobility and location > > > > > >services, completing > > > > > > > > registration in less than a few seconds, > > > > > >reconfiguration in milliseconds, > > > > > > > > providing location services, support of inter > > > > > >domain soft-hand and secure > > > > > > > > signaling. Have these issues been addressed or > > > > > >actively being worked? > > > > > > > > > > > > > > > > Karl > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Henning Schulzrinne > > > > > [ mailto:schulzrinne@cs.columbia.edu > ] > > > > > > > Sent: Monday, September 25, 2000 9:20 AM > > > > > > > To: sip@lists.bell-labs.com > > > > > > > Subject: [SIP] Attempt at summarizing current SIP drafts > > > > > > > > > > > > > > > > > > > > > Given the proliferation of SIP-related drafts, I've > > > > > created a summary of > > > > > > > efforts at > > > > > http://www.cs.columbia.edu/~hgs/sip/drafts.html > . This is > > > > > > > known to be incomplete, so I'd appreciate if you could > > > > > send me any > > > > > > > additions or corrections. (Jonathan Rosenberg provided > > > > > some of the text; > > > > > > > any mistakes or misrepresentations are mine.) > > > > > > > > > > > > > > It is fairly clear that there are a large number of drafts > > > > > that have not > > > > > > > changed materially for half a year or more. Maybe it's > > > > > time to have a WG > > > > > > > last call or two or ten... > > > > > > > > > > > > > > Henning > > > > > > > -- > > > > > > > Henning Schulzrinne http://www.cs.columbia.edu/~hgs > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > SIP mailing list > > > > > > > SIP@lists.bell-labs.com > > > > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > SIP mailing list > > > > > > > SIP@lists.bell-labs.com > > > > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > SIP mailing list > > > > > > SIP@lists.bell-labs.com > > > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > > > > > > _______________________________________________ > > > > > > SIP mailing list > > > > > > SIP@lists.bell-labs.com > > > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > SIP mailing list > > > > > SIP@lists.bell-labs.com > > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > > > > > > > > > > > >_______________________________________________ > > > >SIP mailing list > > > >SIP@lists.bell-labs.com > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > >_______________________________________________ > > > >SIP mailing list > > > >SIP@lists.bell-labs.com > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > >_______________________________________________ >SIP mailing list >SIP@lists.bell-labs.com >http://lists.bell-labs.com/mailman/listinfo/sip > > > >_______________________________________________ >SIP mailing list >SIP@lists.bell-labs.com >http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 4 17:33:56 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA02267 for ; Wed, 4 Oct 2000 17:33:56 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id EB04E44401; Wed, 4 Oct 2000 16:24:09 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from zrtps06u.us.nortel.com (unknown [47.140.48.52]) by lists.bell-labs.com (Postfix) with ESMTP id 11E5C443FB for ; Wed, 4 Oct 2000 16:23:54 -0400 (EDT) Received: from smtprch2.nortel.com (erchg0k.us.nortel.com [47.113.64.104]) by zrtps06u.us.nortel.com (8.11.0/8.11.0) with ESMTP id e94LNnL18428 for ; Wed, 4 Oct 2000 17:23:49 -0400 (EDT) Received: from zrchb200.us.nortel.com (actually zrchb200) by smtprch2.nortel.com; Wed, 4 Oct 2000 16:19:44 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Wed, 4 Oct 2000 16:23:38 -0500 Message-ID: <36FA02BD7083D411BC9E0000F8073E43D05846@crchy271.us.nortel.com> From: "Brian Stucker" To: Rohan Mahy , "Roy, Radhika R, ALCOO" Cc: sip@lists.bell-labs.com Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP Mobility ) MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C02E49.5AED10F0" X-Orig: Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 4 Oct 2000 16:23:35 -0500 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_01C02E49.5AED10F0 Content-Type: text/plain; charset="iso-8859-1" I definitely agree with that sentiment. That was the point of my argument. Do nothing in regards to SIP, and if there's something particular to SIP that needs to be addressed in a layer below SIP, then we should be trying to inject requirements and influence the decisions being made there first. Brian -----Original Message----- From: Rohan Mahy [mailto:rohan@cisco.com] Sent: Wednesday, October 04, 2000 3:14 PM To: Roy, Radhika R, ALCOO Cc: Stucker, Brian [RICH2:WI12:EXCH]; sip@lists.bell-labs.com Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP Mobility ) At 10:51 AM 9/29/00 , Roy, Radhika R, ALCOO wrote: >Hi, Brian: > >I guess that your mail has provided some technical inputs: 1. Inter-session >mobility and 2. Intra-session mobility. > >For inter-session mobility, you think that SIP in OK. > >For intra-session mobility, it appears that you are feeling comfortable, as >if, SIP is not designed to do this. > >Let us go to the basic: SIP is a session initiation protocol. It is the >mandate of SIP. So, we like to see that it MUST deal with mobility as well *NO* !! Part of SIPs mandate is *personal* mobility, as a user moves from device to device. Personal mobility is a good, useful thing. However, The SIP charter does *NOT* include solving the problem of a device moving through different layer 2 networks. This is a problem for a layer 3 protocol to solve generically. If Mobile IP doesn't do what we need it to, then lets extend it, fix it, or replace it. thanks, -rohan >because people will use it in mobile environment (for both intra- and >inter-session). > >For inter-session, I guess that there may be some involvement of REGISTER >and re-INVITE messages (because of change in location). > >That's all! > >All works are done in the lower layer and SIP is not involved (for example, >some one in the lower layer will find that the location has been changed, >accordingly the upper layer may take some actions, if needed). > >Hope this will clarify the things. > >Best regards, >Radhika R. Roy >AT&T > >-----Original Message----- >From: Brian Stucker [mailto:bstucker@nortelnetworks.com] >Sent: Friday, September 29, 2000 1:19 PM >To: sip@lists.bell-labs.com >Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP Mobility ) > > > >My intent isn't to confuse anyone. Quite the contrary. > >My point is that SIP, as an application, should not be concerned about the >vagaries of the underlying media it's being carried on. All applications >that use IP as a transport are going to have to contend with mobility in the >IP space on the intra-session timescale. So IP should solve the problem >because it's a general problem for IP. > >SIP does enough to handle inter-session mobility (I'm at my desk, I'm at >home), and not impede intra-session mobility. It's just simply not suited >for handling anything else because of the nature of the protocol. Any >intra-session mobility must be handled out-of-band as far as SIP is >concerned, and SIP must not make any requirements that would impede this. > >Again, to use wireless voice calls as an example, even with dedicated >transport links, thousands of pages of standards with CDMA/TDMA, IS-41, SS7, >and TCAP, a mobile switching center doesn't attempt to do what you guys are >talking about. It doesn't update the location of a mobile once it's handed >over to another switch in the location database until after your call has >completed, and the mobile registers on the system it moved into. Why? >Because the mobile could be handed back over to the first system, the >handoff could fail, etc. So they don't even attempt to keep the exact >location of the mobile up to date outside of the original switch until the >mobile is stable again, when the call ends. Instead, all incoming calls go >to the first switch, and that switch knows where to go from there to get the >call completed. > >SIP shouldn't be updating the location database every time a wireless >terminal moves around. Some sort of mobile IP proxy function, should instead >be used that knows how to currently find the terminal in it's mobile-aware >IP space. It should route based on the inbound packet's IP address only, and >not care what the payload data is either. > >That solves the problem for SIP, HTTP, FTP, POP3, RTP, you name it. Why >write an extension to every protocol that uses IP as a transport (and have >it solved, and debugged a million different ways) instead of just fixing the >problem at the IP layer (and have it solved, and debugged one way)? > >Brian Stucker >Nortel Networks > >-----Original Message----- >From: Roy, Radhika R, ALCOO [ mailto:rrroy@att.com ] >Sent: Friday, September 29, 2000 11:39 AM >To: hammer michael; Michael Thomas; Henry Sinnreich >Cc: Lewis Karl-QA3387; 'Henning Schulzrinne'; sip@lists.bell-labs.com >Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP >Mobility ) > > >Hi, Everyone: > >The need for addressing mobility is clear and SIP is only one part of the >whole equation. > >Let us not confuse people in the name of Pandora's box or otherwise. > >We have to meet the needs solving problems (not to show our back). > >For the SIP WG, it is the SIP session layer that needs to be addressed, if >it turns out that is a need to do some works. > >Best regards, >Radhika R. Roy >AT&T > >-----Original Message----- >From: hammer michael [ mailto:mhammer@cisco.com ] > >Sent: Friday, September 29, 2000 1:57 PM >To: Roy, Radhika R, ALCOO; Michael Thomas; Henry Sinnreich >Cc: Lewis Karl-QA3387; 'Henning Schulzrinne'; sip@lists.bell-labs.com >Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP >Mobility ) > > >I think Brian aptly pointed out the Pandora's box you open with "mobility." >That should be sufficient motivation to avoid that type of mobility in SIP. > >We are talking about different timescales, e.g.: per packet, per call, and >per registration. > >I thought your term "discrete" captured the idea that the type of >"mobility" you refer to is of the: call me at the office, then later, call >me at home, I'm here now "mobility." Because mobility conjures up so many >more issues, I like the word "presence" better. Presence management may be >more descriptive that mobility management. > >Mike > > >At 04:11 PM 09/28/2000 -0400, Roy, Radhika R, ALCOO wrote: > >Hi, Mike: > > > >Yes, we will have problems if we do not define the terms accurately. > > > >Let us assume that we are using SIP (RFC 2543) and its session layer as our > > >reference. Location, registration, and session are defined in SIP. > > > >Paging (and probably "path") has not been defined in SIP. I will not argue > >to take this abstraction in the SIP layer for now. > > > >Point of attachment has been used as a generic term to indicate "address of > > >the attachment." If we translate this abstraction in the SIP layer, it will > > >mean the addresses that are being used in the SIP layer (e.g., E.164, IP > >address, etc.). > > > >Now let us examine your points: Presence of a person or terminal, etc. > > > >In the SIP layer, I guess, that the presence of a person on a terminal >needs > >to be abstracted in terms of an "address." If that address is also related > >to the point of attachment, then it will also be related to mobility. > > > >(A person behind the terminal may have another ID to deal with personal > >mobility. Let us not address that personal mobility for now.) > > > >In this way, we can extend our analysis for each layer. > > > >Does this answer your question? > > > >Best regards, > >Radhika R. Roy > >AT&T > > > >-----Original Message----- > >From: hammer michael [ mailto:mhammer@cisco.com >] > >Sent: Thursday, September 28, 2000 6:29 PM > >To: Roy, Radhika R, ALCOO; Michael Thomas; Henry Sinnreich > >Cc: Lewis Karl-QA3387; 'Henning Schulzrinne'; sip@lists.bell-labs.com > >Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP > >Mobility ) > > > > > >Roy, > > > >I need to be very careful what word I choose. Session connection rather > >than path might have been more appropriate. I believe confusion can occur > >if the type of location, registration, location, paging, etc. is not > >accurately defined. I think that the intent of such services revolves > >about maintaining relationships between certain elements, such as between: > > > >user/application and terminal, > >terminal and network end-point, > >network end-point and link end-point, etc. > > > >The act of "registering" may mean different things at different layers and > >use different mechanisms to accomplish them. The question for me is > >whether these are handled independently or does one mechanism attempt to > >manage multiple associations or would one type of registration trigger > >another type at a different layer? > > > >Would SIP then manage the "presence" of a person on a terminal, where > >something else manages the "presence" of a terminal on the network? > > > >Mike Hammer > > > > > >At 12:28 PM 09/28/2000 -0400, Roy, Radhika R, ALCOO wrote: > > >Hi, Mike: > > > > > >You have made excellent points. In fact, you are in the heart of this > > >problem: How the communications path(s) needs to be established as the > >point > > >of attachment is changed during the contiguous mobility. > > > > > >I personally believe that SIP does not need to be involved to set up the > > >communications path(s) per se. > > > > > >However, SIP needs to be used to set up the session: re-INVITE (to the >new > > >address) may need to be used. > > > > > >In the process, location updates, paging, etc. are also involved. If the > > >location update does not have any impact in the SIP layer, I do not think > > > >that SIP should be aware of any change in the lower layer. For example, > > >mobile IP has the power of providing location transparency of the IP >layer > > >(although it has some problems to meet the performance requirements for >the > > >real-time communications like voice). > > > > > >In addition to IP addresses, there are also transport addresses (e.g., >UDP, > > >TCP) for media. One also needs to be careful how to deal with the TCP > > >connection. IP addresses change, but the TCP connections still remains >the > > >same. An update mechanism needs to be defined. In turn, does it mean that > > > >this updated information may also be propagated to the SIP layer (other > > >members may also provide comments on this) because SIP does have the > > >abstraction of the transport address? > > > > > >I have not yet talked about the link layer. > > > > > >I am not trying to solve the mobility problem here. > > > > > >All I am trying to show: If we try to analyze the situation doing an > > >end-to-end analysis, we can easily see what needs to be done in each >layer. > > >Finally, we can answer the question: Whether or not any new work is >needed > > >in the SIP layer to address both discrete and continuos mobility. > > > > > >But you are right that we MUST keep the involvement of the SIP layer to a > > > >minimal level (if possible, we should avoid it) to address the mobility > > >problem. > > > > > >Best regards, > > >Radhika R. Roy > > >AT&T > > > > > >-----Original Message----- > > >From: hammer michael [ mailto:mhammer@cisco.com > ] > > >Sent: Thursday, September 28, 2000 2:41 PM > > >To: Roy, Radhika R, ALCOO; Michael Thomas; Henry Sinnreich > > >Cc: Lewis Karl-QA3387; 'Henning Schulzrinne'; sip@lists.bell-labs.com > > >Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP > > >Mobility ) > > > > > > > > >Roy, > > > > > >Your use of the terms "discrete" and "continuous" strike to the heart of > > >the issue. In traditional mobile networks, there is an attempt to move >the > > >stream of media with the terminal as it crosses cell boundaries > > >(continuous). There are many papers related to voice and mobile-IP that > > >address how to move the communications path. > > > > > >The discrete case is more an issue of identification of the presence and > > >availability of recipients and the establishment of communications to > > >them. Because names and addresses denoting physical location are often > > >blurred, in essence, personal mobility involves the creation and deletion > > > >of recipients rather than their movement. > > > > > >As I understand it, SIP does not move existing communications so much as >it > > >destroys existing communications paths and replaces them with new ones. >In > > >that respect, some of the traditional mobility issues such as handover >are > > >avoided, but others, e.g. location updates and paging are still needed. > > > > > >While the telcos reverted to addressing hardware-oriented terminal >mobility > > >in PCS, the softer personal mobility is still open to definition. The >same > > >issues have appeared in the net world and each will need to be solved in > > >their respective layers. > > > > > >Mike > > > > > > > > >At 11:01 AM 09/28/2000 -0400, Roy, Radhika R, ALCOO wrote: > > > >Hi, Mike: > > > > > > > >In fact, this is the precisely the test why SIP should be involved or >to > >be > > > >enhanced to support mobility (discrete + continuos) in the case of >Voice, > > > >chat, IM, messaging, conferencing, games, and others. > > > > > > > >If it is found that SIP does not need to be involved, I do not think >that > > > >anyone will force it to do this. > > > > > > > >By the way, do you not see that how SIP (RFC 2543) has taken care of >many > > > >aspects of users' discrete mobility? Has it not been be an excellent >way > >of > > > >involving SIP to solve a kind of mobility in the first place (what >other > > > >applications like H.323 is yet to support)? > > > > > > > >Along the same line, if people come up with the ideas that it is better > > >to > > > >enhance SIP functionality to support other aspects of mobility (if > > > >alternative solutions are not there or not acceptable), I do not think > >that > > > >we should have any objections. > > > > > > > >Let us keep our mind open and judge each proposal with its own merits. > > > > > > > >Best regards, > > > >Radhika R. Roy > > > >AT&T > > > > > > > >-----Original Message----- > > > >From: Michael Thomas [ mailto:mat@cisco.com ] > > > >Sent: Wednesday, September 27, 2000 7:01 PM > > > >To: Henry Sinnreich > > > >Cc: Michael Thomas; Roy, Radhika R, ALCOO; Lewis Karl-QA3387; 'Henning > > > >Schulzrinne'; sip@lists.bell-labs.com > > > >Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP > > > >Mobility ) > > > > > > > > > > > >Henry Sinnreich writes: > > > > > >what seems clear is that there are a > > > > > >number of applications which won't be able to do > > > > > >that for a variety of reasons. > > > > > > > > > > Voice, chat, IM, messaging, conferencing, games, etc., are > > > > > plenty of reasons to justify the SIP approach to mobility. > > > > > > > > But what if you could do all of the same things > > > > and not need to modify or involve SIP and have the > > > > additional gain that things like http worked as well? > > > > > > > > Mike > > > > > > > > > > > > > > Henry > > > > > > > > > > >-----Original Message----- > > > > > >From: sip-admin@lists.bell-labs.com > > > > > >[ mailto:sip-admin@lists.bell-labs.com > ]On Behalf Of > > > > > >Michael Thomas > > > > > >Sent: Wednesday, September 27, 2000 8:33 PM > > > > > >To: Roy, Radhika R, ALCOO > > > > > >Cc: Michael Thomas; Lewis Karl-QA3387; 'Henning Schulzrinne'; > > > > > >sip@lists.bell-labs.com > > > > > >Subject: RE: [SIP] Attempt at summarizing current SIP > > > > > >drafts (SIP > > > > > >Mobility ) > > > > > > > > > > > > > > > > > > > > > > > >I guess what I'm having a hard time with is the > > > > > >starting point that assumes that SIP based > > > > > >application mobility is Good Thing. While it's > > > > > >clear that many applications *could* design in > > > > > >mobility, what seems clear is that there are a > > > > > >number of applications which won't be able to do > > > > > >that for a variety of reasons. Assuming that those > > > > > >applications are important too, then we're already > > > > > >stuck with needing to solve for the general > > > > > >problem. > > > > > > > > > > > >Starting out with the assumption that Mobile IP > > > > > >addresses the more general problem seems > > > > > >attractive because a good solution with fast > > > > > >handoff that addresses AAA and QoS would solve > > > > > >most of the application layer problems in a > > > > > >general way rather than just a SIP specific > > > > > >way. > > > > > > > > > > > >There also seems to be an implicit assumption in > > > > > >the draft of linkage of SIP to a AAA function. > > > > > >I'm going to guess that it is along the same line > > > > > >of thinking of the DQoS gate controller idea. The > > > > > >problem I have with that is that it is in the end > > > > > >an optimization on the normal RSVP/COPS pull > > > > > >model. However, things that don't fit into that > > > > > >model still have the non-optimized way of doing > > > > > >QoS authorization. That's probably not the fault > > > > > >of this draft, but it does seem to make the entire > > > > > >draft a cart-before-horse situation. > > > > > > > > > > > > Mike > > > > > > > > > > > >Roy, Radhika R, ALCOO writes: > > > > > > > Hi, Mike: > > > > > > > > > > > > > > I guess that SIP, as you rightly pointed out, is > > > > > >dealing with the signaling > > > > > > > mechanism in the application layer. So, SIP does > > > > > >not need to deal with L3 > > > > > > > media path. > > > > > > > > > > > > > > SIP does deal with addresses of the source and > > > > > >destination(s). > > > > > > > > > > > > > > In mobile environment, the point of attachment > > > > > >(i.e., addresses) changes: 1. > > > > > > > Between the sessions (discrete mobility) and 2. > > > > > >During the session > > > > > > > (continuous mobility). > > > > > > > > > > > > > > The problem that is being addressed is: What is the > > > > > >impact in SIP layer due > > > > > > > to these two kinds of mobility. > > > > > > > > > > > > > > I guess that for discrete mobility, SIP has > > > > > >probably addressed most of the > > > > > > > problems (others may also provide comments on this). > > > > > > > > > > > > > > For continuous mobility, there may need (or may > > > > > >not??) some works in the SIP > > > > > > > layer, if any (others may also provide comments). > > > > > > > > > > > > > > However, SIP can only address the mobility related > > > > > >problems in the > > > > > > > application layer. This alone may not be enough to > > > > > >solve all problems > > > > > > > because some L3 and L2 problems may also need to be > > > > > >addressed at the same > > > > > > > time to have the complete solution. > > > > > > > > > > > > > > In any solution, SIP mobility needs to be limited > > > > > >only to the application > > > > > > > layer (not L3, L2, etc.). > > > > > > > > > > > > > > Best regards, > > > > > > > Radhika R. Roy > > > > > > > AT&T > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Michael Thomas [ mailto:mat@cisco.com > ] > > > > > > > Sent: Wednesday, September 27, 2000 12:32 PM > > > > > > > To: Lewis Karl-QA3387 > > > > > > > Cc: 'Henning Schulzrinne'; sip@lists.bell-labs.com > > > > > > > Subject: RE: [SIP] Attempt at summarizing current SIP drafts > > > > > > > > > > > > > > > > > > > > > > > > > > > > While I'm more than willing to believe that there > > > > > > > are mobility issues that SIP needs to deal with, > > > > > > > this paper seems to be positing SIP as the means > > > > > > > of initiating data sessions altogether. To my > > > > > > > mind, that's a rather bellheaded way of thinking > > > > > > > about how you do what amounts to L3 admission > > > > > > > control. In fact, the IETF already has an L3 > > > > > > > admission control mechanism: RSVP. RSVP's main > > > > > > > advantage is that it follows actual network > > > > > > > topology. SIP is at a distinct disadvantage since > > > > > > > all it knows about is the signaling path which > > > > > > > in normal circumstances has nothing to do with > > > > > > > the actual data path. > > > > > > > > > > > > > > Maybe I'm misreading this whole paper, but it sure > > > > > > > looks like it to me. If my interpretation is > > > > > > > right, however, I'd like to know if the intention > > > > > > > is to signal the access routers providing the > > > > > > > L2/L3 bits using SIP instead of, say, COPS (or > > > > > > > DIAMETER). If so, I'd say that SIP truly has > > > > > > > arrived at becoming the new millenium's kitchen > > > > > > > sink if this is accepted. > > > > > > > > > > > > > > Mike > > > > > > > > > > > > > > Lewis Karl-QA3387 writes: > > > > > > > > I have just reviewed the Mobility Related drafts > > > > > >and am wondering if > > > > > > > anyone > > > > > > > > is aware of the current status of > > > > > >draft-itsumo-sip -mobility-req-01. In > > > > > > > > particular, several issues were identified such > > > > > >as Mobile IP not being > > > > > > > > sufficient for personal mobility and location > > > > > >services, completing > > > > > > > > registration in less than a few seconds, > > > > > >reconfiguration in milliseconds, > > > > > > > > providing location services, support of inter > > > > > >domain soft-hand and secure > > > > > > > > signaling. Have these issues been addressed or > > > > > >actively being worked? > > > > > > > > > > > > > > > > Karl > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Henning Schulzrinne > > > > > [ mailto:schulzrinne@cs.columbia.edu > ] > > > > > > > Sent: Monday, September 25, 2000 9:20 AM > > > > > > > To: sip@lists.bell-labs.com > > > > > > > Subject: [SIP] Attempt at summarizing current SIP drafts > > > > > > > > > > > > > > > > > > > > > Given the proliferation of SIP-related drafts, I've > > > > > created a summary of > > > > > > > efforts at > > > > > http://www.cs.columbia.edu/~hgs/sip/drafts.html > . This is > > > > > > > known to be incomplete, so I'd appreciate if you could > > > > > send me any > > > > > > > additions or corrections. (Jonathan Rosenberg provided > > > > > some of the text; > > > > > > > any mistakes or misrepresentations are mine.) > > > > > > > > > > > > > > It is fairly clear that there are a large number of drafts > > > > > that have not > > > > > > > changed materially for half a year or more. Maybe it's > > > > > time to have a WG > > > > > > > last call or two or ten... > > > > > > > > > > > > > > Henning > > > > > > > -- > > > > > > > Henning Schulzrinne http://www.cs.columbia.edu/~hgs > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > SIP mailing list > > > > > > > SIP@lists.bell-labs.com > > > > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > SIP mailing list > > > > > > > SIP@lists.bell-labs.com > > > > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > SIP mailing list > > > > > > SIP@lists.bell-labs.com > > > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > > > > > > _______________________________________________ > > > > > > SIP mailing list > > > > > > SIP@lists.bell-labs.com > > > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > SIP mailing list > > > > > SIP@lists.bell-labs.com > > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > > > > > > > > > > > >_______________________________________________ > > > >SIP mailing list > > > >SIP@lists.bell-labs.com > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > >_______________________________________________ > > > >SIP mailing list > > > >SIP@lists.bell-labs.com > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > >_______________________________________________ >SIP mailing list >SIP@lists.bell-labs.com >http://lists.bell-labs.com/mailman/listinfo/sip > > > >_______________________________________________ >SIP mailing list >SIP@lists.bell-labs.com >http://lists.bell-labs.com/mailman/listinfo/sip ------_=_NextPart_001_01C02E49.5AED10F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [SIP] Attempt at summarizing current SIP drafts (SIP = Mobility )

I definitely agree with that sentiment. That was the = point of my argument. Do nothing in regards to SIP, and if there's = something particular to SIP that needs to be addressed in a layer below = SIP, then we should be trying to inject requirements and influence the = decisions being made there first.

Brian

-----Original Message-----
From: Rohan Mahy [mailto:rohan@cisco.com]
Sent: Wednesday, October 04, 2000 3:14 PM
To: Roy, Radhika R, ALCOO
Cc: Stucker, Brian [RICH2:WI12:EXCH]; = sip@lists.bell-labs.com
Subject: RE: [SIP] Attempt at summarizing current = SIP drafts (SIP
Mobility )


At 10:51 AM 9/29/00 , Roy, Radhika R, ALCOO = wrote:
>Hi, Brian:
>
>I guess that your mail has provided some = technical inputs: 1. Inter-session
>mobility and 2. Intra-session mobility.
>
>For inter-session mobility, you think that SIP = in OK.
>
>For intra-session mobility, it appears that you = are feeling comfortable, as
>if, SIP is not designed to do this.
>
>Let us go to the basic: SIP is a session = initiation protocol. It is the
>mandate of SIP. So, we like to see that it MUST = deal with mobility as well

*NO* !!  Part of SIPs mandate is *personal* = mobility, as a user moves from
device to device.  Personal mobility is a good, = useful thing.  However, The
SIP charter does *NOT* include solving the problem = of a device moving
through different layer 2 networks.  This is a = problem for a layer 3
protocol to solve generically.  If Mobile IP = doesn't do what we need it to,
then lets extend it, fix it, or replace it.

thanks,
-rohan

>because people will use it in mobile environment = (for both intra- and
>inter-session).

>
>For inter-session, I guess that there may be = some involvement of REGISTER
>and re-INVITE messages (because of change in = location).
>
>That's all!
>
>All works are done in the lower layer and SIP is = not involved (for example,
>some one in the lower layer will find that the = location has been changed,
>accordingly the upper layer may take some = actions, if needed).
>
>Hope this will clarify the things.
>
>Best regards,
>Radhika R. Roy
>AT&T
>
>-----Original Message-----
>From: Brian Stucker [mailto:bstucker@nortelnetwor= ks.com]
>Sent: Friday, September 29, 2000 1:19 PM
>To: sip@lists.bell-labs.com
>Subject: RE: [SIP] Attempt at summarizing = current SIP drafts (SIP Mobility )
>
>
>
>My intent isn't to confuse anyone. Quite the = contrary.
>
>My point is that SIP, as an application, should = not be concerned about the
>vagaries of the underlying media it's being = carried on. All applications
>that use IP as a transport are going to have to = contend with mobility in the
>IP space on the intra-session timescale. So IP = should solve the problem
>because it's a general problem for IP.
>
>SIP does enough to handle inter-session mobility = (I'm at my desk, I'm at
>home), and not impede intra-session mobility. = It's just simply not suited
>for handling anything else because of the nature = of the protocol. Any
>intra-session mobility must be handled = out-of-band as far as SIP is
>concerned, and SIP must not make any = requirements that would impede this.
>
>Again, to use wireless voice calls as an = example, even with dedicated
>transport links, thousands of pages of standards = with CDMA/TDMA, IS-41, SS7,
>and TCAP, a mobile switching center doesn't = attempt to do what you guys are
>talking about. It doesn't update the location of = a mobile once it's handed
>over to another switch in the location database = until after your call has
>completed, and the mobile registers on the = system it moved into. Why?
>Because the mobile could be handed back over to = the first system, the
>handoff could fail, etc. So they don't even = attempt to keep the exact
>location of the mobile up to date outside of the = original switch until the
>mobile is stable again, when the call ends. = Instead, all incoming calls go
>to the first switch, and that switch knows where = to go from there to get the
>call completed.
>
>SIP shouldn't be updating the location database = every time a wireless
>terminal moves around. Some sort of mobile IP = proxy function, should instead
>be used that knows how to currently find the = terminal in it's mobile-aware
>IP space. It should route based on the inbound = packet's IP address only, and
>not care what the payload data is either.
>
>That solves the problem for SIP, HTTP, FTP, = POP3, RTP, you name it. Why
>write an extension to every protocol that uses = IP as a transport (and have
>it solved, and debugged a million different = ways) instead of just fixing the
>problem at the IP layer (and have it solved, and = debugged one way)?
>
>Brian Stucker
>Nortel Networks
>
>-----Original Message-----
>From: Roy, Radhika R, ALCOO [ mailto:rrroy@att.com <mailto:rrroy@att.com> ]
>Sent: Friday, September 29, 2000 11:39 AM
>To: hammer michael; Michael Thomas; Henry = Sinnreich
>Cc: Lewis Karl-QA3387; 'Henning Schulzrinne'; = sip@lists.bell-labs.com
>Subject: RE: [SIP] Attempt at summarizing = current SIP drafts (SIP
>Mobility )
>
>
>Hi, Everyone:
>
>The need for addressing mobility is clear and = SIP is only one part of the
>whole equation.
>
>Let us not confuse people in the name of = Pandora's box or otherwise.
>
>We have to meet the needs solving problems (not = to show our back).
>
>For the SIP WG, it is the SIP session layer that = needs to be addressed, if
>it turns out that is a need to do some = works.
>
>Best regards,
>Radhika R. Roy
>AT&T
>
>-----Original Message-----
>From: hammer michael [ mailto:mhammer@cisco.com <mailto:mhammer@cisco.com> = ]
>
>Sent: Friday, September 29, 2000 1:57 PM
>To: Roy, Radhika R, ALCOO; Michael Thomas; Henry = Sinnreich
>Cc: Lewis Karl-QA3387; 'Henning Schulzrinne'; = sip@lists.bell-labs.com
>Subject: RE: [SIP] Attempt at summarizing = current SIP drafts (SIP
>Mobility )
>
>
>I think Brian aptly pointed out the Pandora's = box you open with "mobility."
>That should be sufficient motivation to avoid = that type of mobility in SIP.
>
>We are talking about different timescales, = e.g.:  per packet, per call, and
>per registration.
>
>I thought your term "discrete" = captured the idea that the type of
>"mobility" you refer to is of = the:  call me at the office, then later, call
>me at home, I'm here now = "mobility."  Because mobility conjures up so many
>more issues, I like the word = "presence" better.  Presence management may be
>more descriptive that mobility = management.
>
>Mike
>
>
>At 04:11 PM 09/28/2000 -0400, Roy, Radhika R, = ALCOO wrote:
> >Hi, Mike:
> >
> >Yes, we will have problems if we do not = define the terms accurately.
> >
> >Let us assume that we are using SIP (RFC = 2543) and its session layer as our
>
> >reference. Location, registration, and = session are defined in SIP.
> >
> >Paging (and probably "path") has = not been defined in SIP. I will not argue
> >to take this abstraction in the SIP layer = for now.
> >
> >Point of attachment has been used as a = generic term to indicate "address of
>
> >the attachment." If we translate this = abstraction in the SIP layer, it will
>
> >mean the addresses that are being used in = the SIP layer (e.g., E.164, IP
> >address, etc.).
> >
> >Now let us examine your points: Presence of = a person or terminal, etc.
> >
> >In the SIP layer, I guess, that the = presence of a person on a terminal
>needs
> >to be abstracted in terms of an = "address." If that address is also related
> >to the point of attachment, then it will = also be related to mobility.
> >
> >(A person behind the terminal may have = another ID to deal with personal
> >mobility. Let us not address that personal = mobility for now.)
> >
> >In this way, we can extend our analysis for = each layer.
> >
> >Does this answer your question?
> >
> >Best regards,
> >Radhika R. Roy
> >AT&T
> >
> >-----Original Message-----
> >From: hammer michael [ mailto:mhammer@cisco.com <mailto:mhammer@cisco.com>
>]
> >Sent: Thursday, September 28, 2000 6:29 = PM
> >To: Roy, Radhika R, ALCOO; Michael Thomas; = Henry Sinnreich
> >Cc: Lewis Karl-QA3387; 'Henning = Schulzrinne'; sip@lists.bell-labs.com
> >Subject: RE: [SIP] Attempt at summarizing = current SIP drafts (SIP
> >Mobility )
> >
> >
> >Roy,
> >
> >I need to be very careful what word I = choose.  Session connection rather
> >than path might have been more = appropriate.  I believe confusion can occur
> >if the type of location, registration, = location, paging, etc. is not
> >accurately defined.  I think that the = intent of such services revolves
> >about maintaining relationships between = certain elements, such as between:
> >
> >user/application and terminal,
> >terminal and network end-point,
> >network end-point and link end-point, = etc.
> >
> >The act of "registering" may mean = different things at different layers and
> >use different mechanisms to accomplish = them.  The question for me is
> >whether these are handled independently or = does one mechanism attempt to
> >manage multiple associations or would one = type of registration trigger
> >another type at a different layer?
> >
> >Would SIP then manage the = "presence" of a person on a terminal, where
> >something else manages the = "presence" of a terminal on the network?
> >
> >Mike Hammer
> >
> >
> >At 12:28 PM 09/28/2000 -0400, Roy, Radhika = R, ALCOO wrote:
> > >Hi, Mike:
> > >
> > >You have made excellent points. In = fact, you are in the heart of this
> > >problem: How the communications = path(s) needs to be established as the
> >point
> > >of attachment is changed during the = contiguous mobility.
> > >
> > >I personally believe that SIP does not = need to be involved to set up the
> > >communications path(s) per se.
> > >
> > >However, SIP needs to be used to set = up the session: re-INVITE (to the
>new
> > >address) may need to be used.
> > >
> > >In the process, location updates, = paging, etc. are also involved. If the
> > >location update does not have any = impact in the SIP layer, I do not think
>
> > >that SIP should be aware of any change = in the lower layer. For example,
> > >mobile IP has the power of providing = location transparency of the IP
>layer
> > >(although it has some problems to meet = the performance requirements for
>the
> > >real-time communications like = voice).
> > >
> > >In addition to IP addresses, there are = also transport addresses (e.g.,
>UDP,
> > >TCP) for media. One also needs to be = careful how to deal with the TCP
> > >connection. IP addresses change, but = the TCP connections still remains
>the
> > >same. An update mechanism needs to be = defined. In turn, does it mean that
>
> > >this updated information may also be = propagated to the SIP layer (other
> > >members may also provide comments on = this) because SIP does have the
> > >abstraction of the transport = address?
> > >
> > >I have not yet talked about the link = layer.
> > >
> > >I am not trying to solve the mobility = problem here.
> > >
> > >All I am trying to show: If we try to = analyze the situation doing an
> > >end-to-end analysis, we can easily see = what needs to be done in each
>layer.
> > >Finally, we can answer the question: = Whether or not any new work is
>needed
> > >in the SIP layer to address both = discrete and continuos mobility.
> > >
> > >But you are right that we MUST keep = the involvement of the SIP layer to a
>
> > >minimal level (if possible, we should = avoid it) to address the mobility
> > >problem.
> > >
> > >Best regards,
> > >Radhika R. Roy
> > >AT&T
> > >
> > >-----Original Message-----
> > >From: hammer michael [ mailto:mhammer@cisco.com
><mailto:mhammer@cisco.com> = ]
> > >Sent: Thursday, September 28, 2000 = 2:41 PM
> > >To: Roy, Radhika R, ALCOO; Michael = Thomas; Henry Sinnreich
> > >Cc: Lewis Karl-QA3387; 'Henning = Schulzrinne'; sip@lists.bell-labs.com
> > >Subject: RE: [SIP] Attempt at = summarizing current SIP drafts (SIP
> > >Mobility )
> > >
> > >
> > >Roy,
> > >
> > >Your use of the terms = "discrete" and "continuous" strike to the heart = of
> > >the issue.  In traditional mobile = networks, there is an attempt to move
>the
> > >stream of media with the terminal as = it crosses cell boundaries
> > >(continuous).  There are many = papers related to voice and mobile-IP that
> > >address how to move the communications = path.
> > >
> > >The discrete case is more an issue of = identification of the presence and
> > >availability of recipients and the = establishment of communications to
> > >them.  Because names and = addresses denoting physical location are often
> > >blurred, in essence, personal mobility = involves the creation and deletion
>
> > >of recipients rather than their = movement.
> > >
> > >As I understand it, SIP does not move = existing communications so much as
>it
> > >destroys existing communications paths = and replaces them with new ones.
>In
> > >that respect, some of the traditional = mobility issues such as handover
>are
> > >avoided, but others, e.g. location = updates and paging are still needed.
> > >
> > >While the telcos reverted to = addressing hardware-oriented terminal
>mobility
> > >in PCS, the softer personal mobility = is still open to definition.  The
>same
> > >issues have appeared in the net world = and each will need to be solved in
> > >their respective layers.
> > >
> > >Mike
> > >
> > >
> > >At 11:01 AM 09/28/2000 -0400, Roy, = Radhika R, ALCOO wrote:
> > > >Hi, Mike:
> > > >
> > > >In fact, this is the precisely = the test why SIP should be involved or
>to
> >be
> > > >enhanced to support mobility = (discrete + continuos) in the case of
>Voice,
> > > >chat, IM, messaging, = conferencing, games, and others.
> > > >
> > > >If it is found that SIP does not = need to be involved, I do not think
>that
> > > >anyone will force it to do = this.
> > > >
> > > >By the way, do you not see that = how SIP (RFC 2543) has taken care of
>many
> > > >aspects of users' discrete = mobility? Has it not been be an excellent
>way
> >of
> > > >involving SIP to solve a kind of = mobility in the first place (what
>other
> > > >applications like H.323 is yet to = support)?
> > > >
> > > >Along the same line, if people = come up with the ideas that it is better
>
> >to
> > > >enhance SIP functionality to = support other aspects of mobility (if
> > > >alternative solutions are not = there or not acceptable), I do not think
> >that
> > > >we should have any = objections.
> > > >
> > > >Let us keep our mind open and = judge each proposal with its own merits.
> > > >
> > > >Best regards,
> > > >Radhika R. Roy
> > > >AT&T
> > > >
> > > >-----Original Message-----
> > > >From: Michael Thomas [ mailto:mat@cisco.com <mailto:mat@cisco.com> ]
> > > >Sent: Wednesday, September 27, = 2000 7:01 PM
> > > >To: Henry Sinnreich
> > > >Cc: Michael Thomas; Roy, Radhika = R, ALCOO; Lewis Karl-QA3387; 'Henning
> > > >Schulzrinne'; = sip@lists.bell-labs.com
> > > >Subject: RE: [SIP] Attempt at = summarizing current SIP drafts (SIP
> > > >Mobility )
> > > >
> > > >
> > > >Henry Sinnreich writes:
> > > >  > >what seems clear = is that there are a
> > > >  > >number of = applications which won't be able to do
> > > >  > >that for a = variety of reasons.
> > > >  >
> > > >  > Voice, chat, IM, = messaging, conferencing, games, etc., are
> > > >  > plenty of reasons to = justify the SIP approach to mobility.
> > > >
> > > >    But what if = you could do all of the same things
> > > >    and not need = to modify or involve SIP and have the
> > > >    additional = gain that things like http worked as well?
> > > >
> > > = >           &n= bsp;        Mike
> > > >
> > > >  >
> > > >  > Henry
> > > >  >
> > > >  > >-----Original = Message-----
> > > >  > >From: = sip-admin@lists.bell-labs.com
> > > >  > >[ mailto:sip-admin@lists.bel= l-labs.com
><mailto:sip-admin@lists.bel= l-labs.com> ]On Behalf Of
> > > >  > >Michael = Thomas
> > > >  > >Sent: Wednesday, = September 27, 2000 8:33 PM
> > > >  > >To: Roy, Radhika = R, ALCOO
> > > >  > >Cc: Michael = Thomas; Lewis Karl-QA3387; 'Henning Schulzrinne';
> > > >  > = >sip@lists.bell-labs.com
> > > >  > >Subject: RE: = [SIP] Attempt at summarizing current SIP
> > > >  > >drafts = (SIP
> > > >  > >Mobility )
> > > >  > >
> > > >  > >
> > > >  > >
> > > >  > >I guess what I'm = having a hard time with is the
> > > >  > >starting point = that assumes that SIP based
> > > >  > >application = mobility is Good Thing. While it's
> > > >  > >clear that many = applications *could* design in
> > > >  > >mobility, what = seems clear is that there are a
> > > >  > >number of = applications which won't be able to do
> > > >  > >that for a = variety of reasons. Assuming that those
> > > >  > >applications are = important too, then we're already
> > > >  > >stuck with = needing to solve for the general
> > > >  > >problem.
> > > >  > >
> > > >  > >Starting out with = the assumption that Mobile IP
> > > >  > >addresses the = more general problem seems
> > > >  > >attractive = because a good solution with fast
> > > >  > >handoff that = addresses AAA and QoS would solve
> > > >  > >most of the = application layer problems in a
> > > >  > >general way = rather than just a SIP specific
> > > >  > >way.
> > > >  > >
> > > >  > >There also seems = to be an implicit assumption in
> > > >  > >the draft of = linkage of SIP to a AAA function.
> > > >  > >I'm going to = guess that it is along the same line
> > > >  > >of thinking of = the DQoS gate controller idea. The
> > > >  > >problem I have = with that is that it is in the end
> > > >  > >an optimization = on the normal RSVP/COPS pull
> > > >  > >model. However, = things that don't fit into that
> > > >  > >model still have = the non-optimized way of doing
> > > >  > >QoS = authorization. That's probably not the fault
> > > >  > >of this draft, = but it does seem to make the entire
> > > >  > >draft a = cart-before-horse situation.
> > > >  > >
> > > >  > = >    Mike
> > > >  > >
> > > >  > >Roy, Radhika R, = ALCOO writes:
> > > >  > > > Hi, = Mike:
> > > >  > > >
> > > >  > > > I guess = that SIP, as you rightly pointed out, is
> > > >  > >dealing with the = signaling
> > > >  > > > mechanism = in the application layer. So, SIP does
> > > >  > >not need to deal = with L3
> > > >  > > > media = path.
> > > >  > > >
> > > >  > > > SIP does = deal with addresses of the source and
> > > >  > = >destination(s).
> > > >  > > >
> > > >  > > > In mobile = environment, the point of attachment
> > > >  > >(i.e., addresses) = changes: 1.
> > > >  > > > Between the = sessions (discrete mobility) and 2.
> > > >  > >During the = session
> > > >  > > > (continuous = mobility).
> > > >  > > >
> > > >  > > > The problem = that is being addressed is: What is the
> > > >  > >impact in SIP = layer due
> > > >  > > > to these = two kinds of mobility.
> > > >  > > >
> > > >  > > > I guess = that for discrete mobility, SIP has
> > > >  > >probably = addressed most of the
> > > >  > > > problems = (others may also provide comments on this).
> > > >  > > >
> > > >  > > > For = continuous mobility, there may need (or may
> > > >  > >not??) some works = in the SIP
> > > >  > > > layer, if = any (others may also provide comments).
> > > >  > > >
> > > >  > > > However, = SIP can only address the mobility related
> > > >  > >problems in = the
> > > >  > > > application = layer. This alone may not be enough to
> > > >  > >solve all = problems
> > > >  > > > because = some L3 and L2 problems may also need to be
> > > >  > >addressed at the = same
> > > >  > > > time to = have the complete solution.
> > > >  > > >
> > > >  > > > In any = solution, SIP mobility needs to be limited
> > > >  > >only to the = application
> > > >  > > > layer (not = L3, L2, etc.).
> > > >  > > >
> > > >  > > > Best = regards,
> > > >  > > > Radhika R. = Roy
> > > >  > > > = AT&T
> > > >  > > >
> > > >  > > > = -----Original Message-----
> > > >  > > > From: = Michael Thomas [ mailto:mat@cisco.com
><mailto:mat@cisco.com> ]
> > > >  > > > Sent: = Wednesday, September 27, 2000 12:32 PM
> > > >  > > > To: Lewis = Karl-QA3387
> > > >  > > > Cc: = 'Henning Schulzrinne'; sip@lists.bell-labs.com
> > > >  > > > Subject: = RE: [SIP] Attempt at summarizing current SIP drafts
> > > >  > > >
> > > >  > > >
> > > >  > > >
> > > >  > > > While I'm = more than willing to believe that there
> > > >  > > > are = mobility issues that SIP needs to deal with,
> > > >  > > > this paper = seems to be positing SIP as the means
> > > >  > > > of = initiating data sessions altogether. To my
> > > >  > > > mind, = that's a rather bellheaded way of thinking
> > > >  > > > about how = you do what amounts to L3 admission
> > > >  > > > control. In = fact, the IETF already has an L3
> > > >  > > > admission = control mechanism: RSVP. RSVP's main
> > > >  > > > advantage = is that it follows actual network
> > > >  > > > topology. = SIP is at a distinct disadvantage since
> > > >  > > > all it = knows about is the signaling path which
> > > >  > > > in normal = circumstances has nothing to do with
> > > >  > > > the actual = data path.
> > > >  > > >
> > > >  > > > Maybe I'm = misreading this whole paper, but it sure
> > > >  > > > looks like = it to me. If my interpretation is
> > > >  > > > right, = however, I'd like to know if the intention
> > > >  > > > is to = signal the access routers providing the
> > > >  > > > L2/L3 bits = using SIP instead of, say, COPS (or
> > > >  > > > DIAMETER). = If so, I'd say that SIP truly has
> > > >  > > > arrived at = becoming the new millenium's kitchen
> > > >  > > > sink if = this is accepted.
> > > >  > > >
> > > >  > > = >    Mike
> > > >  > > >
> > > >  > > > Lewis = Karl-QA3387 writes:
> > > >  > > >  > = I have just reviewed the Mobility Related drafts
> > > >  > >and am wondering = if
> > > >  > > > = anyone
> > > >  > > >  > = is aware of the current status of
> > > >  > >draft-itsumo-sip = -mobility-req-01. In
> > > >  > > >  > = particular, several issues were identified such
> > > >  > >as Mobile IP not = being
> > > >  > > >  > = sufficient for personal mobility and location
> > > >  > >services, = completing
> > > >  > > >  > = registration in less than a few seconds,
> > > >  > >reconfiguration = in milliseconds,
> > > >  > > >  > = providing location services, support of inter
> > > >  > >domain soft-hand = and secure
> > > >  > > >  > = signaling. Have these issues been addressed or
> > > >  > >actively being = worked?
> > > >  > > >  = >
> > > >  > > >  > = Karl
> > > >  > > >  = >
> > > >  > > >  = >
> > > >  > > >  = >
> > > >  > > >  > = -----Original Message-----
> > > >  > > >  > = From: Henning Schulzrinne
> > > >  > [ mailto:schulzrinne@cs.columb= ia.edu
><mailto:schulzrinne@cs.columb= ia.edu> ]
> > > >  >  >  > = Sent: Monday, September 25, 2000 9:20 AM
> > > >  >  >  > = To: sip@lists.bell-labs.com
> > > >  >  >  > = Subject: [SIP] Attempt at summarizing current SIP drafts
> > > >  >  >  = >
> > > >  >  >  = >
> > > >  >  >  > = Given the proliferation of SIP-related drafts, I've
> > > >  > created a summary = of
> > > >  >  >  > = efforts at
> > > >  > http://www.cs.columbia.edu/~hgs/sip/drafts.html
><http://www.cs.columbia.edu/~hgs/sip/drafts.html>= ; . This is
> > > >  >  >  > = known to be incomplete, so I'd appreciate if you could
> > > >  > send me any
> > > >  >  >  > = additions or corrections. (Jonathan Rosenberg provided
> > > >  > some of the = text;
> > > >  >  >  > = any mistakes or misrepresentations are mine.)
> > > >  >  >  = >
> > > >  >  >  > = It is fairly clear that there are a large number of drafts
> > > >  > that have not
> > > >  >  >  > = changed materially for half a year or more. Maybe it's
> > > >  > time to have a = WG
> > > >  >  >  > = last call or two or ten...
> > > >  >  >  = >
> > > >  >  >  > = Henning
> > > >  >  >  > = --
> > > >  >  >  > = Henning Schulzrinne   http://www.cs.columbia.edu/~hgs
><http://www.cs.columbia.edu/~hgs>
> > > >  >  >  = >
> > > >  >  >  = >
> > > >  >  >  > = _______________________________________________
> > > >  >  >  > = SIP mailing list
> > > >  >  >  > = SIP@lists.bell-labs.com
> > > >  >  >  > = http://lists.bell-labs.com/mailman/listinfo/sip
><http://lists.bell-labs.com/mailman/listinfo/sip>= ;
> > > >  >  >  = >
> > > >  >  >  > = _______________________________________________
> > > >  >  >  > = SIP mailing list
> > > >  >  >  > = SIP@lists.bell-labs.com
> > > >  >  >  > = http://lists.bell-labs.com/mailman/listinfo/sip
><http://lists.bell-labs.com/mailman/listinfo/sip>= ;
> > > >  >  >  = >
> > > >  >  >
> > > >  >  > = _______________________________________________
> > > >  >  > SIP = mailing list
> > > >  >  > = SIP@lists.bell-labs.com
> > > >  >  > http://lists.bell-labs.com/mailman/listinfo/sip
><http://lists.bell-labs.com/mailman/listinfo/sip>
> > > >  >  >
> > > >  >  > = _______________________________________________
> > > >  >  > SIP = mailing list
> > > >  >  > = SIP@lists.bell-labs.com
> > > >  >  > http://lists.bell-labs.com/mailman/listinfo/sip
><http://lists.bell-labs.com/mailman/listinfo/sip>= ;
> > > >  >  >
> > > >  >
> > > >  > = _______________________________________________
> > > >  > SIP mailing = list
> > > >  > = SIP@lists.bell-labs.com
> > > >  > http://lists.bell-labs.com/mailman/listinfo/sip
><http://lists.bell-labs.com/mailman/listinfo/sip>= ;
> > > >  >
> > > >  >
> > > >
> > > = >_______________________________________________
> > > >SIP mailing list
> > > >SIP@lists.bell-labs.com
> > > > http://lists.bell-labs.com/mailman/listinfo/sip
><http://lists.bell-labs.com/mailman/listinfo/sip>= ;
> > > >
> > > = >_______________________________________________
> > > >SIP mailing list
> > > >SIP@lists.bell-labs.com
> > > > http://lists.bell-labs.com/mailman/listinfo/sip
><http://lists.bell-labs.com/mailman/listinfo/sip>= ;
>
>
>_______________________________________________
>SIP mailing list
>SIP@lists.bell-labs.com
>http://lists.bell-labs.com/mailman/listinfo/sip
><http://lists.bell-labs.com/mailman/listinfo/sip>= ;
>
>
>_______________________________________________
>SIP mailing list
>SIP@lists.bell-labs.com
>http://lists.bell-labs.com/mailman/listinfo/sip

------_=_NextPart_001_01C02E49.5AED10F0-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 4 18:38:33 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA03245 for ; Wed, 4 Oct 2000 18:38:33 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 730C144370; Wed, 4 Oct 2000 17:14:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ertpg14e1.nortelnetworks.com (ertpg14e1.nortelnetworks.com [47.234.0.35]) by lists.bell-labs.com (Postfix) with ESMTP id 0DDFE44362 for ; Wed, 4 Oct 2000 17:13:20 -0400 (EDT) Received: from zsc4c002.corpwest.baynetworks.com by ertpg14e1.nortelnetworks.com; Wed, 4 Oct 2000 18:12:29 -0400 Received: from zsc4c006.corpwest.baynetworks.com ([134.177.2.153]) by zsc4c002.corpwest.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id T3GD5PNW; Wed, 4 Oct 2000 15:12:24 -0700 Received: from long-pc.us.nortel.com (long-pc.corpwest.baynetworks.com [134.177.44.60]) by zsc4c006.corpwest.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id T7ZMVF0T; Wed, 4 Oct 2000 15:12:21 -0700 Message-Id: <4.2.2.20001004150941.00ca7720@zsc4c006.corpwest.baynetworks.com> X-Sender: long@zsc4c006.corpwest.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 To: Jon.Peterson@Level3.com, achoksi@vovida.com From: "Lyndon Ong" Subject: RE: [SIP] SIP ISUP MIME draft Cc: sip@lists.bell-labs.com In-Reply-To: <87A245E94948D3118DE30008C716B01301523B97@c0005v1idc1.oss.l evel3.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 04 Oct 2000 15:13:34 -0700 At 12:37 PM 10/4/2000 -0700, Jon.Peterson@Level3.com wrote: >1. Content-Encoding is not used in any of the examples in the draft; the >form in which ISUP is transmitted should be its native binary encoding. So >it shouldn't be expected, no. Whether or not it could be used (if you for >some reason wanted to encode ISUP differently) is a matter that would >require some discussion. I wouldn't rule it out. Absolutely, in fact content-encoding was in an earlier draft and was taken out on the advice of MIME experts since the assumption was binary. >2. It is optional, but it has a default value as outlined in rfc2543 which >we are not overloading - namely that the content should be considered a >mandatory content (handling=required), and that in requests and 2xx >responses 'session' is the assumed disposition for backwards-compatibility. > >However, rfc2543bis-02 also specifies that if the MIME type doesn't have a >default disposition, then the disposition should be assumed to be 'render'. >This seems to conflict with the backwards compatibility mechanism described >above, and someone should probably fix that. I'd vote for mainaining the >latter statute. > >Now, that much said, the ISUP MIME draft today doesn't specify a default >content disposition for the ISUP MIME type. As the bis asks MIME types to >have a default, I think we probably should define one, and I think it should >be 'session' for ISUP. I suppose it would be the same for QSIG... Lyndon, >have any feelings about that? That sounds reasonable to me, "render" certainly does not make much sense. This can be added pretty easily. >3. In the examples in the draft, a MIME multipart/mixed type is used; this >allows multiple MIME bodies to appear in the same message. So, yes, it is >possible, with multipart/mixed, although the format is different than the >one you suggest below. Yes, Amit, please have a look at the examples in the draft. >Jon Peterson >Aparna Vemuri >Level(3) Communications > >-----Original Message----- >From: Amit Choksi [mailto:achoksi@vovida.com] >Sent: Wednesday, October 04, 2000 12:44 PM >To: Lyndon Ong >Cc: sip >Subject: Re: [SIP] SIP ISUP MIME draft > >Hi, >I had a few questions about the draft > >1. Can a Content-Transfer-Encoding header be expected >2. Is Content-Disposition a mandatory field >3. Is it possible that we have multiple Content-Type: headers followed by >the corresponding payload > >Content-Type:application/ISUP >Content-Type:application/SDP >CRLF > .....data...... >CRLF > ........data..... >CRLF > >I appologize if I have missed the information already clarified in the >draft. >Thanks in advance > >Amit Choksi > > > > > >Lyndon Ong wrote: > > > Folks, > > > > I have not seen any comments on the list regarding the reissued SIP ISUP > > MIME draft > > > (http > ://www.ietf.org/internet-drafts/draft-ietf-sip-isup-mime-04.txt), > > although I've gotten some minor ones offline. Are there any comments or > > questions on the draft? > > > > Thanks, > > > > L. Ong > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > > http://lists.bell-labs.co > m/mailman/listinfo/sip > >_______________________________________________ >SIP mailing list >SIP@lists.bell-labs.com >http://lists.bell-labs.com >/mailman/listinfo/sip > >_______________________________________________ >SIP mailing list >SIP@lists.bell-labs.com >http://lists.bell-labs.com >/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 4 18:45:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA03352 for ; Wed, 4 Oct 2000 18:45:03 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D785D44383; Wed, 4 Oct 2000 17:45:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from pentagon.cisco.com (pentagon.cisco.com [161.44.199.141]) by lists.bell-labs.com (Postfix) with ESMTP id B196B44362 for ; Wed, 4 Oct 2000 17:44:03 -0400 (EDT) Received: from cia.cisco.com (mirapoint@cia.cisco.com [161.44.199.157]) by pentagon.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id SAA06770; Wed, 4 Oct 2000 18:43:57 -0400 (EDT) Received: from mhammer-nt.cisco.com (va-dhcp198-164.cisco.com [161.44.198.164]) by cia.cisco.com (Mirapoint) with ESMTP id ABP27068; Wed, 4 Oct 2000 18:43:54 -0400 (EDT) Message-Id: <4.3.2.7.2.20001004175639.00b23ea0@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Brian Stucker" , Rohan Mahy , "Roy, Radhika R, ALCOO" From: hammer michael Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP Mobility ) Cc: sip@lists.bell-labs.com In-Reply-To: <36FA02BD7083D411BC9E0000F8073E43D05846@crchy271.us.nortel. com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_34725893==_.ALT" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 04 Oct 2000 18:48:25 -0700 --=====================_34725893==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed All, For the record, I agree with the idea that the lower layers should handle mobility. However, one possibility exists that could take the control out of the hands of the lower layer. I'm not sure if this is the issue we are circling, but let me try to describe what I think could happen. The IP layer can address what happens to the communication end-to-end so long as it is really end-to-end. If a proxy is used to patch together two end-to-end IP streams, then any IP-dependent mechanism would be constrained by its knowledge of what the endpoint is. If only one end-to-end stream is used, then the IP layer should be able to maintain flows to that endpoint even as it moves within a network domain. If movement causes the terminal to relinquish an IP address and get a new one in a new network, registrations at the network layer can reestablish IP identities among communicating parties. Also, that same registration mechanism is how a user or proxy finds the other user to begin with. If a message is not acknowledged, then another location request is needed. However, if the real end-point is hidden behind a proxy using another IP stream, then the proxy is burdened with the responsibility to keep track of the end-points on the two streams. But this would be just two instances of the simple example. So, the problem seems to come down to whether the information on the whereabouts of a user is present or can be obtained by some mechanism on a timely basis should an acknowledgement not be received. I had the impression that this was not a problem. Is it the responsibility of the user to push that information to the proxy, or is it the proxy's responsibility to pull that information from the registrar? Either way, that should not be a problem in the time-scale of a session set-up or release. In a world where the terminal is "always on", the role of SIP may be more attuned to whether the user wants to be reached, not where or how to reach the user. But that digresses into another subject. Mike Hammer At 04:23 PM 10/04/2000 -0500, Brian Stucker wrote: >I definitely agree with that sentiment. That was the point of my argument. >Do nothing in regards to SIP, and if there's something particular to SIP >that needs to be addressed in a layer below SIP, then we should be trying >to inject requirements and influence the decisions being made there first. > >Brian > >-----Original Message----- >From: Rohan Mahy [mailto:rohan@cisco.com] >Sent: Wednesday, October 04, 2000 3:14 PM >To: Roy, Radhika R, ALCOO >Cc: Stucker, Brian [RICH2:WI12:EXCH]; sip@lists.bell-labs.com >Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP >Mobility ) > >At 10:51 AM 9/29/00 , Roy, Radhika R, ALCOO wrote: > >Hi, Brian: > > > >I guess that your mail has provided some technical inputs: 1. Inter-session > >mobility and 2. Intra-session mobility. > > > >For inter-session mobility, you think that SIP in OK. > > > >For intra-session mobility, it appears that you are feeling comfortable, as > >if, SIP is not designed to do this. > > > >Let us go to the basic: SIP is a session initiation protocol. It is the > >mandate of SIP. So, we like to see that it MUST deal with mobility as well > >*NO* !! Part of SIPs mandate is *personal* mobility, as a user moves from >device to device. Personal mobility is a good, useful thing. However, The >SIP charter does *NOT* include solving the problem of a device moving >through different layer 2 networks. This is a problem for a layer 3 >protocol to solve generically. If Mobile IP doesn't do what we need it to, >then lets extend it, fix it, or replace it. > >thanks, >-rohan > > >because people will use it in mobile environment (for both intra- and > >inter-session). > > > > >For inter-session, I guess that there may be some involvement of REGISTER > >and re-INVITE messages (because of change in location). > > > >That's all! > > > >All works are done in the lower layer and SIP is not involved (for example, > >some one in the lower layer will find that the location has been changed, > >accordingly the upper layer may take some actions, if needed). > > > >Hope this will clarify the things. > > > >Best regards, > >Radhika R. Roy > >AT&T > > > >-----Original Message----- > >From: Brian Stucker > [mailto:bstucker@nortelnetworks.com] > >Sent: Friday, September 29, 2000 1:19 PM > >To: sip@lists.bell-labs.com > >Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP > Mobility ) > > > > > > > >My intent isn't to confuse anyone. Quite the contrary. > > > >My point is that SIP, as an application, should not be concerned about the > >vagaries of the underlying media it's being carried on. All applications > >that use IP as a transport are going to have to contend with mobility in > the > >IP space on the intra-session timescale. So IP should solve the problem > >because it's a general problem for IP. > > > >SIP does enough to handle inter-session mobility (I'm at my desk, I'm at > >home), and not impede intra-session mobility. It's just simply not suited > >for handling anything else because of the nature of the protocol. Any > >intra-session mobility must be handled out-of-band as far as SIP is > >concerned, and SIP must not make any requirements that would impede this. > > > >Again, to use wireless voice calls as an example, even with dedicated > >transport links, thousands of pages of standards with CDMA/TDMA, IS-41, > SS7, > >and TCAP, a mobile switching center doesn't attempt to do what you guys are > >talking about. It doesn't update the location of a mobile once it's handed > >over to another switch in the location database until after your call has > >completed, and the mobile registers on the system it moved into. Why? > >Because the mobile could be handed back over to the first system, the > >handoff could fail, etc. So they don't even attempt to keep the exact > >location of the mobile up to date outside of the original switch until the > >mobile is stable again, when the call ends. Instead, all incoming calls go > >to the first switch, and that switch knows where to go from there to get > the > >call completed. > > > >SIP shouldn't be updating the location database every time a wireless > >terminal moves around. Some sort of mobile IP proxy function, should > instead > >be used that knows how to currently find the terminal in it's mobile-aware > >IP space. It should route based on the inbound packet's IP address only, > and > >not care what the payload data is either. > > > >That solves the problem for SIP, HTTP, FTP, POP3, RTP, you name it. Why > >write an extension to every protocol that uses IP as a transport (and have > >it solved, and debugged a million different ways) instead of just fixing > the > >problem at the IP layer (and have it solved, and debugged one way)? > > > >Brian Stucker > >Nortel Networks > > > >-----Original Message----- > >From: Roy, Radhika R, ALCOO [ mailto:rrroy@att.com > ] > >Sent: Friday, September 29, 2000 11:39 AM > >To: hammer michael; Michael Thomas; Henry Sinnreich > >Cc: Lewis Karl-QA3387; 'Henning Schulzrinne'; sip@lists.bell-labs.com > >Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP > >Mobility ) > > > > > >Hi, Everyone: > > > >The need for addressing mobility is clear and SIP is only one part of the > >whole equation. > > > >Let us not confuse people in the name of Pandora's box or otherwise. > > > >We have to meet the needs solving problems (not to show our back). > > > >For the SIP WG, it is the SIP session layer that needs to be addressed, if > >it turns out that is a need to do some works. > > > >Best regards, > >Radhika R. Roy > >AT&T > > > >-----Original Message----- > >From: hammer michael [ > mailto:mhammer@cisco.com > ] > > > >Sent: Friday, September 29, 2000 1:57 PM > >To: Roy, Radhika R, ALCOO; Michael Thomas; Henry Sinnreich > >Cc: Lewis Karl-QA3387; 'Henning Schulzrinne'; sip@lists.bell-labs.com > >Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP > >Mobility ) > > > > > >I think Brian aptly pointed out the Pandora's box you open with "mobility." > >That should be sufficient motivation to avoid that type of mobility in SIP. > > > >We are talking about different timescales, e.g.: per packet, per call, and > >per registration. > > > >I thought your term "discrete" captured the idea that the type of > >"mobility" you refer to is of the: call me at the office, then later, call > >me at home, I'm here now "mobility." Because mobility conjures up so many > >more issues, I like the word "presence" better. Presence management may be > >more descriptive that mobility management. > > > >Mike > > > > > >At 04:11 PM 09/28/2000 -0400, Roy, Radhika R, ALCOO wrote: > > >Hi, Mike: > > > > > >Yes, we will have problems if we do not define the terms accurately. > > > > > >Let us assume that we are using SIP (RFC 2543) and its session layer > as our > > > > >reference. Location, registration, and session are defined in SIP. > > > > > >Paging (and probably "path") has not been defined in SIP. I will not > argue > > >to take this abstraction in the SIP layer for now. > > > > > >Point of attachment has been used as a generic term to indicate > "address of > > > > >the attachment." If we translate this abstraction in the SIP layer, it > will > > > > >mean the addresses that are being used in the SIP layer (e.g., E.164, IP > > >address, etc.). > > > > > >Now let us examine your points: Presence of a person or terminal, etc. > > > > > >In the SIP layer, I guess, that the presence of a person on a terminal > >needs > > >to be abstracted in terms of an "address." If that address is also > related > > >to the point of attachment, then it will also be related to mobility. > > > > > >(A person behind the terminal may have another ID to deal with personal > > >mobility. Let us not address that personal mobility for now.) > > > > > >In this way, we can extend our analysis for each layer. > > > > > >Does this answer your question? > > > > > >Best regards, > > >Radhika R. Roy > > >AT&T > > > > > >-----Original Message----- > > >From: hammer michael [ > mailto:mhammer@cisco.com > >] > > >Sent: Thursday, September 28, 2000 6:29 PM > > >To: Roy, Radhika R, ALCOO; Michael Thomas; Henry Sinnreich > > >Cc: Lewis Karl-QA3387; 'Henning Schulzrinne'; sip@lists.bell-labs.com > > >Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP > > >Mobility ) > > > > > > > > >Roy, > > > > > >I need to be very careful what word I choose. Session connection rather > > >than path might have been more appropriate. I believe confusion can > occur > > >if the type of location, registration, location, paging, etc. is not > > >accurately defined. I think that the intent of such services revolves > > >about maintaining relationships between certain elements, such as > between: > > > > > >user/application and terminal, > > >terminal and network end-point, > > >network end-point and link end-point, etc. > > > > > >The act of "registering" may mean different things at different layers > and > > >use different mechanisms to accomplish them. The question for me is > > >whether these are handled independently or does one mechanism attempt to > > >manage multiple associations or would one type of registration trigger > > >another type at a different layer? > > > > > >Would SIP then manage the "presence" of a person on a terminal, where > > >something else manages the "presence" of a terminal on the network? > > > > > >Mike Hammer > > > > > > > > >At 12:28 PM 09/28/2000 -0400, Roy, Radhika R, ALCOO wrote: > > > >Hi, Mike: > > > > > > > >You have made excellent points. In fact, you are in the heart of this > > > >problem: How the communications path(s) needs to be established as the > > >point > > > >of attachment is changed during the contiguous mobility. > > > > > > > >I personally believe that SIP does not need to be involved to set up > the > > > >communications path(s) per se. > > > > > > > >However, SIP needs to be used to set up the session: re-INVITE (to the > >new > > > >address) may need to be used. > > > > > > > >In the process, location updates, paging, etc. are also involved. If > the > > > >location update does not have any impact in the SIP layer, I do not > think > > > > > >that SIP should be aware of any change in the lower layer. For example, > > > >mobile IP has the power of providing location transparency of the IP > >layer > > > >(although it has some problems to meet the performance requirements for > >the > > > >real-time communications like voice). > > > > > > > >In addition to IP addresses, there are also transport addresses (e.g., > >UDP, > > > >TCP) for media. One also needs to be careful how to deal with the TCP > > > >connection. IP addresses change, but the TCP connections still remains > >the > > > >same. An update mechanism needs to be defined. In turn, does it mean > that > > > > > >this updated information may also be propagated to the SIP layer (other > > > >members may also provide comments on this) because SIP does have the > > > >abstraction of the transport address? > > > > > > > >I have not yet talked about the link layer. > > > > > > > >I am not trying to solve the mobility problem here. > > > > > > > >All I am trying to show: If we try to analyze the situation doing an > > > >end-to-end analysis, we can easily see what needs to be done in each > >layer. > > > >Finally, we can answer the question: Whether or not any new work is > >needed > > > >in the SIP layer to address both discrete and continuos mobility. > > > > > > > >But you are right that we MUST keep the involvement of the SIP layer > to a > > > > > >minimal level (if possible, we should avoid it) to address the mobility > > > >problem. > > > > > > > >Best regards, > > > >Radhika R. Roy > > > >AT&T > > > > > > > >-----Original Message----- > > > >From: hammer michael [ > mailto:mhammer@cisco.com > > ] > > > >Sent: Thursday, September 28, 2000 2:41 PM > > > >To: Roy, Radhika R, ALCOO; Michael Thomas; Henry Sinnreich > > > >Cc: Lewis Karl-QA3387; 'Henning Schulzrinne'; sip@lists.bell-labs.com > > > >Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP > > > >Mobility ) > > > > > > > > > > > >Roy, > > > > > > > >Your use of the terms "discrete" and "continuous" strike to the > heart of > > > >the issue. In traditional mobile networks, there is an attempt to move > >the > > > >stream of media with the terminal as it crosses cell boundaries > > > >(continuous). There are many papers related to voice and mobile-IP > that > > > >address how to move the communications path. > > > > > > > >The discrete case is more an issue of identification of the presence > and > > > >availability of recipients and the establishment of communications to > > > >them. Because names and addresses denoting physical location are often > > > >blurred, in essence, personal mobility involves the creation and > deletion > > > > > >of recipients rather than their movement. > > > > > > > >As I understand it, SIP does not move existing communications so > much as > >it > > > >destroys existing communications paths and replaces them with new ones. > >In > > > >that respect, some of the traditional mobility issues such as handover > >are > > > >avoided, but others, e.g. location updates and paging are still needed. > > > > > > > >While the telcos reverted to addressing hardware-oriented terminal > >mobility > > > >in PCS, the softer personal mobility is still open to definition. The > >same > > > >issues have appeared in the net world and each will need to be > solved in > > > >their respective layers. > > > > > > > >Mike > > > > > > > > > > > >At 11:01 AM 09/28/2000 -0400, Roy, Radhika R, ALCOO wrote: > > > > >Hi, Mike: > > > > > > > > > >In fact, this is the precisely the test why SIP should be involved or > >to > > >be > > > > >enhanced to support mobility (discrete + continuos) in the case of > >Voice, > > > > >chat, IM, messaging, conferencing, games, and others. > > > > > > > > > >If it is found that SIP does not need to be involved, I do not think > >that > > > > >anyone will force it to do this. > > > > > > > > > >By the way, do you not see that how SIP (RFC 2543) has taken care of > >many > > > > >aspects of users' discrete mobility? Has it not been be an excellent > >way > > >of > > > > >involving SIP to solve a kind of mobility in the first place (what > >other > > > > >applications like H.323 is yet to support)? > > > > > > > > > >Along the same line, if people come up with the ideas that it is > better > > > > >to > > > > >enhance SIP functionality to support other aspects of mobility (if > > > > >alternative solutions are not there or not acceptable), I do not > think > > >that > > > > >we should have any objections. > > > > > > > > > >Let us keep our mind open and judge each proposal with its own > merits. > > > > > > > > > >Best regards, > > > > >Radhika R. Roy > > > > >AT&T > > > > > > > > > >-----Original Message----- > > > > >From: Michael Thomas [ mailto:mat@cisco.com > ] > > > > >Sent: Wednesday, September 27, 2000 7:01 PM > > > > >To: Henry Sinnreich > > > > >Cc: Michael Thomas; Roy, Radhika R, ALCOO; Lewis Karl-QA3387; > 'Henning > > > > >Schulzrinne'; sip@lists.bell-labs.com > > > > >Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP > > > > >Mobility ) > > > > > > > > > > > > > > >Henry Sinnreich writes: > > > > > > >what seems clear is that there are a > > > > > > >number of applications which won't be able to do > > > > > > >that for a variety of reasons. > > > > > > > > > > > > Voice, chat, IM, messaging, conferencing, games, etc., are > > > > > > plenty of reasons to justify the SIP approach to mobility. > > > > > > > > > > But what if you could do all of the same things > > > > > and not need to modify or involve SIP and have the > > > > > additional gain that things like http worked as well? > > > > > > > > > > Mike > > > > > > > > > > > > > > > > > Henry > > > > > > > > > > > > >-----Original Message----- > > > > > > >From: sip-admin@lists.bell-labs.com > > > > > > >[ > mailto:sip-admin@lists.bell-labs.com > > ]On Behalf Of > > > > > > >Michael Thomas > > > > > > >Sent: Wednesday, September 27, 2000 8:33 PM > > > > > > >To: Roy, Radhika R, ALCOO > > > > > > >Cc: Michael Thomas; Lewis Karl-QA3387; 'Henning Schulzrinne'; > > > > > > >sip@lists.bell-labs.com > > > > > > >Subject: RE: [SIP] Attempt at summarizing current SIP > > > > > > >drafts (SIP > > > > > > >Mobility ) > > > > > > > > > > > > > > > > > > > > > > > > > > > >I guess what I'm having a hard time with is the > > > > > > >starting point that assumes that SIP based > > > > > > >application mobility is Good Thing. While it's > > > > > > >clear that many applications *could* design in > > > > > > >mobility, what seems clear is that there are a > > > > > > >number of applications which won't be able to do > > > > > > >that for a variety of reasons. Assuming that those > > > > > > >applications are important too, then we're already > > > > > > >stuck with needing to solve for the general > > > > > > >problem. > > > > > > > > > > > > > >Starting out with the assumption that Mobile IP > > > > > > >addresses the more general problem seems > > > > > > >attractive because a good solution with fast > > > > > > >handoff that addresses AAA and QoS would solve > > > > > > >most of the application layer problems in a > > > > > > >general way rather than just a SIP specific > > > > > > >way. > > > > > > > > > > > > > >There also seems to be an implicit assumption in > > > > > > >the draft of linkage of SIP to a AAA function. > > > > > > >I'm going to guess that it is along the same line > > > > > > >of thinking of the DQoS gate controller idea. The > > > > > > >problem I have with that is that it is in the end > > > > > > >an optimization on the normal RSVP/COPS pull > > > > > > >model. However, things that don't fit into that > > > > > > >model still have the non-optimized way of doing > > > > > > >QoS authorization. That's probably not the fault > > > > > > >of this draft, but it does seem to make the entire > > > > > > >draft a cart-before-horse situation. > > > > > > > > > > > > > > Mike > > > > > > > > > > > > > >Roy, Radhika R, ALCOO writes: > > > > > > > > Hi, Mike: > > > > > > > > > > > > > > > > I guess that SIP, as you rightly pointed out, is > > > > > > >dealing with the signaling > > > > > > > > mechanism in the application layer. So, SIP does > > > > > > >not need to deal with L3 > > > > > > > > media path. > > > > > > > > > > > > > > > > SIP does deal with addresses of the source and > > > > > > >destination(s). > > > > > > > > > > > > > > > > In mobile environment, the point of attachment > > > > > > >(i.e., addresses) changes: 1. > > > > > > > > Between the sessions (discrete mobility) and 2. > > > > > > >During the session > > > > > > > > (continuous mobility). > > > > > > > > > > > > > > > > The problem that is being addressed is: What is the > > > > > > >impact in SIP layer due > > > > > > > > to these two kinds of mobility. > > > > > > > > > > > > > > > > I guess that for discrete mobility, SIP has > > > > > > >probably addressed most of the > > > > > > > > problems (others may also provide comments on this). > > > > > > > > > > > > > > > > For continuous mobility, there may need (or may > > > > > > >not??) some works in the SIP > > > > > > > > layer, if any (others may also provide comments). > > > > > > > > > > > > > > > > However, SIP can only address the mobility related > > > > > > >problems in the > > > > > > > > application layer. This alone may not be enough to > > > > > > >solve all problems > > > > > > > > because some L3 and L2 problems may also need to be > > > > > > >addressed at the same > > > > > > > > time to have the complete solution. > > > > > > > > > > > > > > > > In any solution, SIP mobility needs to be limited > > > > > > >only to the application > > > > > > > > layer (not L3, L2, etc.). > > > > > > > > > > > > > > > > Best regards, > > > > > > > > Radhika R. Roy > > > > > > > > AT&T > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Michael Thomas [ > mailto:mat@cisco.com > > ] > > > > > > > > Sent: Wednesday, September 27, 2000 12:32 PM > > > > > > > > To: Lewis Karl-QA3387 > > > > > > > > Cc: 'Henning Schulzrinne'; sip@lists.bell-labs.com > > > > > > > > Subject: RE: [SIP] Attempt at summarizing current SIP drafts > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > While I'm more than willing to believe that there > > > > > > > > are mobility issues that SIP needs to deal with, > > > > > > > > this paper seems to be positing SIP as the means > > > > > > > > of initiating data sessions altogether. To my > > > > > > > > mind, that's a rather bellheaded way of thinking > > > > > > > > about how you do what amounts to L3 admission > > > > > > > > control. In fact, the IETF already has an L3 > > > > > > > > admission control mechanism: RSVP. RSVP's main > > > > > > > > advantage is that it follows actual network > > > > > > > > topology. SIP is at a distinct disadvantage since > > > > > > > > all it knows about is the signaling path which > > > > > > > > in normal circumstances has nothing to do with > > > > > > > > the actual data path. > > > > > > > > > > > > > > > > Maybe I'm misreading this whole paper, but it sure > > > > > > > > looks like it to me. If my interpretation is > > > > > > > > right, however, I'd like to know if the intention > > > > > > > > is to signal the access routers providing the > > > > > > > > L2/L3 bits using SIP instead of, say, COPS (or > > > > > > > > DIAMETER). If so, I'd say that SIP truly has > > > > > > > > arrived at becoming the new millenium's kitchen > > > > > > > > sink if this is accepted. > > > > > > > > > > > > > > > > Mike > > > > > > > > > > > > > > > > Lewis Karl-QA3387 writes: > > > > > > > > > I have just reviewed the Mobility Related drafts > > > > > > >and am wondering if > > > > > > > > anyone > > > > > > > > > is aware of the current status of > > > > > > >draft-itsumo-sip -mobility-req-01. In > > > > > > > > > particular, several issues were identified such > > > > > > >as Mobile IP not being > > > > > > > > > sufficient for personal mobility and location > > > > > > >services, completing > > > > > > > > > registration in less than a few seconds, > > > > > > >reconfiguration in milliseconds, > > > > > > > > > providing location services, support of inter > > > > > > >domain soft-hand and secure > > > > > > > > > signaling. Have these issues been addressed or > > > > > > >actively being worked? > > > > > > > > > > > > > > > > > > Karl > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Henning Schulzrinne > > > > > > [ > mailto:schulzrinne@cs.columbia.edu > > ] > > > > > > > > Sent: Monday, September 25, 2000 9:20 AM > > > > > > > > To: sip@lists.bell-labs.com > > > > > > > > Subject: [SIP] Attempt at summarizing current SIP drafts > > > > > > > > > > > > > > > > > > > > > > > > Given the proliferation of SIP-related drafts, I've > > > > > > created a summary of > > > > > > > > efforts at > > > > > > > http://www.cs.columbia.edu/~hgs/sip/drafts.html > > > . This is > > > > > > > > known to be incomplete, so I'd appreciate if you could > > > > > > send me any > > > > > > > > additions or corrections. (Jonathan Rosenberg provided > > > > > > some of the text; > > > > > > > > any mistakes or misrepresentations are mine.) > > > > > > > > > > > > > > > > It is fairly clear that there are a large number of drafts > > > > > > that have not > > > > > > > > changed materially for half a year or more. Maybe it's > > > > > > time to have a WG > > > > > > > > last call or two or ten... > > > > > > > > > > > > > > > > Henning > > > > > > > > -- > > > > > > > > Henning > Schulzrinne http://www.cs.columbia.edu/~hgs > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > SIP mailing list > > > > > > > > SIP@lists.bell-labs.com > > > > > > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > SIP mailing list > > > > > > > > SIP@lists.bell-labs.com > > > > > > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > SIP mailing list > > > > > > > SIP@lists.bell-labs.com > > > > > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > SIP mailing list > > > > > > > SIP@lists.bell-labs.com > > > > > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > SIP mailing list > > > > > > SIP@lists.bell-labs.com > > > > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > > > > > > > > > > > > > > > > > >_______________________________________________ > > > > >SIP mailing list > > > > >SIP@lists.bell-labs.com > > > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > > > > > >_______________________________________________ > > > > >SIP mailing list > > > > >SIP@lists.bell-labs.com > > > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > >_______________________________________________ > >SIP mailing list > >SIP@lists.bell-labs.com > >http://lists.bell-labs.c > om/mailman/listinfo/sip > > > > > > > >_______________________________________________ > >SIP mailing list > >SIP@lists.bell-labs.com > >http://lists.bell-labs.c > om/mailman/listinfo/sip --=====================_34725893==_.ALT Content-Type: text/html; charset="us-ascii" All,

For the record, I agree with the idea that the lower layers should handle mobility.  However, one possibility exists that could take the control out of the hands of the lower layer.  I'm not sure if this is the issue we are circling, but let me try to describe what I think could happen.

The IP layer can address what happens to the communication end-to-end so long as it is really end-to-end.  If a proxy is used to patch together two end-to-end IP streams, then any IP-dependent mechanism would be constrained by its knowledge of what the endpoint is.

If only one end-to-end stream is used, then the IP layer should be able to maintain flows to that endpoint even as it moves within a network domain.  If movement causes the terminal to relinquish an IP address and get a new one in a new network, registrations at the network layer can reestablish IP identities among communicating parties.  Also, that same registration mechanism is how a user or proxy finds the other user to begin with.  If a message is not acknowledged, then another location request is needed.

However, if the real end-point is hidden behind a proxy using another IP stream, then the proxy is burdened with the responsibility to keep track of the end-points on the two streams.  But this would be just two instances of the simple example.

So, the problem seems to come down to whether the information on the whereabouts of a user is present or can be obtained by some mechanism on a timely basis should an acknowledgement not be received.  I had the impression that this was not a problem.

Is it the responsibility of the user to push that information to the proxy, or is it the proxy's responsibility to pull that information from the registrar?  Either way, that should not be a problem in the time-scale of a session set-up or release.

In a world where the terminal is "always on", the role of SIP may be more attuned to whether the user wants to be reached, not where or how to reach the user.  But that digresses into another subject.

Mike Hammer
 


At 04:23 PM 10/04/2000 -0500, Brian Stucker wrote:

I definitely agree with that sentiment. That was the point of my argument. Do nothing in regards to SIP, and if there's something particular to SIP that needs to be addressed in a layer below SIP, then we should be trying to inject requirements and influence the decisions being made there first.

Brian

-----Original Message-----
From: Rohan Mahy [mailto:rohan@cisco.com]
Sent: Wednesday, October 04, 2000 3:14 PM
To: Roy, Radhika R, ALCOO
Cc: Stucker, Brian [RICH2:WI12:EXCH]; sip@lists.bell-labs.com
Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP
Mobility )

At 10:51 AM 9/29/00 , Roy, Radhika R, ALCOO wrote:
>Hi, Brian:
>
>I guess that your mail has provided some technical inputs: 1. Inter-session
>mobility and 2. Intra-session mobility.
>
>For inter-session mobility, you think that SIP in OK.
>
>For intra-session mobility, it appears that you are feeling comfortable, as
>if, SIP is not designed to do this.
>
>Let us go to the basic: SIP is a session initiation protocol. It is the
>mandate of SIP. So, we like to see that it MUST deal with mobility as well

*NO* !!  Part of SIPs mandate is *personal* mobility, as a user moves from
device to device.  Personal mobility is a good, useful thing.  However, The
SIP charter does *NOT* include solving the problem of a device moving
through different layer 2 networks.  This is a problem for a layer 3
protocol to solve generically.  If Mobile IP doesn't do what we need it to,
then lets extend it, fix it, or replace it.

thanks,
-rohan

>because people will use it in mobile environment (for both intra- and
>inter-session).

>
>For inter-session, I guess that there may be some involvement of REGISTER
>and re-INVITE messages (because of change in location).
>
>That's all!
>
>All works are done in the lower layer and SIP is not involved (for example,
>some one in the lower layer will find that the location has been changed,
>accordingly the upper layer may take some actions, if needed).
>
>Hope this will clarify the things.
>
>Best regards,
>Radhika R. Roy
>AT&T
>
>-----Original Message-----
>From: Brian Stucker [mailto:bstucker@nortelnetworks.com]
>Sent: Friday, September 29, 2000 1:19 PM
>To: sip@lists.bell-labs.com
>Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP Mobility )
>
>
>
>My intent isn't to confuse anyone. Quite the contrary.
>
>My point is that SIP, as an application, should not be concerned about the
>vagaries of the underlying media it's being carried on. All applications
>that use IP as a transport are going to have to contend with mobility in the
>IP space on the intra-session timescale. So IP should solve the problem
>because it's a general problem for IP.
>
>SIP does enough to handle inter-session mobility (I'm at my desk, I'm at
>home), and not impede intra-session mobility. It's just simply not suited
>for handling anything else because of the nature of the protocol. Any
>intra-session mobility must be handled out-of-band as far as SIP is
>concerned, and SIP must not make any requirements that would impede this.
>
>Again, to use wireless voice calls as an example, even with dedicated
>transport links, thousands of pages of standards with CDMA/TDMA, IS-41, SS7,
>and TCAP, a mobile switching center doesn't attempt to do what you guys are
>talking about. It doesn't update the location of a mobile once it's handed
>over to another switch in the location database until after your call has
>completed, and the mobile registers on the system it moved into. Why?
>Because the mobile could be handed back over to the first system, the
>handoff could fail, etc. So they don't even attempt to keep the exact
>location of the mobile up to date outside of the original switch until the
>mobile is stable again, when the call ends. Instead, all incoming calls go
>to the first switch, and that switch knows where to go from there to get the
>call completed.
>
>SIP shouldn't be updating the location database every time a wireless
>terminal moves around. Some sort of mobile IP proxy function, should instead
>be used that knows how to currently find the terminal in it's mobile-aware
>IP space. It should route based on the inbound packet's IP address only, and
>not care what the payload data is either.
>
>That solves the problem for SIP, HTTP, FTP, POP3, RTP, you name it. Why
>write an extension to every protocol that uses IP as a transport (and have
>it solved, and debugged a million different ways) instead of just fixing the
>problem at the IP layer (and have it solved, and debugged one way)?
>
>Brian Stucker
>Nortel Networks
>
>-----Original Message-----
>From: Roy, Radhika R, ALCOO [ mailto:rrroy@att.com <mailto:rrroy@att.com> ]
>Sent: Friday, September 29, 2000 11:39 AM
>To: hammer michael; Michael Thomas; Henry Sinnreich
>Cc: Lewis Karl-QA3387; 'Henning Schulzrinne'; sip@lists.bell-labs.com
>Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP
>Mobility )
>
>
>Hi, Everyone:
>
>The need for addressing mobility is clear and SIP is only one part of the
>whole equation.
>
>Let us not confuse people in the name of Pandora's box or otherwise.
>
>We have to meet the needs solving problems (not to show our back).
>
>For the SIP WG, it is the SIP session layer that needs to be addressed, if
>it turns out that is a need to do some works.
>
>Best regards,
>Radhika R. Roy
>AT&T
>
>-----Original Message-----
>From: hammer michael [ mailto:mhammer@cisco.com <mailto:mhammer@cisco.com> ]
>
>Sent: Friday, September 29, 2000 1:57 PM
>To: Roy, Radhika R, ALCOO; Michael Thomas; Henry Sinnreich
>Cc: Lewis Karl-QA3387; 'Henning Schulzrinne'; sip@lists.bell-labs.com
>Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP
>Mobility )
>
>
>I think Brian aptly pointed out the Pandora's box you open with "mobility."
>That should be sufficient motivation to avoid that type of mobility in SIP.
>
>We are talking about different timescales, e.g.:  per packet, per call, and
>per registration.
>
>I thought your term "discrete" captured the idea that the type of
>"mobility" you refer to is of the:  call me at the office, then later, call
>me at home, I'm here now "mobility."  Because mobility conjures up so many
>more issues, I like the word "presence" better.  Presence management may be
>more descriptive that mobility management.
>
>Mike
>
>
>At 04:11 PM 09/28/2000 -0400, Roy, Radhika R, ALCOO wrote:
> >Hi, Mike:
> >
> >Yes, we will have problems if we do not define the terms accurately.
> >
> >Let us assume that we are using SIP (RFC 2543) and its session layer as our
>
> >reference. Location, registration, and session are defined in SIP.
> >
> >Paging (and probably "path") has not been defined in SIP. I will not argue
> >to take this abstraction in the SIP layer for now.
> >
> >Point of attachment has been used as a generic term to indicate "address of
>
> >the attachment." If we translate this abstraction in the SIP layer, it will
>
> >mean the addresses that are being used in the SIP layer (e.g., E.164, IP
> >address, etc.).
> >
> >Now let us examine your points: Presence of a person or terminal, etc.
> >
> >In the SIP layer, I guess, that the presence of a person on a terminal
>needs
> >to be abstracted in terms of an "address." If that address is also related
> >to the point of attachment, then it will also be related to mobility.
> >
> >(A person behind the terminal may have another ID to deal with personal
> >mobility. Let us not address that personal mobility for now.)
> >
> >In this way, we can extend our analysis for each layer.
> >
> >Does this answer your question?
> >
> >Best regards,
> >Radhika R. Roy
> >AT&T
> >
> >-----Original Message-----
> >From: hammer michael [ mailto:mhammer@cisco.com <mailto:mhammer@cisco.com>
>]
> >Sent: Thursday, September 28, 2000 6:29 PM
> >To: Roy, Radhika R, ALCOO; Michael Thomas; Henry Sinnreich
> >Cc: Lewis Karl-QA3387; 'Henning Schulzrinne'; sip@lists.bell-labs.com
> >Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP
> >Mobility )
> >
> >
> >Roy,
> >
> >I need to be very careful what word I choose.  Session connection rather
> >than path might have been more appropriate.  I believe confusion can occur
> >if the type of location, registration, location, paging, etc. is not
> >accurately defined.  I think that the intent of such services revolves
> >about maintaining relationships between certain elements, such as between:
> >
> >user/application and terminal,
> >terminal and network end-point,
> >network end-point and link end-point, etc.
> >
> >The act of "registering" may mean different things at different layers and
> >use different mechanisms to accomplish them.  The question for me is
> >whether these are handled independently or does one mechanism attempt to
> >manage multiple associations or would one type of registration trigger
> >another type at a different layer?
> >
> >Would SIP then manage the "presence" of a person on a terminal, where
> >something else manages the "presence" of a terminal on the network?
> >
> >Mike Hammer
> >
> >
> >At 12:28 PM 09/28/2000 -0400, Roy, Radhika R, ALCOO wrote:
> > >Hi, Mike:
> > >
> > >You have made excellent points. In fact, you are in the heart of this
> > >problem: How the communications path(s) needs to be established as the
> >point
> > >of attachment is changed during the contiguous mobility.
> > >
> > >I personally believe that SIP does not need to be involved to set up the
> > >communications path(s) per se.
> > >
> > >However, SIP needs to be used to set up the session: re-INVITE (to the
>new
> > >address) may need to be used.
> > >
> > >In the process, location updates, paging, etc. are also involved. If the
> > >location update does not have any impact in the SIP layer, I do not think
>
> > >that SIP should be aware of any change in the lower layer. For example,
> > >mobile IP has the power of providing location transparency of the IP
>layer
> > >(although it has some problems to meet the performance requirements for
>the
> > >real-time communications like voice).
> > >
> > >In addition to IP addresses, there are also transport addresses (e.g.,
>UDP,
> > >TCP) for media. One also needs to be careful how to deal with the TCP
> > >connection. IP addresses change, but the TCP connections still remains
>the
> > >same. An update mechanism needs to be defined. In turn, does it mean that
>
> > >this updated information may also be propagated to the SIP layer (other
> > >members may also provide comments on this) because SIP does have the
> > >abstraction of the transport address?
> > >
> > >I have not yet talked about the link layer.
> > >
> > >I am not trying to solve the mobility problem here.
> > >
> > >All I am trying to show: If we try to analyze the situation doing an
> > >end-to-end analysis, we can easily see what needs to be done in each
>layer.
> > >Finally, we can answer the question: Whether or not any new work is
>needed
> > >in the SIP layer to address both discrete and continuos mobility.
> > >
> > >But you are right that we MUST keep the involvement of the SIP layer to a
>
> > >minimal level (if possible, we should avoid it) to address the mobility
> > >problem.
> > >
> > >Best regards,
> > >Radhika R. Roy
> > >AT&T
> > >
> > >-----Original Message-----
> > >From: hammer michael [ mailto:mhammer@cisco.com
><mailto:mhammer@cisco.com> ]
> > >Sent: Thursday, September 28, 2000 2:41 PM
> > >To: Roy, Radhika R, ALCOO; Michael Thomas; Henry Sinnreich
> > >Cc: Lewis Karl-QA3387; 'Henning Schulzrinne'; sip@lists.bell-labs.com
> > >Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP
> > >Mobility )
> > >
> > >
> > >Roy,
> > >
> > >Your use of the terms "discrete" and "continuous" strike to the heart of
> > >the issue.  In traditional mobile networks, there is an attempt to move
>the
> > >stream of media with the terminal as it crosses cell boundaries
> > >(continuous).  There are many papers related to voice and mobile-IP that
> > >address how to move the communications path.
> > >
> > >The discrete case is more an issue of identification of the presence and
> > >availability of recipients and the establishment of communications to
> > >them.  Because names and addresses denoting physical location are often
> > >blurred, in essence, personal mobility involves the creation and deletion
>
> > >of recipients rather than their movement.
> > >
> > >As I understand it, SIP does not move existing communications so much as
>it
> > >destroys existing communications paths and replaces them with new ones.
>In
> > >that respect, some of the traditional mobility issues such as handover
>are
> > >avoided, but others, e.g. location updates and paging are still needed.
> > >
> > >While the telcos reverted to addressing hardware-oriented terminal
>mobility
> > >in PCS, the softer personal mobility is still open to definition.  The
>same
> > >issues have appeared in the net world and each will need to be solved in
> > >their respective layers.
> > >
> > >Mike
> > >
> > >
> > >At 11:01 AM 09/28/2000 -0400, Roy, Radhika R, ALCOO wrote:
> > > >Hi, Mike:
> > > >
> > > >In fact, this is the precisely the test why SIP should be involved or
>to
> >be
> > > >enhanced to support mobility (discrete + continuos) in the case of
>Voice,
> > > >chat, IM, messaging, conferencing, games, and others.
> > > >
> > > >If it is found that SIP does not need to be involved, I do not think
>that
> > > >anyone will force it to do this.
> > > >
> > > >By the way, do you not see that how SIP (RFC 2543) has taken care of
>many
> > > >aspects of users' discrete mobility? Has it not been be an excellent
>way
> >of
> > > >involving SIP to solve a kind of mobility in the first place (what
>other
> > > >applications like H.323 is yet to support)?
> > > >
> > > >Along the same line, if people come up with the ideas that it is better
>
> >to
> > > >enhance SIP functionality to support other aspects of mobility (if
> > > >alternative solutions are not there or not acceptable), I do not think
> >that
> > > >we should have any objections.
> > > >
> > > >Let us keep our mind open and judge each proposal with its own merits.
> > > >
> > > >Best regards,
> > > >Radhika R. Roy
> > > >AT&T
> > > >
> > > >-----Original Message-----
> > > >From: Michael Thomas [ mailto:mat@cisco.com <mailto:mat@cisco.com> ]
> > > >Sent: Wednesday, September 27, 2000 7:01 PM
> > > >To: Henry Sinnreich
> > > >Cc: Michael Thomas; Roy, Radhika R, ALCOO; Lewis Karl-QA3387; 'Henning
> > > >Schulzrinne'; sip@lists.bell-labs.com
> > > >Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP
> > > >Mobility )
> > > >
> > > >
> > > >Henry Sinnreich writes:
> > > >  > >what seems clear is that there are a
> > > >  > >number of applications which won't be able to do
> > > >  > >that for a variety of reasons.
> > > >  >
> > > >  > Voice, chat, IM, messaging, conferencing, games, etc., are
> > > >  > plenty of reasons to justify the SIP approach to mobility.
> > > >
> > > >    But what if you could do all of the same things
> > > >    and not need to modify or involve SIP and have the
> > > >    additional gain that things like http worked as well?
> > > >
> > > >                    Mike
> > > >
> > > >  >
> > > >  > Henry
> > > >  >
> > > >  > >-----Original Message-----
> > > >  > >From: sip-admin@lists.bell-labs.com
> > > >  > >[ mailto:sip-admin@lists.bell-labs.com
><mailto:sip-admin@lists.bell-labs.com> ]On Behalf Of
> > > >  > >Michael Thomas
> > > >  > >Sent: Wednesday, September 27, 2000 8:33 PM
> > > >  > >To: Roy, Radhika R, ALCOO
> > > >  > >Cc: Michael Thomas; Lewis Karl-QA3387; 'Henning Schulzrinne';
> > > >  > >sip@lists.bell-labs.com
> > > >  > >Subject: RE: [SIP] Attempt at summarizing current SIP
> > > >  > >drafts (SIP
> > > >  > >Mobility )
> > > >  > >
> > > >  > >
> > > >  > >
> > > >  > >I guess what I'm having a hard time with is the
> > > >  > >starting point that assumes that SIP based
> > > >  > >application mobility is Good Thing. While it's
> > > >  > >clear that many applications *could* design in
> > > >  > >mobility, what seems clear is that there are a
> > > >  > >number of applications which won't be able to do
> > > >  > >that for a variety of reasons. Assuming that those
> > > >  > >applications are important too, then we're already
> > > >  > >stuck with needing to solve for the general
> > > >  > >problem.
> > > >  > >
> > > >  > >Starting out with the assumption that Mobile IP
> > > >  > >addresses the more general problem seems
> > > >  > >attractive because a good solution with fast
> > > >  > >handoff that addresses AAA and QoS would solve
> > > >  > >most of the application layer problems in a
> > > >  > >general way rather than just a SIP specific
> > > >  > >way.
> > > >  > >
> > > >  > >There also seems to be an implicit assumption in
> > > >  > >the draft of linkage of SIP to a AAA function.
> > > >  > >I'm going to guess that it is along the same line
> > > >  > >of thinking of the DQoS gate controller idea. The
> > > >  > >problem I have with that is that it is in the end
> > > >  > >an optimization on the normal RSVP/COPS pull
> > > >  > >model. However, things that don't fit into that
> > > >  > >model still have the non-optimized way of doing
> > > >  > >QoS authorization. That's probably not the fault
> > > >  > >of this draft, but it does seem to make the entire
> > > >  > >draft a cart-before-horse situation.
> > > >  > >
> > > >  > >    Mike
> > > >  > >
> > > >  > >Roy, Radhika R, ALCOO writes:
> > > >  > > > Hi, Mike:
> > > >  > > >
> > > >  > > > I guess that SIP, as you rightly pointed out, is
> > > >  > >dealing with the signaling
> > > >  > > > mechanism in the application layer. So, SIP does
> > > >  > >not need to deal with L3
> > > >  > > > media path.
> > > >  > > >
> > > >  > > > SIP does deal with addresses of the source and
> > > >  > >destination(s).
> > > >  > > >
> > > >  > > > In mobile environment, the point of attachment
> > > >  > >(i.e., addresses) changes: 1.
> > > >  > > > Between the sessions (discrete mobility) and 2.
> > > >  > >During the session
> > > >  > > > (continuous mobility).
> > > >  > > >
> > > >  > > > The problem that is being addressed is: What is the
> > > >  > >impact in SIP layer due
> > > >  > > > to these two kinds of mobility.
> > > >  > > >
> > > >  > > > I guess that for discrete mobility, SIP has
> > > >  > >probably addressed most of the
> > > >  > > > problems (others may also provide comments on this).
> > > >  > > >
> > > >  > > > For continuous mobility, there may need (or may
> > > >  > >not??) some works in the SIP
> > > >  > > > layer, if any (others may also provide comments).
> > > >  > > >
> > > >  > > > However, SIP can only address the mobility related
> > > >  > >problems in the
> > > >  > > > application layer. This alone may not be enough to
> > > >  > >solve all problems
> > > >  > > > because some L3 and L2 problems may also need to be
> > > >  > >addressed at the same
> > > >  > > > time to have the complete solution.
> > > >  > > >
> > > >  > > > In any solution, SIP mobility needs to be limited
> > > >  > >only to the application
> > > >  > > > layer (not L3, L2, etc.).
> > > >  > > >
> > > >  > > > Best regards,
> > > >  > > > Radhika R. Roy
> > > >  > > > AT&T
> > > >  > > >
> > > >  > > > -----Original Message-----
> > > >  > > > From: Michael Thomas [ mailto:mat@cisco.com
><mailto:mat@cisco.com> ]
> > > >  > > > Sent: Wednesday, September 27, 2000 12:32 PM
> > > >  > > > To: Lewis Karl-QA3387
> > > >  > > > Cc: 'Henning Schulzrinne'; sip@lists.bell-labs.com
> > > >  > > > Subject: RE: [SIP] Attempt at summarizing current SIP drafts
> > > >  > > >
> > > >  > > >
> > > >  > > >
> > > >  > > > While I'm more than willing to believe that there
> > > >  > > > are mobility issues that SIP needs to deal with,
> > > >  > > > this paper seems to be positing SIP as the means
> > > >  > > > of initiating data sessions altogether. To my
> > > >  > > > mind, that's a rather bellheaded way of thinking
> > > >  > > > about how you do what amounts to L3 admission
> > > >  > > > control. In fact, the IETF already has an L3
> > > >  > > > admission control mechanism: RSVP. RSVP's main
> > > >  > > > advantage is that it follows actual network
> > > >  > > > topology. SIP is at a distinct disadvantage since
> > > >  > > > all it knows about is the signaling path which
> > > >  > > > in normal circumstances has nothing to do with
> > > >  > > > the actual data path.
> > > >  > > >
> > > >  > > > Maybe I'm misreading this whole paper, but it sure
> > > >  > > > looks like it to me. If my interpretation is
> > > >  > > > right, however, I'd like to know if the intention
> > > >  > > > is to signal the access routers providing the
> > > >  > > > L2/L3 bits using SIP instead of, say, COPS (or
> > > >  > > > DIAMETER). If so, I'd say that SIP truly has
> > > >  > > > arrived at becoming the new millenium's kitchen
> > > >  > > > sink if this is accepted.
> > > >  > > >
> > > >  > > >    Mike
> > > >  > > >
> > > >  > > > Lewis Karl-QA3387 writes:
> > > >  > > >  > I have just reviewed the Mobility Related drafts
> > > >  > >and am wondering if
> > > >  > > > anyone
> > > >  > > >  > is aware of the current status of
> > > >  > >draft-itsumo-sip -mobility-req-01. In
> > > >  > > >  > particular, several issues were identified such
> > > >  > >as Mobile IP not being
> > > >  > > >  > sufficient for personal mobility and location
> > > >  > >services, completing
> > > >  > > >  > registration in less than a few seconds,
> > > >  > >reconfiguration in milliseconds,
> > > >  > > >  > providing location services, support of inter
> > > >  > >domain soft-hand and secure
> > > >  > > >  > signaling. Have these issues been addressed or
> > > >  > >actively being worked?
> > > >  > > >  >
> > > >  > > >  > Karl
> > > >  > > >  >
> > > >  > > >  >
> > > >  > > >  >
> > > >  > > >  > -----Original Message-----
> > > >  > > >  > From: Henning Schulzrinne
> > > >  > [ mailto:schulzrinne@cs.columbia.edu
><mailto:schulzrinne@cs.columbia.edu> ]
> > > >  >  >  > Sent: Monday, September 25, 2000 9:20 AM
> > > >  >  >  > To: sip@lists.bell-labs.com
> > > >  >  >  > Subject: [SIP] Attempt at summarizing current SIP drafts
> > > >  >  >  >
> > > >  >  >  >
> > > >  >  >  > Given the proliferation of SIP-related drafts, I've
> > > >  > created a summary of
> > > >  >  >  > efforts at
> > > >  > http://www.cs.columbia.edu/~hgs/sip/drafts.html
><http://www.cs.columbia.edu/~hgs/sip/drafts.html> . This is
> > > >  >  >  > known to be incomplete, so I'd appreciate if you could
> > > >  > send me any
> > > >  >  >  > additions or corrections. (Jonathan Rosenberg provided
> > > >  > some of the text;
> > > >  >  >  > any mistakes or misrepresentations are mine.)
> > > >  >  >  >
> > > >  >  >  > It is fairly clear that there are a large number of drafts
> > > >  > that have not
> > > >  >  >  > changed materially for half a year or more. Maybe it's
> > > >  > time to have a WG
> > > >  >  >  > last call or two or ten...
> > > >  >  >  >
> > > >  >  >  > Henning
> > > >  >  >  > --
> > > >  >  >  > Henning Schulzrinne   http://www.cs.columbia.edu/~hgs
><http://www.cs.columbia.edu/~hgs>
> > > >  >  >  >
> > > >  >  >  >
> > > >  >  >  > _______________________________________________
> > > >  >  >  > SIP mailing list
> > > >  >  >  > SIP@lists.bell-labs.com
> > > >  >  >  > http://lists.bell-labs.com/mailman/listinfo/sip
><http://lists.bell-labs.com/mailman/listinfo/sip>
> > > >  >  >  >
> > > >  >  >  > _______________________________________________
> > > >  >  >  > SIP mailing list
> > > >  >  >  > SIP@lists.bell-labs.com
> > > >  >  >  > http://lists.bell-labs.com/mailman/listinfo/sip
><http://lists.bell-labs.com/mailman/listinfo/sip>
> > > >  >  >  >
> > > >  >  >
> > > >  >  > _______________________________________________
> > > >  >  > SIP mailing list
> > > >  >  > SIP@lists.bell-labs.com
> > > >  >  > http://lists.bell-labs.com/mailman/listinfo/sip
><http://lists.bell-labs.com/mailman/listinfo/sip>
> > > >  >  >
> > > >  >  > _______________________________________________
> > > >  >  > SIP mailing list
> > > >  >  > SIP@lists.bell-labs.com
> > > >  >  > http://lists.bell-labs.com/mailman/listinfo/sip
><http://lists.bell-labs.com/mailman/listinfo/sip>
> > > >  >  >
> > > >  >
> > > >  > _______________________________________________
> > > >  > SIP mailing list
> > > >  > SIP@lists.bell-labs.com
> > > >  > http://lists.bell-labs.com/mailman/listinfo/sip
><http://lists.bell-labs.com/mailman/listinfo/sip>
> > > >  >
> > > >  >
> > > >
> > > >_______________________________________________
> > > >SIP mailing list
> > > >SIP@lists.bell-labs.com
> > > > http://lists.bell-labs.com/mailman/listinfo/sip
><http://lists.bell-labs.com/mailman/listinfo/sip>
> > > >
> > > >_______________________________________________
> > > >SIP mailing list
> > > >SIP@lists.bell-labs.com
> > > > http://lists.bell-labs.com/mailman/listinfo/sip
><http://lists.bell-labs.com/mailman/listinfo/sip>
>
>
>_______________________________________________
>SIP mailing list
>SIP@lists.bell-labs.com
>http://lists.bell-labs.com/mailman/listinfo/sip
><http://lists.bell-labs.com/mailman/listinfo/sip>
>
>
>_______________________________________________
>SIP mailing list
>SIP@lists.bell-labs.com
>http://lists.bell-labs.com/mailman/listinfo/sip

--=====================_34725893==_.ALT-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 4 19:07:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA03710 for ; Wed, 4 Oct 2000 19:07:02 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 487CE443D2; Wed, 4 Oct 2000 18:07:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 9CA0644362 for ; Wed, 4 Oct 2000 18:06:10 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id TAA28560; Wed, 4 Oct 2000 19:08:04 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Wed, 4 Oct 2000 19:02:33 -0400 Message-ID: From: Jonathan Rosenberg To: "'Jon.Peterson@Level3.com'" , "'achoksi@vovida.com'" , "'long@nortelnetworks.com'" Cc: "'sip@lists.bell-labs.com'" Subject: RE: [SIP] SIP ISUP MIME draft MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 4 Oct 2000 19:02:27 -0400 > -----Original Message----- > From: Jon.Peterson@Level3.com [mailto:Jon.Peterson@Level3.com] > Sent: Wednesday, October 04, 2000 3:38 PM > To: achoksi@vovida.com; long@nortelnetworks.com > Cc: sip@lists.bell-labs.com > Subject: RE: [SIP] SIP ISUP MIME draft > > > > 2. It is optional, but it has a default value as outlined in > rfc2543 which > we are not overloading - namely that the content should be > considered a > mandatory content (handling=required), and that in requests and 2xx > responses 'session' is the assumed disposition for > backwards-compatibility. > > However, rfc2543bis-02 also specifies that if the MIME type > doesn't have a > default disposition, then the disposition should be assumed > to be 'render'. > This seems to conflict with the backwards compatibility > mechanism described > above, and someone should probably fix that. I'd vote for > mainaining the > latter statute. You are right, this seems to be contradictory. I think the former one is sort of trying to say that the default content disposition value for SDP is "session". I agree that the latter statute is better. > > Now, that much said, the ISUP MIME draft today doesn't > specify a default > content disposition for the ISUP MIME type. As the bis asks > MIME types to > have a default, I think we probably should define one, and I > think it should > be 'session' for ISUP. I suppose it would be the same for > QSIG... Lyndon, > have any feelings about that? No, I don't think session is write. This is not a session description. It is describing extra information used to support signaling interworking. I think a new content-disposition makes sense here. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 4 19:11:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA03776 for ; Wed, 4 Oct 2000 19:11:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7A223443EA; Wed, 4 Oct 2000 18:11:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 19B8344362 for ; Wed, 4 Oct 2000 18:10:16 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id TAA28596; Wed, 4 Oct 2000 19:12:14 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Wed, 4 Oct 2000 19:06:43 -0400 Message-ID: From: Jonathan Rosenberg To: "'Deepak Pant'" , "'sip@lists.bell-labs.com'" Subject: RE: [SIP] Question about UA behaviour to 407 response MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 4 Oct 2000 19:06:39 -0400 > -----Original Message----- > From: Deepak Pant [mailto:pantdee@charlie.cns.iit.edu] > Sent: Wednesday, October 04, 2000 5:21 PM > To: sip@lists.bell-labs.com > Subject: [SIP] Question about UA behaviour to 407 response > > > rfc2543bis-02 says (Pg 93 , Sec 14.1 ) "When a UAC resubmits a request > with its credentials after receiving a 401 or 407 response, it MUST > increment the CSeq header field as it would normally do when sending > updated request." > > However 407 is a final response and all the SIP proxy should expect > after sending a 407 (in response to INVITE) is an ACK and a new > INVITE message with a new CallID. The sip call flows draft is more > in line with the reasoning. > > Does the explanation in the rfc conflict the call flows? I suppose either way (totally new Call-ID, or same Call-ID, higher CSeq) will work. I think the latter (higher CSeq), is better, since it provides a useful way of correlating the two at the proxy, if the proxy wants to make use of that (of course it can't depend on it). > > > For the authentication for REGISTER messages, if a SIP proxy accepts > a registration message from a UA on behalf of a third party, how > should the UA be authenticated. Should the registration message be > forwarded to the home proxy and whatever challenge is issued by the > home proxy proxied back to the UA or should the SIP proxy use an > alternate mechanism as well. A proxy is a proxy. If it forwards a request downstream, it forwards the responses back upstream. If the proxy wishes to authenticate the client itself, it would use proxy-authentication. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 4 19:58:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA04799 for ; Wed, 4 Oct 2000 19:58:02 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 401BA443A5; Wed, 4 Oct 2000 18:58:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from june.Broomfield1.level3.net (june.Broomfield1.Level3.net [209.245.18.7]) by lists.bell-labs.com (Postfix) with ESMTP id 3203944362 for ; Wed, 4 Oct 2000 18:57:55 -0400 (EDT) Received: from f1ee40-19.idc1.level3.com (hme0.f1ee40-19.idc1.oss.level3.com [10.1.144.204]) by june.Broomfield1.level3.net (8.9.3/8.9.3) with ESMTP id XAA04455; Wed, 4 Oct 2000 23:57:51 GMT From: Jon.Peterson@Level3.com Received: from n0195idc1.oss.level3.com (localhost [127.0.0.1]) by f1ee40-19.idc1.level3.com (8.8.8+Sun/8.8.8) with ESMTP id RAA12740; Wed, 4 Oct 2000 17:57:47 -0600 (MDT) Received: by n0195idc1.oss.level3.com with Internet Mail Service (5.5.2650.21) id ; Wed, 4 Oct 2000 17:59:37 -0600 Message-ID: <87A245E94948D3118DE30008C716B01301523B9E@c0005v1idc1.oss.level3.com> To: jdrosen@dynamicsoft.com, achoksi@vovida.com, long@nortelnetworks.com Cc: sip@lists.bell-labs.com Subject: RE: [SIP] SIP ISUP MIME draft MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 4 Oct 2000 17:57:36 -0600 Well, 'session' seemed better than any of the other options listed in the bis, anyway. I suppose 'session' would then refer exclusively to SDP? It was be nice if the disposition-type used for ISUP and QSIG could be the same, and could cover any other encapsulated signals from other protocols that are used by interworking UAs, at the very least. Perhaps 'signal' as a disposition-type? Jon Peterson Level(3) Communications -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Wednesday, October 04, 2000 5:02 PM To: Peterson, Jon; 'achoksi@vovida.com'; 'long@nortelnetworks.com' Cc: 'sip@lists.bell-labs.com' Subject: RE: [SIP] SIP ISUP MIME draft > -----Original Message----- > From: Jon.Peterson@Level3.com [mailto:Jon.Peterson@Level3.com] > Sent: Wednesday, October 04, 2000 3:38 PM > To: achoksi@vovida.com; long@nortelnetworks.com > Cc: sip@lists.bell-labs.com > Subject: RE: [SIP] SIP ISUP MIME draft > > > > 2. It is optional, but it has a default value as outlined in > rfc2543 which > we are not overloading - namely that the content should be > considered a > mandatory content (handling=required), and that in requests and 2xx > responses 'session' is the assumed disposition for > backwards-compatibility. > > However, rfc2543bis-02 also specifies that if the MIME type > doesn't have a > default disposition, then the disposition should be assumed > to be 'render'. > This seems to conflict with the backwards compatibility > mechanism described > above, and someone should probably fix that. I'd vote for > mainaining the > latter statute. You are right, this seems to be contradictory. I think the former one is sort of trying to say that the default content disposition value for SDP is "session". I agree that the latter statute is better. > > Now, that much said, the ISUP MIME draft today doesn't > specify a default > content disposition for the ISUP MIME type. As the bis asks > MIME types to > have a default, I think we probably should define one, and I > think it should > be 'session' for ISUP. I suppose it would be the same for > QSIG... Lyndon, > have any feelings about that? No, I don't think session is write. This is not a session description. It is describing extra information used to support signaling interworking. I think a new content-disposition makes sense here. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 4 23:37:00 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA09279 for ; Wed, 4 Oct 2000 23:36:59 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E1AF3443D2; Wed, 4 Oct 2000 22:37:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from hotmail.com (f123.law7.hotmail.com [216.33.237.123]) by lists.bell-labs.com (Postfix) with ESMTP id 7E3A9443D2 for ; Wed, 4 Oct 2000 22:36:33 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 4 Oct 2000 20:36:29 -0700 Received: from 164.164.6.34 by lw7fd.law7.hotmail.msn.com with HTTP; Thu, 05 Oct 2000 03:36:29 GMT X-Originating-IP: [164.164.6.34] From: "rahul pande" To: sip@lists.bell-labs.com Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 05 Oct 2000 03:36:29.0887 (UTC) FILETIME=[72D734F0:01C02E7D] Subject: [SIP] SIP/SDP attribute under...... Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 05 Oct 2000 09:06:29 IST Hello All, I am having problem in understanding the "a=fmtp:" attribute, i haave tried to contact the confctrl@isi.edu, but no one responds. The problem is somewhat related to SIP and other tools also which will be using SDP. SDP rfc2327 says :: "a=fmtp: This attribute allows parameters that are specific to a particular format to be conveyed in a way that SDP doesn't have to understand them. The format must be one of the formats specified for the media. Format-specific parameters may be any set of parameters required to be conveyed by SDP and given unchanged to the media tool that will use this format. " Sir, above whom is the rfc refering to as a "media tool" Secondly sir, Its clear that the SDP parsers don't have to worry about the , but who is going to handle the parseing of this parameter, since PINT, RTP payload types and others are having different grammar for . Can someone please give me some details reguerding this or please do refer me a URL. Thanking you, rahul _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. Share information about yourself, create your own public profile at http://profiles.msn.com. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Oct 5 00:37:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA10008 for ; Thu, 5 Oct 2000 00:37:03 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5DE5E443D2; Wed, 4 Oct 2000 23:37:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sumo.vocaltec.co.il (sumo.vocaltec.co.il [199.203.72.1]) by lists.bell-labs.com (Postfix) with ESMTP id A657D443B7 for ; Wed, 4 Oct 2000 23:36:51 -0400 (EDT) Received: from il4.vocaltec.co.il (notesgw.vocaltec.co.il [199.203.72.136]) by sumo.vocaltec.co.il (8.9.3/8.9.3) with ESMTP id HAA11573; Thu, 5 Oct 2000 07:39:48 +0200 (IST) From: Joshua_Fox@vocaltec.com Subject: RE: [SIP] centralized vs. decentralized architectures To: sip@lists.bell-labs.com, Cliff.Harris@nokia.com X-Mailer: Lotus Notes Release 5.0.3 March 21, 2000 Message-ID: X-MIMETrack: Serialize by Router on IL4/Vocaltec_Comm(Release 5.0.3 |March 21, 2000) at 10/05/2000 07:35:49 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 5 Oct 2000 07:35:45 +0200 >Why doesn't a B2BUA provide true anonymity? By the way, I'm curious about >why anonymity is so important: are there legitimate reasons for people to >make calls anonymously? When I mentioned "anonymity", I wasn't referring to the idea of keepingyour human identity secret; I meant that for convenience, the user should not have to provide a network identifier before making a call. There are indeed legitimate reasons for people to make calls anonymously in this sense--that's what we do when we call from a pay phone. Of course, a pay phone has an E.164 number assigned to it--but what would you do if anyone could instantly download and instantiate as many "pay phones" as they want? There are various solutions to this problem: Require the user to register an identifier (perhaps the most common solution), have the IP phone request an identifier from a server, or generate an identifier randomly. Naturally, unless the user registers, such a phone is only good for outgoing calls. Joshua Fox _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Oct 5 05:41:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA24193 for ; Thu, 5 Oct 2000 05:41:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 890A944342; Thu, 5 Oct 2000 04:41:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lists.bell-labs.com (Postfix) with ESMTP id 833164433D for ; Thu, 5 Oct 2000 04:40:15 -0400 (EDT) Received: from esealnt409.al.sw.ericsson.se (esealnt409.al.sw.ericsson.se [153.88.251.32]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id e959eAZ07068 for ; Thu, 5 Oct 2000 11:40:10 +0200 (MEST) Received: FROM esealnt743.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Thu Oct 05 11:40:08 2000 +0200 Received: by esealnt743.al.sw.ericsson.se with Internet Mail Service (5.5.2651.58) id ; Thu, 5 Oct 2000 11:40:09 +0200 Message-ID: <56E7307B0850D411B1480008C75DD5EAB73CF5@enlrynt303.dsn.ericsson.se> From: "Arnoud van Wijk (ELN)" To: "'hammer michael'" , Brian Stucker , Rohan Mahy , "Roy, Radhika R, ALCOO" Cc: sip@lists.bell-labs.com Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP Mobility ) MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="ISO-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 5 Oct 2000 11:40:00 +0200 It is indeed a good idea to look at the problem. First is the question of "what" we are talking about. And if the problem is indeed happening. When logged in via a mobile terminal on an IP network, the outside world should always see the same IP address for the mobile terminal. For the user it can be a mobile IP or an IP address asigned when the mobile terminal logged on. If the endpoint changes, the mobile network will change the routing and whatever that is needed for the handover. The user should still remain an IP address that does not change. So SIP should still see the same end point. And for SIP there are no changes at all. So, a requirement for the SIP proxy of the IP-operator should then be that the server has to be able to change the IP-address to the IP-address that the outside world sees the mobile terminal using. (if the IP-address changes during hand-over). I do not know everything about mobile internet. I am also not sure what the current solutions are. I could look it up etc, but I have more things to do. Is this not similar to the SIP-NAT problem, where the internal part of a network has different IP-addresses then the outside part? Maybe I am overlooking a lot of issues. Just my 2 cents. Arnoud van Wijk -----Original Message----- From: hammer michael [mailto:mhammer@cisco.com] Sent: donderdag 5 okt 2000 3:48 To: Brian Stucker; Rohan Mahy; Roy, Radhika R, ALCOO Cc: sip@lists.bell-labs.com Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP Mobility ) All, For the record, I agree with the idea that the lower layers should handle mobility. However, one possibility exists that could take the control out of the hands of the lower layer. I'm not sure if this is the issue we are circling, but let me try to describe what I think could happen. The IP layer can address what happens to the communication end-to-end so long as it is really end-to-end. If a proxy is used to patch together two end-to-end IP streams, then any IP-dependent mechanism would be constrained by its knowledge of what the endpoint is. If only one end-to-end stream is used, then the IP layer should be able to maintain flows to that endpoint even as it moves within a network domain. If movement causes the terminal to relinquish an IP address and get a new one in a new network, registrations at the network layer can reestablish IP identities among communicating parties. Also, that same registration mechanism is how a user or proxy finds the other user to begin with. If a message is not acknowledged, then another location request is needed. However, if the real end-point is hidden behind a proxy using another IP stream, then the proxy is burdened with the responsibility to keep track of the end-points on the two streams. But this would be just two instances of the simple example. So, the problem seems to come down to whether the information on the whereabouts of a user is present or can be obtained by some mechanism on a timely basis should an acknowledgement not be received. I had the impression that this was not a problem. Is it the responsibility of the user to push that information to the proxy, or is it the proxy's responsibility to pull that information from the registrar? Either way, that should not be a problem in the time-scale of a session set-up or release. In a world where the terminal is "always on", the role of SIP may be more attuned to whether the user wants to be reached, not where or how to reach the user. But that digresses into another subject. Mike Hammer At 04:23 PM 10/04/2000 -0500, Brian Stucker wrote: I definitely agree with that sentiment. That was the point of my argument. Do nothing in regards to SIP, and if there's something particular to SIP that needs to be addressed in a layer below SIP, then we should be trying to inject requirements and influence the decisions being made there first. Brian -----Original Message----- From: Rohan Mahy [ mailto:rohan@cisco.com ] Sent: Wednesday, October 04, 2000 3:14 PM To: Roy, Radhika R, ALCOO Cc: Stucker, Brian [RICH2:WI12:EXCH]; sip@lists.bell-labs.com Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP Mobility ) At 10:51 AM 9/29/00 , Roy, Radhika R, ALCOO wrote: >Hi, Brian: > >I guess that your mail has provided some technical inputs: 1. Inter-session >mobility and 2. Intra-session mobility. > >For inter-session mobility, you think that SIP in OK. > >For intra-session mobility, it appears that you are feeling comfortable, as >if, SIP is not designed to do this. > >Let us go to the basic: SIP is a session initiation protocol. It is the >mandate of SIP. So, we like to see that it MUST deal with mobility as well *NO* !! Part of SIPs mandate is *personal* mobility, as a user moves from device to device. Personal mobility is a good, useful thing. However, The SIP charter does *NOT* include solving the problem of a device moving through different layer 2 networks. This is a problem for a layer 3 protocol to solve generically. If Mobile IP doesn't do what we need it to, then lets extend it, fix it, or replace it. thanks, -rohan >because people will use it in mobile environment (for both intra- and >inter-session). > >For inter-session, I guess that there may be some involvement of REGISTER >and re-INVITE messages (because of change in location). > >That's all! > >All works are done in the lower layer and SIP is not involved (for example, >some one in the lower layer will find that the location has been changed, >accordingly the upper layer may take some actions, if needed). > >Hope this will clarify the things. > >Best regards, >Radhika R. Roy >AT&T > >-----Original Message----- >From: Brian Stucker [ mailto:bstucker@nortelnetworks.com ] >Sent: Friday, September 29, 2000 1:19 PM >To: sip@lists.bell-labs.com >Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP Mobility ) > > > >My intent isn't to confuse anyone. Quite the contrary. > >My point is that SIP, as an application, should not be concerned about the >vagaries of the underlying media it's being carried on. All applications >that use IP as a transport are going to have to contend with mobility in the >IP space on the intra-session timescale. So IP should solve the problem >because it's a general problem for IP. > >SIP does enough to handle inter-session mobility (I'm at my desk, I'm at >home), and not impede intra-session mobility. It's just simply not suited >for handling anything else because of the nature of the protocol. Any >intra-session mobility must be handled out-of-band as far as SIP is >concerned, and SIP must not make any requirements that would impede this. > >Again, to use wireless voice calls as an example, even with dedicated >transport links, thousands of pages of standards with CDMA/TDMA, IS-41, SS7, >and TCAP, a mobile switching center doesn't attempt to do what you guys are >talking about. It doesn't update the location of a mobile once it's handed >over to another switch in the location database until after your call has >completed, and the mobile registers on the system it moved into. Why? >Because the mobile could be handed back over to the first system, the >handoff could fail, etc. So they don't even attempt to keep the exact >location of the mobile up to date outside of the original switch until the >mobile is stable again, when the call ends. Instead, all incoming calls go >to the first switch, and that switch knows where to go from there to get the >call completed. > >SIP shouldn't be updating the location database every time a wireless >terminal moves around. Some sort of mobile IP proxy function, should instead >be used that knows how to currently find the terminal in it's mobile-aware >IP space. It should route based on the inbound packet's IP address only, and >not care what the payload data is either. > >That solves the problem for SIP, HTTP, FTP, POP3, RTP, you name it. Why >write an extension to every protocol that uses IP as a transport (and have >it solved, and debugged a million different ways) instead of just fixing the >problem at the IP layer (and have it solved, and debugged one way)? > >Brian Stucker >Nortel Networks > >-----Original Message----- >From: Roy, Radhika R, ALCOO [ mailto:rrroy@att.com < mailto:rrroy@att.com > ] >Sent: Friday, September 29, 2000 11:39 AM >To: hammer michael; Michael Thomas; Henry Sinnreich >Cc: Lewis Karl-QA3387; 'Henning Schulzrinne'; sip@lists.bell-labs.com >Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP >Mobility ) > > >Hi, Everyone: > >The need for addressing mobility is clear and SIP is only one part of the >whole equation. > >Let us not confuse people in the name of Pandora's box or otherwise. > >We have to meet the needs solving problems (not to show our back). > >For the SIP WG, it is the SIP session layer that needs to be addressed, if >it turns out that is a need to do some works. > >Best regards, >Radhika R. Roy >AT&T > >-----Original Message----- >From: hammer michael [ mailto:mhammer@cisco.com < mailto:mhammer@cisco.com > ] > >Sent: Friday, September 29, 2000 1:57 PM >To: Roy, Radhika R, ALCOO; Michael Thomas; Henry Sinnreich >Cc: Lewis Karl-QA3387; 'Henning Schulzrinne'; sip@lists.bell-labs.com >Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP >Mobility ) > > >I think Brian aptly pointed out the Pandora's box you open with "mobility." >That should be sufficient motivation to avoid that type of mobility in SIP. > >We are talking about different timescales, e.g.: per packet, per call, and >per registration. > >I thought your term "discrete" captured the idea that the type of >"mobility" you refer to is of the: call me at the office, then later, call >me at home, I'm here now "mobility." Because mobility conjures up so many >more issues, I like the word "presence" better. Presence management may be >more descriptive that mobility management. > >Mike > > >At 04:11 PM 09/28/2000 -0400, Roy, Radhika R, ALCOO wrote: > >Hi, Mike: > > > >Yes, we will have problems if we do not define the terms accurately. > > > >Let us assume that we are using SIP (RFC 2543) and its session layer as our > > >reference. Location, registration, and session are defined in SIP. > > > >Paging (and probably "path") has not been defined in SIP. I will not argue > >to take this abstraction in the SIP layer for now. > > > >Point of attachment has been used as a generic term to indicate "address of > > >the attachment." If we translate this abstraction in the SIP layer, it will > > >mean the addresses that are being used in the SIP layer (e.g., E.164, IP > >address, etc.). > > > >Now let us examine your points: Presence of a person or terminal, etc. > > > >In the SIP layer, I guess, that the presence of a person on a terminal >needs > >to be abstracted in terms of an "address." If that address is also related > >to the point of attachment, then it will also be related to mobility. > > > >(A person behind the terminal may have another ID to deal with personal > >mobility. Let us not address that personal mobility for now.) > > > >In this way, we can extend our analysis for each layer. > > > >Does this answer your question? > > > >Best regards, > >Radhika R. Roy > >AT&T > > > >-----Original Message----- > >From: hammer michael [ mailto:mhammer@cisco.com < mailto:mhammer@cisco.com > >] > >Sent: Thursday, September 28, 2000 6:29 PM > >To: Roy, Radhika R, ALCOO; Michael Thomas; Henry Sinnreich > >Cc: Lewis Karl-QA3387; 'Henning Schulzrinne'; sip@lists.bell-labs.com > >Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP > >Mobility ) > > > > > >Roy, > > > >I need to be very careful what word I choose. Session connection rather > >than path might have been more appropriate. I believe confusion can occur > >if the type of location, registration, location, paging, etc. is not > >accurately defined. I think that the intent of such services revolves > >about maintaining relationships between certain elements, such as between: > > > >user/application and terminal, > >terminal and network end-point, > >network end-point and link end-point, etc. > > > >The act of "registering" may mean different things at different layers and > >use different mechanisms to accomplish them. The question for me is > >whether these are handled independently or does one mechanism attempt to > >manage multiple associations or would one type of registration trigger > >another type at a different layer? > > > >Would SIP then manage the "presence" of a person on a terminal, where > >something else manages the "presence" of a terminal on the network? > > > >Mike Hammer > > > > > >At 12:28 PM 09/28/2000 -0400, Roy, Radhika R, ALCOO wrote: > > >Hi, Mike: > > > > > >You have made excellent points. In fact, you are in the heart of this > > >problem: How the communications path(s) needs to be established as the > >point > > >of attachment is changed during the contiguous mobility. > > > > > >I personally believe that SIP does not need to be involved to set up the > > >communications path(s) per se. > > > > > >However, SIP needs to be used to set up the session: re-INVITE (to the >new > > >address) may need to be used. > > > > > >In the process, location updates, paging, etc. are also involved. If the > > >location update does not have any impact in the SIP layer, I do not think > > > >that SIP should be aware of any change in the lower layer. For example, > > >mobile IP has the power of providing location transparency of the IP >layer > > >(although it has some problems to meet the performance requirements for >the > > >real-time communications like voice). > > > > > >In addition to IP addresses, there are also transport addresses (e.g., >UDP, > > >TCP) for media. One also needs to be careful how to deal with the TCP > > >connection. IP addresses change, but the TCP connections still remains >the > > >same. An update mechanism needs to be defined. In turn, does it mean that > > > >this updated information may also be propagated to the SIP layer (other > > >members may also provide comments on this) because SIP does have the > > >abstraction of the transport address? > > > > > >I have not yet talked about the link layer. > > > > > >I am not trying to solve the mobility problem here. > > > > > >All I am trying to show: If we try to analyze the situation doing an > > >end-to-end analysis, we can easily see what needs to be done in each >layer. > > >Finally, we can answer the question: Whether or not any new work is >needed > > >in the SIP layer to address both discrete and continuos mobility. > > > > > >But you are right that we MUST keep the involvement of the SIP layer to a > > > >minimal level (if possible, we should avoid it) to address the mobility > > >problem. > > > > > >Best regards, > > >Radhika R. Roy > > >AT&T > > > > > >-----Original Message----- > > >From: hammer michael [ mailto:mhammer@cisco.com >< mailto:mhammer@cisco.com > ] > > >Sent: Thursday, September 28, 2000 2:41 PM > > >To: Roy, Radhika R, ALCOO; Michael Thomas; Henry Sinnreich > > >Cc: Lewis Karl-QA3387; 'Henning Schulzrinne'; sip@lists.bell-labs.com > > >Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP > > >Mobility ) > > > > > > > > >Roy, > > > > > >Your use of the terms "discrete" and "continuous" strike to the heart of > > >the issue. In traditional mobile networks, there is an attempt to move >the > > >stream of media with the terminal as it crosses cell boundaries > > >(continuous). There are many papers related to voice and mobile-IP that > > >address how to move the communications path. > > > > > >The discrete case is more an issue of identification of the presence and > > >availability of recipients and the establishment of communications to > > >them. Because names and addresses denoting physical location are often > > >blurred, in essence, personal mobility involves the creation and deletion > > > >of recipients rather than their movement. > > > > > >As I understand it, SIP does not move existing communications so much as >it > > >destroys existing communications paths and replaces them with new ones. >In > > >that respect, some of the traditional mobility issues such as handover >are > > >avoided, but others, e.g. location updates and paging are still needed. > > > > > >While the telcos reverted to addressing hardware-oriented terminal >mobility > > >in PCS, the softer personal mobility is still open to definition. The >same > > >issues have appeared in the net world and each will need to be solved in > > >their respective layers. > > > > > >Mike > > > > > > > > >At 11:01 AM 09/28/2000 -0400, Roy, Radhika R, ALCOO wrote: > > > >Hi, Mike: > > > > > > > >In fact, this is the precisely the test why SIP should be involved or >to > >be > > > >enhanced to support mobility (discrete + continuos) in the case of >Voice, > > > >chat, IM, messaging, conferencing, games, and others. > > > > > > > >If it is found that SIP does not need to be involved, I do not think >that > > > >anyone will force it to do this. > > > > > > > >By the way, do you not see that how SIP (RFC 2543) has taken care of >many > > > >aspects of users' discrete mobility? Has it not been be an excellent >way > >of > > > >involving SIP to solve a kind of mobility in the first place (what >other > > > >applications like H.323 is yet to support)? > > > > > > > >Along the same line, if people come up with the ideas that it is better > > >to > > > >enhance SIP functionality to support other aspects of mobility (if > > > >alternative solutions are not there or not acceptable), I do not think > >that > > > >we should have any objections. > > > > > > > >Let us keep our mind open and judge each proposal with its own merits. > > > > > > > >Best regards, > > > >Radhika R. Roy > > > >AT&T > > > > > > > >-----Original Message----- > > > >From: Michael Thomas [ mailto:mat@cisco.com < mailto:mat@cisco.com > ] > > > >Sent: Wednesday, September 27, 2000 7:01 PM > > > >To: Henry Sinnreich > > > >Cc: Michael Thomas; Roy, Radhika R, ALCOO; Lewis Karl-QA3387; 'Henning > > > >Schulzrinne'; sip@lists.bell-labs.com > > > >Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP > > > >Mobility ) > > > > > > > > > > > >Henry Sinnreich writes: > > > > > >what seems clear is that there are a > > > > > >number of applications which won't be able to do > > > > > >that for a variety of reasons. > > > > > > > > > > Voice, chat, IM, messaging, conferencing, games, etc., are > > > > > plenty of reasons to justify the SIP approach to mobility. > > > > > > > > But what if you could do all of the same things > > > > and not need to modify or involve SIP and have the > > > > additional gain that things like http worked as well? > > > > > > > > Mike > > > > > > > > > > > > > > Henry > > > > > > > > > > >-----Original Message----- > > > > > >From: sip-admin@lists.bell-labs.com > > > > > >[ mailto:sip-admin@lists.bell-labs.com >< mailto:sip-admin@lists.bell-labs.com > ]On Behalf Of > > > > > >Michael Thomas > > > > > >Sent: Wednesday, September 27, 2000 8:33 PM > > > > > >To: Roy, Radhika R, ALCOO > > > > > >Cc: Michael Thomas; Lewis Karl-QA3387; 'Henning Schulzrinne'; > > > > > >sip@lists.bell-labs.com > > > > > >Subject: RE: [SIP] Attempt at summarizing current SIP > > > > > >drafts (SIP > > > > > >Mobility ) > > > > > > > > > > > > > > > > > > > > > > > >I guess what I'm having a hard time with is the > > > > > >starting point that assumes that SIP based > > > > > >application mobility is Good Thing. While it's > > > > > >clear that many applications *could* design in > > > > > >mobility, what seems clear is that there are a > > > > > >number of applications which won't be able to do > > > > > >that for a variety of reasons. Assuming that those > > > > > >applications are important too, then we're already > > > > > >stuck with needing to solve for the general > > > > > >problem. > > > > > > > > > > > >Starting out with the assumption that Mobile IP > > > > > >addresses the more general problem seems > > > > > >attractive because a good solution with fast > > > > > >handoff that addresses AAA and QoS would solve > > > > > >most of the application layer problems in a > > > > > >general way rather than just a SIP specific > > > > > >way. > > > > > > > > > > > >There also seems to be an implicit assumption in > > > > > >the draft of linkage of SIP to a AAA function. > > > > > >I'm going to guess that it is along the same line > > > > > >of thinking of the DQoS gate controller idea. The > > > > > >problem I have with that is that it is in the end > > > > > >an optimization on the normal RSVP/COPS pull > > > > > >model. However, things that don't fit into that > > > > > >model still have the non-optimized way of doing > > > > > >QoS authorization. That's probably not the fault > > > > > >of this draft, but it does seem to make the entire > > > > > >draft a cart-before-horse situation. > > > > > > > > > > > > Mike > > > > > > > > > > > >Roy, Radhika R, ALCOO writes: > > > > > > > Hi, Mike: > > > > > > > > > > > > > > I guess that SIP, as you rightly pointed out, is > > > > > >dealing with the signaling > > > > > > > mechanism in the application layer. So, SIP does > > > > > >not need to deal with L3 > > > > > > > media path. > > > > > > > > > > > > > > SIP does deal with addresses of the source and > > > > > >destination(s). > > > > > > > > > > > > > > In mobile environment, the point of attachment > > > > > >(i.e., addresses) changes: 1. > > > > > > > Between the sessions (discrete mobility) and 2. > > > > > >During the session > > > > > > > (continuous mobility). > > > > > > > > > > > > > > The problem that is being addressed is: What is the > > > > > >impact in SIP layer due > > > > > > > to these two kinds of mobility. > > > > > > > > > > > > > > I guess that for discrete mobility, SIP has > > > > > >probably addressed most of the > > > > > > > problems (others may also provide comments on this). > > > > > > > > > > > > > > For continuous mobility, there may need (or may > > > > > >not??) some works in the SIP > > > > > > > layer, if any (others may also provide comments). > > > > > > > > > > > > > > However, SIP can only address the mobility related > > > > > >problems in the > > > > > > > application layer. This alone may not be enough to > > > > > >solve all problems > > > > > > > because some L3 and L2 problems may also need to be > > > > > >addressed at the same > > > > > > > time to have the complete solution. > > > > > > > > > > > > > > In any solution, SIP mobility needs to be limited > > > > > >only to the application > > > > > > > layer (not L3, L2, etc.). > > > > > > > > > > > > > > Best regards, > > > > > > > Radhika R. Roy > > > > > > > AT&T > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Michael Thomas [ mailto:mat@cisco.com >< mailto:mat@cisco.com > ] > > > > > > > Sent: Wednesday, September 27, 2000 12:32 PM > > > > > > > To: Lewis Karl-QA3387 > > > > > > > Cc: 'Henning Schulzrinne'; sip@lists.bell-labs.com > > > > > > > Subject: RE: [SIP] Attempt at summarizing current SIP drafts > > > > > > > > > > > > > > > > > > > > > > > > > > > > While I'm more than willing to believe that there > > > > > > > are mobility issues that SIP needs to deal with, > > > > > > > this paper seems to be positing SIP as the means > > > > > > > of initiating data sessions altogether. To my > > > > > > > mind, that's a rather bellheaded way of thinking > > > > > > > about how you do what amounts to L3 admission > > > > > > > control. In fact, the IETF already has an L3 > > > > > > > admission control mechanism: RSVP. RSVP's main > > > > > > > advantage is that it follows actual network > > > > > > > topology. SIP is at a distinct disadvantage since > > > > > > > all it knows about is the signaling path which > > > > > > > in normal circumstances has nothing to do with > > > > > > > the actual data path. > > > > > > > > > > > > > > Maybe I'm misreading this whole paper, but it sure > > > > > > > looks like it to me. If my interpretation is > > > > > > > right, however, I'd like to know if the intention > > > > > > > is to signal the access routers providing the > > > > > > > L2/L3 bits using SIP instead of, say, COPS (or > > > > > > > DIAMETER). If so, I'd say that SIP truly has > > > > > > > arrived at becoming the new millenium's kitchen > > > > > > > sink if this is accepted. > > > > > > > > > > > > > > Mike > > > > > > > > > > > > > > Lewis Karl-QA3387 writes: > > > > > > > > I have just reviewed the Mobility Related drafts > > > > > >and am wondering if > > > > > > > anyone > > > > > > > > is aware of the current status of > > > > > >draft-itsumo-sip -mobility-req-01. In > > > > > > > > particular, several issues were identified such > > > > > >as Mobile IP not being > > > > > > > > sufficient for personal mobility and location > > > > > >services, completing > > > > > > > > registration in less than a few seconds, > > > > > >reconfiguration in milliseconds, > > > > > > > > providing location services, support of inter > > > > > >domain soft-hand and secure > > > > > > > > signaling. Have these issues been addressed or > > > > > >actively being worked? > > > > > > > > > > > > > > > > Karl > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Henning Schulzrinne > > > > > [ mailto:schulzrinne@cs.columbia.edu >< mailto:schulzrinne@cs.columbia.edu > ] > > > > > > > Sent: Monday, September 25, 2000 9:20 AM > > > > > > > To: sip@lists.bell-labs.com > > > > > > > Subject: [SIP] Attempt at summarizing current SIP drafts > > > > > > > > > > > > > > > > > > > > > Given the proliferation of SIP-related drafts, I've > > > > > created a summary of > > > > > > > efforts at > > > > > http://www.cs.columbia.edu/~hgs/sip/drafts.html >< http://www.cs.columbia.edu/~hgs/sip/drafts.html > . This is > > > > > > > known to be incomplete, so I'd appreciate if you could > > > > > send me any > > > > > > > additions or corrections. (Jonathan Rosenberg provided > > > > > some of the text; > > > > > > > any mistakes or misrepresentations are mine.) > > > > > > > > > > > > > > It is fairly clear that there are a large number of drafts > > > > > that have not > > > > > > > changed materially for half a year or more. Maybe it's > > > > > time to have a WG > > > > > > > last call or two or ten... > > > > > > > > > > > > > > Henning > > > > > > > -- > > > > > > > Henning Schulzrinne http://www.cs.columbia.edu/~hgs >< http://www.cs.columbia.edu/~hgs > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > SIP mailing list > > > > > > > SIP@lists.bell-labs.com > > > > > > > http://lists.bell-labs.com/mailman/listinfo/sip >< http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > SIP mailing list > > > > > > > SIP@lists.bell-labs.com > > > > > > > http://lists.bell-labs.com/mailman/listinfo/sip >< http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > SIP mailing list > > > > > > SIP@lists.bell-labs.com > > > > > > http://lists.bell-labs.com/mailman/listinfo/sip >< http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > > > > > > _______________________________________________ > > > > > > SIP mailing list > > > > > > SIP@lists.bell-labs.com > > > > > > http://lists.bell-labs.com/mailman/listinfo/sip >< http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > SIP mailing list > > > > > SIP@lists.bell-labs.com > > > > > http://lists.bell-labs.com/mailman/listinfo/sip >< http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > > > > > > > > > > > >_______________________________________________ > > > >SIP mailing list > > > >SIP@lists.bell-labs.com > > > > http://lists.bell-labs.com/mailman/listinfo/sip >< http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > >_______________________________________________ > > > >SIP mailing list > > > >SIP@lists.bell-labs.com > > > > http://lists.bell-labs.com/mailman/listinfo/sip >< http://lists.bell-labs.com/mailman/listinfo/sip > > > >_______________________________________________ >SIP mailing list >SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip >< http://lists.bell-labs.com/mailman/listinfo/sip > > > >_______________________________________________ >SIP mailing list >SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Oct 5 08:06:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA26997 for ; Thu, 5 Oct 2000 08:06:02 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id DFB2044386; Thu, 5 Oct 2000 07:06:01 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from alvin.loniis.spb.su (gw1.loniis.spb.su [195.201.37.253]) by lists.bell-labs.com (Postfix) with ESMTP id 969C64433D for ; Thu, 5 Oct 2000 07:05:05 -0400 (EDT) Received: from rts.nio1.loniis (rts.loniis.ru [195.201.37.111]) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id e95C4xe10337 for ; Thu, 5 Oct 2000 16:04:59 +0400 (MSD) Received: from Vova (vova.rts.nio1.loniis [192.168.100.180]) by rts.nio1.loniis (Postfix) with SMTP id E5F3FF3 for ; Thu, 5 Oct 2000 16:08:18 +0400 (MSD) Message-ID: <004701c02ec4$87b30ce0$b464a8c0@rts.nio1.loniis> From: =?koi8-r?B?88HNz9LF2s/XIPfMwcTJzcnS?= To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0044_01C02EE6.0E460700" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Subject: [SIP] (no subject) Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 5 Oct 2000 16:05:18 +0400 This is a multi-part message in MIME format. ------=_NextPart_000_0044_01C02EE6.0E460700 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable Could you help me, pls! I have easy question!=20 What , in general, is redirect server for? Not functions. Is it really = necessary to separate redirect server as logical unit?=20 Thank you! My best regards! Vladimir Samorezov St.-Petersburg Research And Development Center For Telecommunication = (LONIIS) 11, Washavskaya str, 196128, Saint-Petersburg,Russia Phone: +7 812 294 76 78, Fax: +7 812 296 76 78 E-mail: samorezov@rts.loniis.ru, http://www.loniis.ru=20 ------=_NextPart_000_0044_01C02EE6.0E460700 Content-Type: text/html; charset="koi8-r" Content-Transfer-Encoding: quoted-printable
Could you help me, = pls!
I have easy question! =
What , in general, is redirect = server for?=20 Not functions.  Is it really necessary=20 to separate redirect server  as logical unit? =
Thank you!
My best regards! Vladimir=20 Samorezov
 
St.-Petersburg Research And = Development=20 Center For Telecommunication (LONIIS)
11, Washavskaya str, 196128,=20 Saint-Petersburg,Russia
Phone: +7 812 294 76 78, Fax: +7 812 296 76=20 78
E-mail: samorezov@rts.loniis.ru, http://www.loniis.ru =
------=_NextPart_000_0044_01C02EE6.0E460700-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Oct 5 08:30:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA27451 for ; Thu, 5 Oct 2000 08:30:02 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A370F443DF; Thu, 5 Oct 2000 07:30:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from almso1.proxy.att.com (almso1.att.com [192.128.167.69]) by lists.bell-labs.com (Postfix) with ESMTP id 88B194433D for ; Thu, 5 Oct 2000 07:29:39 -0400 (EDT) Received: from gab200r1.ems.att.com ([135.37.94.32]) by almso1.proxy.att.com (AT&T IPNS/MSO-2.2) with ESMTP id IAA24193; Thu, 5 Oct 2000 08:29:35 -0400 (EDT) Received: from njb140bh2.ems.att.com by gab200r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2) id IAA20944; Thu, 5 Oct 2000 08:31:33 -0400 (EDT) Received: by njb140bh2.ems.att.com with Internet Mail Service (5.5.2652.35) id ; Thu, 5 Oct 2000 08:29:30 -0400 Message-ID: From: "Roy, Radhika R, ALCOO" To: "Arnoud van Wijk (ELN)" , "'hammer michael'" , Brian Stucker , Rohan Mahy Cc: sip@lists.bell-labs.com Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP Mobility ) MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 5 Oct 2000 08:29:27 -0400 Hi, Arnoud: Yes, you are right that if the lower makes the changes transparent to the upper lower layer, the upper layer will not do anything. This is a kind of implementation issues and people may choose to use those kinds of solutions if they like. But it should not be mandatory for everyone. (A whole industry is working for the mobility-aware middleware because the services provided by the lower is not sufficient. The classical thinking is going away and new services are emerging because of the new areas that are being opening up with the intelligence moving in the upper layer.) The fact of the matter still remains true that the address information in the register needs to be updated and one may still like to use the re-INVITE messages to the new addresses. If this solution is acceptable to anyone, let us allow them to use it. Best regards, Radhika R. Roy AT&T -----Original Message----- From: Arnoud van Wijk (ELN) [mailto:Arnoud.van.Wijk@eln.ericsson.se] Sent: Thursday, October 05, 2000 5:40 AM To: 'hammer michael'; Brian Stucker; Rohan Mahy; Roy, Radhika R, ALCOO Cc: sip@lists.bell-labs.com Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP Mobility ) It is indeed a good idea to look at the problem. First is the question of "what" we are talking about. And if the problem is indeed happening. When logged in via a mobile terminal on an IP network, the outside world should always see the same IP address for the mobile terminal. For the user it can be a mobile IP or an IP address asigned when the mobile terminal logged on. If the endpoint changes, the mobile network will change the routing and whatever that is needed for the handover. The user should still remain an IP address that does not change. So SIP should still see the same end point. And for SIP there are no changes at all. So, a requirement for the SIP proxy of the IP-operator should then be that the server has to be able to change the IP-address to the IP-address that the outside world sees the mobile terminal using. (if the IP-address changes during hand-over). I do not know everything about mobile internet. I am also not sure what the current solutions are. I could look it up etc, but I have more things to do. Is this not similar to the SIP-NAT problem, where the internal part of a network has different IP-addresses then the outside part? Maybe I am overlooking a lot of issues. Just my 2 cents. Arnoud van Wijk -----Original Message----- From: hammer michael [mailto:mhammer@cisco.com] Sent: donderdag 5 okt 2000 3:48 To: Brian Stucker; Rohan Mahy; Roy, Radhika R, ALCOO Cc: sip@lists.bell-labs.com Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP Mobility ) All, For the record, I agree with the idea that the lower layers should handle mobility. However, one possibility exists that could take the control out of the hands of the lower layer. I'm not sure if this is the issue we are circling, but let me try to describe what I think could happen. The IP layer can address what happens to the communication end-to-end so long as it is really end-to-end. If a proxy is used to patch together two end-to-end IP streams, then any IP-dependent mechanism would be constrained by its knowledge of what the endpoint is. If only one end-to-end stream is used, then the IP layer should be able to maintain flows to that endpoint even as it moves within a network domain. If movement causes the terminal to relinquish an IP address and get a new one in a new network, registrations at the network layer can reestablish IP identities among communicating parties. Also, that same registration mechanism is how a user or proxy finds the other user to begin with. If a message is not acknowledged, then another location request is needed. However, if the real end-point is hidden behind a proxy using another IP stream, then the proxy is burdened with the responsibility to keep track of the end-points on the two streams. But this would be just two instances of the simple example. So, the problem seems to come down to whether the information on the whereabouts of a user is present or can be obtained by some mechanism on a timely basis should an acknowledgement not be received. I had the impression that this was not a problem. Is it the responsibility of the user to push that information to the proxy, or is it the proxy's responsibility to pull that information from the registrar? Either way, that should not be a problem in the time-scale of a session set-up or release. In a world where the terminal is "always on", the role of SIP may be more attuned to whether the user wants to be reached, not where or how to reach the user. But that digresses into another subject. Mike Hammer At 04:23 PM 10/04/2000 -0500, Brian Stucker wrote: I definitely agree with that sentiment. That was the point of my argument. Do nothing in regards to SIP, and if there's something particular to SIP that needs to be addressed in a layer below SIP, then we should be trying to inject requirements and influence the decisions being made there first. Brian -----Original Message----- From: Rohan Mahy [ mailto:rohan@cisco.com ] Sent: Wednesday, October 04, 2000 3:14 PM To: Roy, Radhika R, ALCOO Cc: Stucker, Brian [RICH2:WI12:EXCH]; sip@lists.bell-labs.com Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP Mobility ) At 10:51 AM 9/29/00 , Roy, Radhika R, ALCOO wrote: >Hi, Brian: > >I guess that your mail has provided some technical inputs: 1. Inter-session >mobility and 2. Intra-session mobility. > >For inter-session mobility, you think that SIP in OK. > >For intra-session mobility, it appears that you are feeling comfortable, as >if, SIP is not designed to do this. > >Let us go to the basic: SIP is a session initiation protocol. It is the >mandate of SIP. So, we like to see that it MUST deal with mobility as well *NO* !! Part of SIPs mandate is *personal* mobility, as a user moves from device to device. Personal mobility is a good, useful thing. However, The SIP charter does *NOT* include solving the problem of a device moving through different layer 2 networks. This is a problem for a layer 3 protocol to solve generically. If Mobile IP doesn't do what we need it to, then lets extend it, fix it, or replace it. thanks, -rohan >because people will use it in mobile environment (for both intra- and >inter-session). > >For inter-session, I guess that there may be some involvement of REGISTER >and re-INVITE messages (because of change in location). > >That's all! > >All works are done in the lower layer and SIP is not involved (for example, >some one in the lower layer will find that the location has been changed, >accordingly the upper layer may take some actions, if needed). > >Hope this will clarify the things. > >Best regards, >Radhika R. Roy >AT&T > >-----Original Message----- >From: Brian Stucker [ mailto:bstucker@nortelnetworks.com ] >Sent: Friday, September 29, 2000 1:19 PM >To: sip@lists.bell-labs.com >Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP Mobility ) > > > >My intent isn't to confuse anyone. Quite the contrary. > >My point is that SIP, as an application, should not be concerned about the >vagaries of the underlying media it's being carried on. All applications >that use IP as a transport are going to have to contend with mobility in the >IP space on the intra-session timescale. So IP should solve the problem >because it's a general problem for IP. > >SIP does enough to handle inter-session mobility (I'm at my desk, I'm at >home), and not impede intra-session mobility. It's just simply not suited >for handling anything else because of the nature of the protocol. Any >intra-session mobility must be handled out-of-band as far as SIP is >concerned, and SIP must not make any requirements that would impede this. > >Again, to use wireless voice calls as an example, even with dedicated >transport links, thousands of pages of standards with CDMA/TDMA, IS-41, SS7, >and TCAP, a mobile switching center doesn't attempt to do what you guys are >talking about. It doesn't update the location of a mobile once it's handed >over to another switch in the location database until after your call has >completed, and the mobile registers on the system it moved into. Why? >Because the mobile could be handed back over to the first system, the >handoff could fail, etc. So they don't even attempt to keep the exact >location of the mobile up to date outside of the original switch until the >mobile is stable again, when the call ends. Instead, all incoming calls go >to the first switch, and that switch knows where to go from there to get the >call completed. > >SIP shouldn't be updating the location database every time a wireless >terminal moves around. Some sort of mobile IP proxy function, should instead >be used that knows how to currently find the terminal in it's mobile-aware >IP space. It should route based on the inbound packet's IP address only, and >not care what the payload data is either. > >That solves the problem for SIP, HTTP, FTP, POP3, RTP, you name it. Why >write an extension to every protocol that uses IP as a transport (and have >it solved, and debugged a million different ways) instead of just fixing the >problem at the IP layer (and have it solved, and debugged one way)? > >Brian Stucker >Nortel Networks > >-----Original Message----- >From: Roy, Radhika R, ALCOO [ mailto:rrroy@att.com < mailto:rrroy@att.com > ] >Sent: Friday, September 29, 2000 11:39 AM >To: hammer michael; Michael Thomas; Henry Sinnreich >Cc: Lewis Karl-QA3387; 'Henning Schulzrinne'; sip@lists.bell-labs.com >Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP >Mobility ) > > >Hi, Everyone: > >The need for addressing mobility is clear and SIP is only one part of the >whole equation. > >Let us not confuse people in the name of Pandora's box or otherwise. > >We have to meet the needs solving problems (not to show our back). > >For the SIP WG, it is the SIP session layer that needs to be addressed, if >it turns out that is a need to do some works. > >Best regards, >Radhika R. Roy >AT&T > >-----Original Message----- >From: hammer michael [ mailto:mhammer@cisco.com < mailto:mhammer@cisco.com > ] > >Sent: Friday, September 29, 2000 1:57 PM >To: Roy, Radhika R, ALCOO; Michael Thomas; Henry Sinnreich >Cc: Lewis Karl-QA3387; 'Henning Schulzrinne'; sip@lists.bell-labs.com >Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP >Mobility ) > > >I think Brian aptly pointed out the Pandora's box you open with "mobility." >That should be sufficient motivation to avoid that type of mobility in SIP. > >We are talking about different timescales, e.g.: per packet, per call, and >per registration. > >I thought your term "discrete" captured the idea that the type of >"mobility" you refer to is of the: call me at the office, then later, call >me at home, I'm here now "mobility." Because mobility conjures up so many >more issues, I like the word "presence" better. Presence management may be >more descriptive that mobility management. > >Mike > > >At 04:11 PM 09/28/2000 -0400, Roy, Radhika R, ALCOO wrote: > >Hi, Mike: > > > >Yes, we will have problems if we do not define the terms accurately. > > > >Let us assume that we are using SIP (RFC 2543) and its session layer as our > > >reference. Location, registration, and session are defined in SIP. > > > >Paging (and probably "path") has not been defined in SIP. I will not argue > >to take this abstraction in the SIP layer for now. > > > >Point of attachment has been used as a generic term to indicate "address of > > >the attachment." If we translate this abstraction in the SIP layer, it will > > >mean the addresses that are being used in the SIP layer (e.g., E.164, IP > >address, etc.). > > > >Now let us examine your points: Presence of a person or terminal, etc. > > > >In the SIP layer, I guess, that the presence of a person on a terminal >needs > >to be abstracted in terms of an "address." If that address is also related > >to the point of attachment, then it will also be related to mobility. > > > >(A person behind the terminal may have another ID to deal with personal > >mobility. Let us not address that personal mobility for now.) > > > >In this way, we can extend our analysis for each layer. > > > >Does this answer your question? > > > >Best regards, > >Radhika R. Roy > >AT&T > > > >-----Original Message----- > >From: hammer michael [ mailto:mhammer@cisco.com < mailto:mhammer@cisco.com > >] > >Sent: Thursday, September 28, 2000 6:29 PM > >To: Roy, Radhika R, ALCOO; Michael Thomas; Henry Sinnreich > >Cc: Lewis Karl-QA3387; 'Henning Schulzrinne'; sip@lists.bell-labs.com > >Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP > >Mobility ) > > > > > >Roy, > > > >I need to be very careful what word I choose. Session connection rather > >than path might have been more appropriate. I believe confusion can occur > >if the type of location, registration, location, paging, etc. is not > >accurately defined. I think that the intent of such services revolves > >about maintaining relationships between certain elements, such as between: > > > >user/application and terminal, > >terminal and network end-point, > >network end-point and link end-point, etc. > > > >The act of "registering" may mean different things at different layers and > >use different mechanisms to accomplish them. The question for me is > >whether these are handled independently or does one mechanism attempt to > >manage multiple associations or would one type of registration trigger > >another type at a different layer? > > > >Would SIP then manage the "presence" of a person on a terminal, where > >something else manages the "presence" of a terminal on the network? > > > >Mike Hammer > > > > > >At 12:28 PM 09/28/2000 -0400, Roy, Radhika R, ALCOO wrote: > > >Hi, Mike: > > > > > >You have made excellent points. In fact, you are in the heart of this > > >problem: How the communications path(s) needs to be established as the > >point > > >of attachment is changed during the contiguous mobility. > > > > > >I personally believe that SIP does not need to be involved to set up the > > >communications path(s) per se. > > > > > >However, SIP needs to be used to set up the session: re-INVITE (to the >new > > >address) may need to be used. > > > > > >In the process, location updates, paging, etc. are also involved. If the > > >location update does not have any impact in the SIP layer, I do not think > > > >that SIP should be aware of any change in the lower layer. For example, > > >mobile IP has the power of providing location transparency of the IP >layer > > >(although it has some problems to meet the performance requirements for >the > > >real-time communications like voice). > > > > > >In addition to IP addresses, there are also transport addresses (e.g., >UDP, > > >TCP) for media. One also needs to be careful how to deal with the TCP > > >connection. IP addresses change, but the TCP connections still remains >the > > >same. An update mechanism needs to be defined. In turn, does it mean that > > > >this updated information may also be propagated to the SIP layer (other > > >members may also provide comments on this) because SIP does have the > > >abstraction of the transport address? > > > > > >I have not yet talked about the link layer. > > > > > >I am not trying to solve the mobility problem here. > > > > > >All I am trying to show: If we try to analyze the situation doing an > > >end-to-end analysis, we can easily see what needs to be done in each >layer. > > >Finally, we can answer the question: Whether or not any new work is >needed > > >in the SIP layer to address both discrete and continuos mobility. > > > > > >But you are right that we MUST keep the involvement of the SIP layer to a > > > >minimal level (if possible, we should avoid it) to address the mobility > > >problem. > > > > > >Best regards, > > >Radhika R. Roy > > >AT&T > > > > > >-----Original Message----- > > >From: hammer michael [ mailto:mhammer@cisco.com >< mailto:mhammer@cisco.com > ] > > >Sent: Thursday, September 28, 2000 2:41 PM > > >To: Roy, Radhika R, ALCOO; Michael Thomas; Henry Sinnreich > > >Cc: Lewis Karl-QA3387; 'Henning Schulzrinne'; sip@lists.bell-labs.com > > >Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP > > >Mobility ) > > > > > > > > >Roy, > > > > > >Your use of the terms "discrete" and "continuous" strike to the heart of > > >the issue. In traditional mobile networks, there is an attempt to move >the > > >stream of media with the terminal as it crosses cell boundaries > > >(continuous). There are many papers related to voice and mobile-IP that > > >address how to move the communications path. > > > > > >The discrete case is more an issue of identification of the presence and > > >availability of recipients and the establishment of communications to > > >them. Because names and addresses denoting physical location are often > > >blurred, in essence, personal mobility involves the creation and deletion > > > >of recipients rather than their movement. > > > > > >As I understand it, SIP does not move existing communications so much as >it > > >destroys existing communications paths and replaces them with new ones. >In > > >that respect, some of the traditional mobility issues such as handover >are > > >avoided, but others, e.g. location updates and paging are still needed. > > > > > >While the telcos reverted to addressing hardware-oriented terminal >mobility > > >in PCS, the softer personal mobility is still open to definition. The >same > > >issues have appeared in the net world and each will need to be solved in > > >their respective layers. > > > > > >Mike > > > > > > > > >At 11:01 AM 09/28/2000 -0400, Roy, Radhika R, ALCOO wrote: > > > >Hi, Mike: > > > > > > > >In fact, this is the precisely the test why SIP should be involved or >to > >be > > > >enhanced to support mobility (discrete + continuos) in the case of >Voice, > > > >chat, IM, messaging, conferencing, games, and others. > > > > > > > >If it is found that SIP does not need to be involved, I do not think >that > > > >anyone will force it to do this. > > > > > > > >By the way, do you not see that how SIP (RFC 2543) has taken care of >many > > > >aspects of users' discrete mobility? Has it not been be an excellent >way > >of > > > >involving SIP to solve a kind of mobility in the first place (what >other > > > >applications like H.323 is yet to support)? > > > > > > > >Along the same line, if people come up with the ideas that it is better > > >to > > > >enhance SIP functionality to support other aspects of mobility (if > > > >alternative solutions are not there or not acceptable), I do not think > >that > > > >we should have any objections. > > > > > > > >Let us keep our mind open and judge each proposal with its own merits. > > > > > > > >Best regards, > > > >Radhika R. Roy > > > >AT&T > > > > > > > >-----Original Message----- > > > >From: Michael Thomas [ mailto:mat@cisco.com < mailto:mat@cisco.com > ] > > > >Sent: Wednesday, September 27, 2000 7:01 PM > > > >To: Henry Sinnreich > > > >Cc: Michael Thomas; Roy, Radhika R, ALCOO; Lewis Karl-QA3387; 'Henning > > > >Schulzrinne'; sip@lists.bell-labs.com > > > >Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP > > > >Mobility ) > > > > > > > > > > > >Henry Sinnreich writes: > > > > > >what seems clear is that there are a > > > > > >number of applications which won't be able to do > > > > > >that for a variety of reasons. > > > > > > > > > > Voice, chat, IM, messaging, conferencing, games, etc., are > > > > > plenty of reasons to justify the SIP approach to mobility. > > > > > > > > But what if you could do all of the same things > > > > and not need to modify or involve SIP and have the > > > > additional gain that things like http worked as well? > > > > > > > > Mike > > > > > > > > > > > > > > Henry > > > > > > > > > > >-----Original Message----- > > > > > >From: sip-admin@lists.bell-labs.com > > > > > >[ mailto:sip-admin@lists.bell-labs.com >< mailto:sip-admin@lists.bell-labs.com > ]On Behalf Of > > > > > >Michael Thomas > > > > > >Sent: Wednesday, September 27, 2000 8:33 PM > > > > > >To: Roy, Radhika R, ALCOO > > > > > >Cc: Michael Thomas; Lewis Karl-QA3387; 'Henning Schulzrinne'; > > > > > >sip@lists.bell-labs.com > > > > > >Subject: RE: [SIP] Attempt at summarizing current SIP > > > > > >drafts (SIP > > > > > >Mobility ) > > > > > > > > > > > > > > > > > > > > > > > >I guess what I'm having a hard time with is the > > > > > >starting point that assumes that SIP based > > > > > >application mobility is Good Thing. While it's > > > > > >clear that many applications *could* design in > > > > > >mobility, what seems clear is that there are a > > > > > >number of applications which won't be able to do > > > > > >that for a variety of reasons. Assuming that those > > > > > >applications are important too, then we're already > > > > > >stuck with needing to solve for the general > > > > > >problem. > > > > > > > > > > > >Starting out with the assumption that Mobile IP > > > > > >addresses the more general problem seems > > > > > >attractive because a good solution with fast > > > > > >handoff that addresses AAA and QoS would solve > > > > > >most of the application layer problems in a > > > > > >general way rather than just a SIP specific > > > > > >way. > > > > > > > > > > > >There also seems to be an implicit assumption in > > > > > >the draft of linkage of SIP to a AAA function. > > > > > >I'm going to guess that it is along the same line > > > > > >of thinking of the DQoS gate controller idea. The > > > > > >problem I have with that is that it is in the end > > > > > >an optimization on the normal RSVP/COPS pull > > > > > >model. However, things that don't fit into that > > > > > >model still have the non-optimized way of doing > > > > > >QoS authorization. That's probably not the fault > > > > > >of this draft, but it does seem to make the entire > > > > > >draft a cart-before-horse situation. > > > > > > > > > > > > Mike > > > > > > > > > > > >Roy, Radhika R, ALCOO writes: > > > > > > > Hi, Mike: > > > > > > > > > > > > > > I guess that SIP, as you rightly pointed out, is > > > > > >dealing with the signaling > > > > > > > mechanism in the application layer. So, SIP does > > > > > >not need to deal with L3 > > > > > > > media path. > > > > > > > > > > > > > > SIP does deal with addresses of the source and > > > > > >destination(s). > > > > > > > > > > > > > > In mobile environment, the point of attachment > > > > > >(i.e., addresses) changes: 1. > > > > > > > Between the sessions (discrete mobility) and 2. > > > > > >During the session > > > > > > > (continuous mobility). > > > > > > > > > > > > > > The problem that is being addressed is: What is the > > > > > >impact in SIP layer due > > > > > > > to these two kinds of mobility. > > > > > > > > > > > > > > I guess that for discrete mobility, SIP has > > > > > >probably addressed most of the > > > > > > > problems (others may also provide comments on this). > > > > > > > > > > > > > > For continuous mobility, there may need (or may > > > > > >not??) some works in the SIP > > > > > > > layer, if any (others may also provide comments). > > > > > > > > > > > > > > However, SIP can only address the mobility related > > > > > >problems in the > > > > > > > application layer. This alone may not be enough to > > > > > >solve all problems > > > > > > > because some L3 and L2 problems may also need to be > > > > > >addressed at the same > > > > > > > time to have the complete solution. > > > > > > > > > > > > > > In any solution, SIP mobility needs to be limited > > > > > >only to the application > > > > > > > layer (not L3, L2, etc.). > > > > > > > > > > > > > > Best regards, > > > > > > > Radhika R. Roy > > > > > > > AT&T > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Michael Thomas [ mailto:mat@cisco.com >< mailto:mat@cisco.com > ] > > > > > > > Sent: Wednesday, September 27, 2000 12:32 PM > > > > > > > To: Lewis Karl-QA3387 > > > > > > > Cc: 'Henning Schulzrinne'; sip@lists.bell-labs.com > > > > > > > Subject: RE: [SIP] Attempt at summarizing current SIP drafts > > > > > > > > > > > > > > > > > > > > > > > > > > > > While I'm more than willing to believe that there > > > > > > > are mobility issues that SIP needs to deal with, > > > > > > > this paper seems to be positing SIP as the means > > > > > > > of initiating data sessions altogether. To my > > > > > > > mind, that's a rather bellheaded way of thinking > > > > > > > about how you do what amounts to L3 admission > > > > > > > control. In fact, the IETF already has an L3 > > > > > > > admission control mechanism: RSVP. RSVP's main > > > > > > > advantage is that it follows actual network > > > > > > > topology. SIP is at a distinct disadvantage since > > > > > > > all it knows about is the signaling path which > > > > > > > in normal circumstances has nothing to do with > > > > > > > the actual data path. > > > > > > > > > > > > > > Maybe I'm misreading this whole paper, but it sure > > > > > > > looks like it to me. If my interpretation is > > > > > > > right, however, I'd like to know if the intention > > > > > > > is to signal the access routers providing the > > > > > > > L2/L3 bits using SIP instead of, say, COPS (or > > > > > > > DIAMETER). If so, I'd say that SIP truly has > > > > > > > arrived at becoming the new millenium's kitchen > > > > > > > sink if this is accepted. > > > > > > > > > > > > > > Mike > > > > > > > > > > > > > > Lewis Karl-QA3387 writes: > > > > > > > > I have just reviewed the Mobility Related drafts > > > > > >and am wondering if > > > > > > > anyone > > > > > > > > is aware of the current status of > > > > > >draft-itsumo-sip -mobility-req-01. In > > > > > > > > particular, several issues were identified such > > > > > >as Mobile IP not being > > > > > > > > sufficient for personal mobility and location > > > > > >services, completing > > > > > > > > registration in less than a few seconds, > > > > > >reconfiguration in milliseconds, > > > > > > > > providing location services, support of inter > > > > > >domain soft-hand and secure > > > > > > > > signaling. Have these issues been addressed or > > > > > >actively being worked? > > > > > > > > > > > > > > > > Karl > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Henning Schulzrinne > > > > > [ mailto:schulzrinne@cs.columbia.edu >< mailto:schulzrinne@cs.columbia.edu > ] > > > > > > > Sent: Monday, September 25, 2000 9:20 AM > > > > > > > To: sip@lists.bell-labs.com > > > > > > > Subject: [SIP] Attempt at summarizing current SIP drafts > > > > > > > > > > > > > > > > > > > > > Given the proliferation of SIP-related drafts, I've > > > > > created a summary of > > > > > > > efforts at > > > > > http://www.cs.columbia.edu/~hgs/sip/drafts.html >< http://www.cs.columbia.edu/~hgs/sip/drafts.html > . This is > > > > > > > known to be incomplete, so I'd appreciate if you could > > > > > send me any > > > > > > > additions or corrections. (Jonathan Rosenberg provided > > > > > some of the text; > > > > > > > any mistakes or misrepresentations are mine.) > > > > > > > > > > > > > > It is fairly clear that there are a large number of drafts > > > > > that have not > > > > > > > changed materially for half a year or more. Maybe it's > > > > > time to have a WG > > > > > > > last call or two or ten... > > > > > > > > > > > > > > Henning > > > > > > > -- > > > > > > > Henning Schulzrinne http://www.cs.columbia.edu/~hgs >< http://www.cs.columbia.edu/~hgs > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > SIP mailing list > > > > > > > SIP@lists.bell-labs.com > > > > > > > http://lists.bell-labs.com/mailman/listinfo/sip >< http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > SIP mailing list > > > > > > > SIP@lists.bell-labs.com > > > > > > > http://lists.bell-labs.com/mailman/listinfo/sip >< http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > SIP mailing list > > > > > > SIP@lists.bell-labs.com > > > > > > http://lists.bell-labs.com/mailman/listinfo/sip >< http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > > > > > > _______________________________________________ > > > > > > SIP mailing list > > > > > > SIP@lists.bell-labs.com > > > > > > http://lists.bell-labs.com/mailman/listinfo/sip >< http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > SIP mailing list > > > > > SIP@lists.bell-labs.com > > > > > http://lists.bell-labs.com/mailman/listinfo/sip >< http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > > > > > > > > > > > >_______________________________________________ > > > >SIP mailing list > > > >SIP@lists.bell-labs.com > > > > http://lists.bell-labs.com/mailman/listinfo/sip >< http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > >_______________________________________________ > > > >SIP mailing list > > > >SIP@lists.bell-labs.com > > > > http://lists.bell-labs.com/mailman/listinfo/sip >< http://lists.bell-labs.com/mailman/listinfo/sip > > > >_______________________________________________ >SIP mailing list >SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip >< http://lists.bell-labs.com/mailman/listinfo/sip > > > >_______________________________________________ >SIP mailing list >SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Oct 5 08:33:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA27527 for ; Thu, 5 Oct 2000 08:33:03 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id ADC064438C; Thu, 5 Oct 2000 07:33:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from kcmso1.proxy.att.com (kcmso1.att.com [192.128.133.69]) by lists.bell-labs.com (Postfix) with ESMTP id D465A4433D for ; Thu, 5 Oct 2000 07:31:59 -0400 (EDT) Received: from njb140r1.ems.att.com ([135.65.202.58]) by kcmso1.proxy.att.com (AT&T IPNS/MSO-2.2) with ESMTP id IAA12496; Thu, 5 Oct 2000 08:31:55 -0400 (EDT) Received: from njb140bh2.ems.att.com by njb140r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2) id IAA23449; Thu, 5 Oct 2000 08:30:33 -0400 (EDT) Received: by njb140bh2.ems.att.com with Internet Mail Service (5.5.2652.35) id ; Thu, 5 Oct 2000 08:31:55 -0400 Message-ID: From: "Roy, Radhika R, ALCOO" To: Lewis Karl-QA3387 , Lewis Karl-QA3387 , Lewis Karl-QA3387 , sip@lists.bell-labs.com Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP Mobility ) MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 5 Oct 2000 08:31:52 -0400 If one likes to use this opportunity for keeping the updated information in the register, let us allow them to use it. -----Original Message----- From: Lewis Karl-QA3387 [mailto:K.Lewis@motorola.com] Sent: Wednesday, October 04, 2000 5:23 PM To: Roy, Radhika R, ALCOO; Lewis Karl-QA3387; Lewis Karl-QA3387; sip@lists.bell-labs.com Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP Mobility ) Are you saying that every time the point of attachment changes a reregister is needed? -----Original Message----- From: Roy, Radhika R, ALCOO [mailto:rrroy@att.com] Sent: Wednesday, October 04, 2000 4:20 PM To: Lewis Karl-QA3387; Lewis Karl-QA3387; sip@lists.bell-labs.com Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP Mobility ) May be several reasons: Register may need to be have the current updated information. Session may need to be established to the right addresses optimizing resources. (Point of attachment may have the abstraction from L1 through L7) -----Original Message----- From: Lewis Karl-QA3387 [mailto:K.Lewis@motorola.com] Sent: Wednesday, October 04, 2000 5:08 PM To: Roy, Radhika R, ALCOO; Lewis Karl-QA3387; sip@lists.bell-labs.com Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP Mobility ) I don't understand why you need to involve SIP if L3 is addressing this issue. For instance, packets can still be routed to the new destination when the point of attachment changes. -----Original Message----- From: Roy, Radhika R, ALCOO [mailto:rrroy@att.com] Sent: Wednesday, October 04, 2000 4:03 PM To: Lewis Karl-QA3387; sip@lists.bell-labs.com Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP Mobility ) I guess that it is needed in L3. I-Ds show that still there may be a need for re-REGISTER and re-INVITE messages in the SIP layer. -----Original Message----- From: Lewis Karl-QA3387 [mailto:K.Lewis@motorola.com] Sent: Wednesday, October 04, 2000 4:57 PM To: sip@lists.bell-labs.com Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP Mobility ) MobileIP is addressing this issue with drafts such as draft-elmalki-mobileip-fast-handoffs-03.txt and draft-soliman-mobileip-hmipv6-01.txt. -----Original Message----- From: Roy, Radhika R, ALCOO [mailto:rrroy@att.com] Sent: Wednesday, October 04, 2000 3:34 PM To: Rohan Mahy Cc: Brian Stucker; sip@lists.bell-labs.com Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP Mobility ) Hi, Rohan: Again, let us go back to the basic: SIP is a session initiation protocol. What needs to be done, if any, in the SIP layer if the point of attachment is changed during the session. Best regards, Radhika R. Roy AT&T -----Original Message----- From: Rohan Mahy [mailto:rohan@cisco.com] Sent: Wednesday, October 04, 2000 4:14 PM To: Roy, Radhika R, ALCOO Cc: Brian Stucker; sip@lists.bell-labs.com Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP Mobility ) At 10:51 AM 9/29/00 , Roy, Radhika R, ALCOO wrote: >Hi, Brian: > >I guess that your mail has provided some technical inputs: 1. Inter-session >mobility and 2. Intra-session mobility. > >For inter-session mobility, you think that SIP in OK. > >For intra-session mobility, it appears that you are feeling comfortable, as >if, SIP is not designed to do this. > >Let us go to the basic: SIP is a session initiation protocol. It is the >mandate of SIP. So, we like to see that it MUST deal with mobility as well *NO* !! Part of SIPs mandate is *personal* mobility, as a user moves from device to device. Personal mobility is a good, useful thing. However, The SIP charter does *NOT* include solving the problem of a device moving through different layer 2 networks. This is a problem for a layer 3 protocol to solve generically. If Mobile IP doesn't do what we need it to, then lets extend it, fix it, or replace it. thanks, -rohan >because people will use it in mobile environment (for both intra- and >inter-session). > >For inter-session, I guess that there may be some involvement of REGISTER >and re-INVITE messages (because of change in location). > >That's all! > >All works are done in the lower layer and SIP is not involved (for example, >some one in the lower layer will find that the location has been changed, >accordingly the upper layer may take some actions, if needed). > >Hope this will clarify the things. > >Best regards, >Radhika R. Roy >AT&T > >-----Original Message----- >From: Brian Stucker [mailto:bstucker@nortelnetworks.com] >Sent: Friday, September 29, 2000 1:19 PM >To: sip@lists.bell-labs.com >Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP Mobility ) > > > >My intent isn't to confuse anyone. Quite the contrary. > >My point is that SIP, as an application, should not be concerned about the >vagaries of the underlying media it's being carried on. All applications >that use IP as a transport are going to have to contend with mobility in the >IP space on the intra-session timescale. So IP should solve the problem >because it's a general problem for IP. > >SIP does enough to handle inter-session mobility (I'm at my desk, I'm at >home), and not impede intra-session mobility. It's just simply not suited >for handling anything else because of the nature of the protocol. Any >intra-session mobility must be handled out-of-band as far as SIP is >concerned, and SIP must not make any requirements that would impede this. > >Again, to use wireless voice calls as an example, even with dedicated >transport links, thousands of pages of standards with CDMA/TDMA, IS-41, SS7, >and TCAP, a mobile switching center doesn't attempt to do what you guys are >talking about. It doesn't update the location of a mobile once it's handed >over to another switch in the location database until after your call has >completed, and the mobile registers on the system it moved into. Why? >Because the mobile could be handed back over to the first system, the >handoff could fail, etc. So they don't even attempt to keep the exact >location of the mobile up to date outside of the original switch until the >mobile is stable again, when the call ends. Instead, all incoming calls go >to the first switch, and that switch knows where to go from there to get the >call completed. > >SIP shouldn't be updating the location database every time a wireless >terminal moves around. Some sort of mobile IP proxy function, should instead >be used that knows how to currently find the terminal in it's mobile-aware >IP space. It should route based on the inbound packet's IP address only, and >not care what the payload data is either. > >That solves the problem for SIP, HTTP, FTP, POP3, RTP, you name it. Why >write an extension to every protocol that uses IP as a transport (and have >it solved, and debugged a million different ways) instead of just fixing the >problem at the IP layer (and have it solved, and debugged one way)? > >Brian Stucker >Nortel Networks > >-----Original Message----- >From: Roy, Radhika R, ALCOO [ mailto:rrroy@att.com ] >Sent: Friday, September 29, 2000 11:39 AM >To: hammer michael; Michael Thomas; Henry Sinnreich >Cc: Lewis Karl-QA3387; 'Henning Schulzrinne'; sip@lists.bell-labs.com >Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP >Mobility ) > > >Hi, Everyone: > >The need for addressing mobility is clear and SIP is only one part of the >whole equation. > >Let us not confuse people in the name of Pandora's box or otherwise. > >We have to meet the needs solving problems (not to show our back). > >For the SIP WG, it is the SIP session layer that needs to be addressed, if >it turns out that is a need to do some works. > >Best regards, >Radhika R. Roy >AT&T > >-----Original Message----- >From: hammer michael [ mailto:mhammer@cisco.com ] > >Sent: Friday, September 29, 2000 1:57 PM >To: Roy, Radhika R, ALCOO; Michael Thomas; Henry Sinnreich >Cc: Lewis Karl-QA3387; 'Henning Schulzrinne'; sip@lists.bell-labs.com >Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP >Mobility ) > > >I think Brian aptly pointed out the Pandora's box you open with "mobility." >That should be sufficient motivation to avoid that type of mobility in SIP. > >We are talking about different timescales, e.g.: per packet, per call, and >per registration. > >I thought your term "discrete" captured the idea that the type of >"mobility" you refer to is of the: call me at the office, then later, call >me at home, I'm here now "mobility." Because mobility conjures up so many >more issues, I like the word "presence" better. Presence management may be >more descriptive that mobility management. > >Mike > > >At 04:11 PM 09/28/2000 -0400, Roy, Radhika R, ALCOO wrote: > >Hi, Mike: > > > >Yes, we will have problems if we do not define the terms accurately. > > > >Let us assume that we are using SIP (RFC 2543) and its session layer as our > > >reference. Location, registration, and session are defined in SIP. > > > >Paging (and probably "path") has not been defined in SIP. I will not argue > >to take this abstraction in the SIP layer for now. > > > >Point of attachment has been used as a generic term to indicate "address of > > >the attachment." If we translate this abstraction in the SIP layer, it will > > >mean the addresses that are being used in the SIP layer (e.g., E.164, IP > >address, etc.). > > > >Now let us examine your points: Presence of a person or terminal, etc. > > > >In the SIP layer, I guess, that the presence of a person on a terminal >needs > >to be abstracted in terms of an "address." If that address is also related > >to the point of attachment, then it will also be related to mobility. > > > >(A person behind the terminal may have another ID to deal with personal > >mobility. Let us not address that personal mobility for now.) > > > >In this way, we can extend our analysis for each layer. > > > >Does this answer your question? > > > >Best regards, > >Radhika R. Roy > >AT&T > > > >-----Original Message----- > >From: hammer michael [ mailto:mhammer@cisco.com >] > >Sent: Thursday, September 28, 2000 6:29 PM > >To: Roy, Radhika R, ALCOO; Michael Thomas; Henry Sinnreich > >Cc: Lewis Karl-QA3387; 'Henning Schulzrinne'; sip@lists.bell-labs.com > >Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP > >Mobility ) > > > > > >Roy, > > > >I need to be very careful what word I choose. Session connection rather > >than path might have been more appropriate. I believe confusion can occur > >if the type of location, registration, location, paging, etc. is not > >accurately defined. I think that the intent of such services revolves > >about maintaining relationships between certain elements, such as between: > > > >user/application and terminal, > >terminal and network end-point, > >network end-point and link end-point, etc. > > > >The act of "registering" may mean different things at different layers and > >use different mechanisms to accomplish them. The question for me is > >whether these are handled independently or does one mechanism attempt to > >manage multiple associations or would one type of registration trigger > >another type at a different layer? > > > >Would SIP then manage the "presence" of a person on a terminal, where > >something else manages the "presence" of a terminal on the network? > > > >Mike Hammer > > > > > >At 12:28 PM 09/28/2000 -0400, Roy, Radhika R, ALCOO wrote: > > >Hi, Mike: > > > > > >You have made excellent points. In fact, you are in the heart of this > > >problem: How the communications path(s) needs to be established as the > >point > > >of attachment is changed during the contiguous mobility. > > > > > >I personally believe that SIP does not need to be involved to set up the > > >communications path(s) per se. > > > > > >However, SIP needs to be used to set up the session: re-INVITE (to the >new > > >address) may need to be used. > > > > > >In the process, location updates, paging, etc. are also involved. If the > > >location update does not have any impact in the SIP layer, I do not think > > > >that SIP should be aware of any change in the lower layer. For example, > > >mobile IP has the power of providing location transparency of the IP >layer > > >(although it has some problems to meet the performance requirements for >the > > >real-time communications like voice). > > > > > >In addition to IP addresses, there are also transport addresses (e.g., >UDP, > > >TCP) for media. One also needs to be careful how to deal with the TCP > > >connection. IP addresses change, but the TCP connections still remains >the > > >same. An update mechanism needs to be defined. In turn, does it mean that > > > >this updated information may also be propagated to the SIP layer (other > > >members may also provide comments on this) because SIP does have the > > >abstraction of the transport address? > > > > > >I have not yet talked about the link layer. > > > > > >I am not trying to solve the mobility problem here. > > > > > >All I am trying to show: If we try to analyze the situation doing an > > >end-to-end analysis, we can easily see what needs to be done in each >layer. > > >Finally, we can answer the question: Whether or not any new work is >needed > > >in the SIP layer to address both discrete and continuos mobility. > > > > > >But you are right that we MUST keep the involvement of the SIP layer to a > > > >minimal level (if possible, we should avoid it) to address the mobility > > >problem. > > > > > >Best regards, > > >Radhika R. Roy > > >AT&T > > > > > >-----Original Message----- > > >From: hammer michael [ mailto:mhammer@cisco.com > ] > > >Sent: Thursday, September 28, 2000 2:41 PM > > >To: Roy, Radhika R, ALCOO; Michael Thomas; Henry Sinnreich > > >Cc: Lewis Karl-QA3387; 'Henning Schulzrinne'; sip@lists.bell-labs.com > > >Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP > > >Mobility ) > > > > > > > > >Roy, > > > > > >Your use of the terms "discrete" and "continuous" strike to the heart of > > >the issue. In traditional mobile networks, there is an attempt to move >the > > >stream of media with the terminal as it crosses cell boundaries > > >(continuous). There are many papers related to voice and mobile-IP that > > >address how to move the communications path. > > > > > >The discrete case is more an issue of identification of the presence and > > >availability of recipients and the establishment of communications to > > >them. Because names and addresses denoting physical location are often > > >blurred, in essence, personal mobility involves the creation and deletion > > > >of recipients rather than their movement. > > > > > >As I understand it, SIP does not move existing communications so much as >it > > >destroys existing communications paths and replaces them with new ones. >In > > >that respect, some of the traditional mobility issues such as handover >are > > >avoided, but others, e.g. location updates and paging are still needed. > > > > > >While the telcos reverted to addressing hardware-oriented terminal >mobility > > >in PCS, the softer personal mobility is still open to definition. The >same > > >issues have appeared in the net world and each will need to be solved in > > >their respective layers. > > > > > >Mike > > > > > > > > >At 11:01 AM 09/28/2000 -0400, Roy, Radhika R, ALCOO wrote: > > > >Hi, Mike: > > > > > > > >In fact, this is the precisely the test why SIP should be involved or >to > >be > > > >enhanced to support mobility (discrete + continuos) in the case of >Voice, > > > >chat, IM, messaging, conferencing, games, and others. > > > > > > > >If it is found that SIP does not need to be involved, I do not think >that > > > >anyone will force it to do this. > > > > > > > >By the way, do you not see that how SIP (RFC 2543) has taken care of >many > > > >aspects of users' discrete mobility? Has it not been be an excellent >way > >of > > > >involving SIP to solve a kind of mobility in the first place (what >other > > > >applications like H.323 is yet to support)? > > > > > > > >Along the same line, if people come up with the ideas that it is better > > >to > > > >enhance SIP functionality to support other aspects of mobility (if > > > >alternative solutions are not there or not acceptable), I do not think > >that > > > >we should have any objections. > > > > > > > >Let us keep our mind open and judge each proposal with its own merits. > > > > > > > >Best regards, > > > >Radhika R. Roy > > > >AT&T > > > > > > > >-----Original Message----- > > > >From: Michael Thomas [ mailto:mat@cisco.com ] > > > >Sent: Wednesday, September 27, 2000 7:01 PM > > > >To: Henry Sinnreich > > > >Cc: Michael Thomas; Roy, Radhika R, ALCOO; Lewis Karl-QA3387; 'Henning > > > >Schulzrinne'; sip@lists.bell-labs.com > > > >Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP > > > >Mobility ) > > > > > > > > > > > >Henry Sinnreich writes: > > > > > >what seems clear is that there are a > > > > > >number of applications which won't be able to do > > > > > >that for a variety of reasons. > > > > > > > > > > Voice, chat, IM, messaging, conferencing, games, etc., are > > > > > plenty of reasons to justify the SIP approach to mobility. > > > > > > > > But what if you could do all of the same things > > > > and not need to modify or involve SIP and have the > > > > additional gain that things like http worked as well? > > > > > > > > Mike > > > > > > > > > > > > > > Henry > > > > > > > > > > >-----Original Message----- > > > > > >From: sip-admin@lists.bell-labs.com > > > > > >[ mailto:sip-admin@lists.bell-labs.com > ]On Behalf Of > > > > > >Michael Thomas > > > > > >Sent: Wednesday, September 27, 2000 8:33 PM > > > > > >To: Roy, Radhika R, ALCOO > > > > > >Cc: Michael Thomas; Lewis Karl-QA3387; 'Henning Schulzrinne'; > > > > > >sip@lists.bell-labs.com > > > > > >Subject: RE: [SIP] Attempt at summarizing current SIP > > > > > >drafts (SIP > > > > > >Mobility ) > > > > > > > > > > > > > > > > > > > > > > > >I guess what I'm having a hard time with is the > > > > > >starting point that assumes that SIP based > > > > > >application mobility is Good Thing. While it's > > > > > >clear that many applications *could* design in > > > > > >mobility, what seems clear is that there are a > > > > > >number of applications which won't be able to do > > > > > >that for a variety of reasons. Assuming that those > > > > > >applications are important too, then we're already > > > > > >stuck with needing to solve for the general > > > > > >problem. > > > > > > > > > > > >Starting out with the assumption that Mobile IP > > > > > >addresses the more general problem seems > > > > > >attractive because a good solution with fast > > > > > >handoff that addresses AAA and QoS would solve > > > > > >most of the application layer problems in a > > > > > >general way rather than just a SIP specific > > > > > >way. > > > > > > > > > > > >There also seems to be an implicit assumption in > > > > > >the draft of linkage of SIP to a AAA function. > > > > > >I'm going to guess that it is along the same line > > > > > >of thinking of the DQoS gate controller idea. The > > > > > >problem I have with that is that it is in the end > > > > > >an optimization on the normal RSVP/COPS pull > > > > > >model. However, things that don't fit into that > > > > > >model still have the non-optimized way of doing > > > > > >QoS authorization. That's probably not the fault > > > > > >of this draft, but it does seem to make the entire > > > > > >draft a cart-before-horse situation. > > > > > > > > > > > > Mike > > > > > > > > > > > >Roy, Radhika R, ALCOO writes: > > > > > > > Hi, Mike: > > > > > > > > > > > > > > I guess that SIP, as you rightly pointed out, is > > > > > >dealing with the signaling > > > > > > > mechanism in the application layer. So, SIP does > > > > > >not need to deal with L3 > > > > > > > media path. > > > > > > > > > > > > > > SIP does deal with addresses of the source and > > > > > >destination(s). > > > > > > > > > > > > > > In mobile environment, the point of attachment > > > > > >(i.e., addresses) changes: 1. > > > > > > > Between the sessions (discrete mobility) and 2. > > > > > >During the session > > > > > > > (continuous mobility). > > > > > > > > > > > > > > The problem that is being addressed is: What is the > > > > > >impact in SIP layer due > > > > > > > to these two kinds of mobility. > > > > > > > > > > > > > > I guess that for discrete mobility, SIP has > > > > > >probably addressed most of the > > > > > > > problems (others may also provide comments on this). > > > > > > > > > > > > > > For continuous mobility, there may need (or may > > > > > >not??) some works in the SIP > > > > > > > layer, if any (others may also provide comments). > > > > > > > > > > > > > > However, SIP can only address the mobility related > > > > > >problems in the > > > > > > > application layer. This alone may not be enough to > > > > > >solve all problems > > > > > > > because some L3 and L2 problems may also need to be > > > > > >addressed at the same > > > > > > > time to have the complete solution. > > > > > > > > > > > > > > In any solution, SIP mobility needs to be limited > > > > > >only to the application > > > > > > > layer (not L3, L2, etc.). > > > > > > > > > > > > > > Best regards, > > > > > > > Radhika R. Roy > > > > > > > AT&T > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Michael Thomas [ mailto:mat@cisco.com > ] > > > > > > > Sent: Wednesday, September 27, 2000 12:32 PM > > > > > > > To: Lewis Karl-QA3387 > > > > > > > Cc: 'Henning Schulzrinne'; sip@lists.bell-labs.com > > > > > > > Subject: RE: [SIP] Attempt at summarizing current SIP drafts > > > > > > > > > > > > > > > > > > > > > > > > > > > > While I'm more than willing to believe that there > > > > > > > are mobility issues that SIP needs to deal with, > > > > > > > this paper seems to be positing SIP as the means > > > > > > > of initiating data sessions altogether. To my > > > > > > > mind, that's a rather bellheaded way of thinking > > > > > > > about how you do what amounts to L3 admission > > > > > > > control. In fact, the IETF already has an L3 > > > > > > > admission control mechanism: RSVP. RSVP's main > > > > > > > advantage is that it follows actual network > > > > > > > topology. SIP is at a distinct disadvantage since > > > > > > > all it knows about is the signaling path which > > > > > > > in normal circumstances has nothing to do with > > > > > > > the actual data path. > > > > > > > > > > > > > > Maybe I'm misreading this whole paper, but it sure > > > > > > > looks like it to me. If my interpretation is > > > > > > > right, however, I'd like to know if the intention > > > > > > > is to signal the access routers providing the > > > > > > > L2/L3 bits using SIP instead of, say, COPS (or > > > > > > > DIAMETER). If so, I'd say that SIP truly has > > > > > > > arrived at becoming the new millenium's kitchen > > > > > > > sink if this is accepted. > > > > > > > > > > > > > > Mike > > > > > > > > > > > > > > Lewis Karl-QA3387 writes: > > > > > > > > I have just reviewed the Mobility Related drafts > > > > > >and am wondering if > > > > > > > anyone > > > > > > > > is aware of the current status of > > > > > >draft-itsumo-sip -mobility-req-01. In > > > > > > > > particular, several issues were identified such > > > > > >as Mobile IP not being > > > > > > > > sufficient for personal mobility and location > > > > > >services, completing > > > > > > > > registration in less than a few seconds, > > > > > >reconfiguration in milliseconds, > > > > > > > > providing location services, support of inter > > > > > >domain soft-hand and secure > > > > > > > > signaling. Have these issues been addressed or > > > > > >actively being worked? > > > > > > > > > > > > > > > > Karl > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Henning Schulzrinne > > > > > [ mailto:schulzrinne@cs.columbia.edu > ] > > > > > > > Sent: Monday, September 25, 2000 9:20 AM > > > > > > > To: sip@lists.bell-labs.com > > > > > > > Subject: [SIP] Attempt at summarizing current SIP drafts > > > > > > > > > > > > > > > > > > > > > Given the proliferation of SIP-related drafts, I've > > > > > created a summary of > > > > > > > efforts at > > > > > http://www.cs.columbia.edu/~hgs/sip/drafts.html > . This is > > > > > > > known to be incomplete, so I'd appreciate if you could > > > > > send me any > > > > > > > additions or corrections. (Jonathan Rosenberg provided > > > > > some of the text; > > > > > > > any mistakes or misrepresentations are mine.) > > > > > > > > > > > > > > It is fairly clear that there are a large number of drafts > > > > > that have not > > > > > > > changed materially for half a year or more. Maybe it's > > > > > time to have a WG > > > > > > > last call or two or ten... > > > > > > > > > > > > > > Henning > > > > > > > -- > > > > > > > Henning Schulzrinne http://www.cs.columbia.edu/~hgs > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > SIP mailing list > > > > > > > SIP@lists.bell-labs.com > > > > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > SIP mailing list > > > > > > > SIP@lists.bell-labs.com > > > > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > SIP mailing list > > > > > > SIP@lists.bell-labs.com > > > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > > > > > > _______________________________________________ > > > > > > SIP mailing list > > > > > > SIP@lists.bell-labs.com > > > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > SIP mailing list > > > > > SIP@lists.bell-labs.com > > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > > > > > > > > > > > >_______________________________________________ > > > >SIP mailing list > > > >SIP@lists.bell-labs.com > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > >_______________________________________________ > > > >SIP mailing list > > > >SIP@lists.bell-labs.com > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > >_______________________________________________ >SIP mailing list >SIP@lists.bell-labs.com >http://lists.bell-labs.com/mailman/listinfo/sip > > > >_______________________________________________ >SIP mailing list >SIP@lists.bell-labs.com >http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Oct 5 09:13:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA28355 for ; Thu, 5 Oct 2000 09:13:02 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B9D6A4433D; Thu, 5 Oct 2000 08:13:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mars.hss.co.in (unknown [202.54.26.197]) by lists.bell-labs.com (Postfix) with ESMTP id 0E0974433A for ; Thu, 5 Oct 2000 08:12:13 -0400 (EDT) Received: from sampark.hss.hns.com (sampark [139.85.229.22]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id e95DCiC21675; Thu, 5 Oct 2000 18:42:44 +0530 (IST) Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 6525696F.0048E741 ; Thu, 5 Oct 2000 18:46:17 +0530 X-Lotus-FromDomain: HSSBLR From: archow@hss.hns.com To: "Roy, Radhika R, ALCOO" Cc: Lewis Karl-QA3387 , sip@lists.bell-labs.com Message-ID: <6525696F.0048E687.00@sampark.hss.hns.com> Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP Mobility ) Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 5 Oct 2000 18:46:15 +0530 Yes- I always liked REGISTER + re-INVITE addressing change of point of attachment. However, I think the basic problem that people had/have with this is that it *may* take too long to propogate. If so, let it be solved more efficiently in lower layers if it can . However, the idea that I can still handle mobility at application level using SIP is equally exciting for me. Just like we handle personal mobility using REGISTER, is there really a problem if we allow a person to do a re-INVITE at application level for dynamic point of att. changes - especially since it does not warrant any changes to existing SIP ? A basic question regarding time: Why exactly do we say that application level re-INV will take too long and that doing it in lower levels is faster ? Is it because the app. level SIP message may traverse more hops ? If so, why cant we make the SIP message traverse the same set of hops as this lower level message would ? Or , is it due to INV-OK-ACK 3 way transaction ? If so, would this be solved if we just used a 2-way re-session establishment which only changes port and IP and not codec for a session ? (probably in this case, there is no real "capability " re-negotiation problems as its only an IP+port change...) Just thinking aloud - am I missing something basic ? Regds Arjun -- Arjun Roychowdhury @ Hughes Software Systems "Roy, Radhika R, ALCOO" on 10/05/2000 06:01:52 PM To: Lewis Karl-QA3387 , Lewis Karl-QA3387 , Lewis Karl-QA3387 , sip@lists.bell-labs.com cc: Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP Mobility ) If one likes to use this opportunity for keeping the updated information in the register, let us allow them to use it. -----Original Message----- From: Lewis Karl-QA3387 [mailto:K.Lewis@motorola.com] Sent: Wednesday, October 04, 2000 5:23 PM To: Roy, Radhika R, ALCOO; Lewis Karl-QA3387; Lewis Karl-QA3387; sip@lists.bell-labs.com Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP Mobility ) _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Oct 5 09:45:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA28924 for ; Thu, 5 Oct 2000 09:45:02 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B32C34438C; Thu, 5 Oct 2000 08:45:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by lists.bell-labs.com (Postfix) with ESMTP id E204B4433A for ; Thu, 5 Oct 2000 08:44:31 -0400 (EDT) Received: from mr4u3.ericy.com (mr4u3.ericy.com [208.237.135.127]) by imr1.ericy.com (8.9.3/8.9.3) with ESMTP id IAA05591; Thu, 5 Oct 2000 08:44:21 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr4u3.ericy.com (8.9.3/8.9.3) with ESMTP id IAA06293; Thu, 5 Oct 2000 08:43:52 -0500 (CDT) 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 IAA17590; Thu, 5 Oct 2000 08:43:52 -0500 (CDT) Received: (from eusadam@localhost) by b04a24.exu.ericsson.se (8.9.1/8.9.1) id IAA01495; Thu, 5 Oct 2000 08:43:51 -0500 (CDT) Message-Id: <200010051343.IAA01495@b04a24.exu.ericsson.se> To: sip-events@egroups.com Cc: sip@lists.bell-labs.com 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 Subject: [SIP] New SUBSCRIBE/NOTIFY draft almost ready Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 5 Oct 2000 08:43:51 -0500 (CDT) Content-Transfer-Encoding: 7bit Since the previous draft has expired, I've been getting a lot of mail asking whether (and when) I plan to re-issue a draft on the SUBSCRIBE/NOTIFY framework. I'm almost done with the newest revision (which takes into account the comments received at and since Pittsburgh), and should have something available next week. Thanks for your patience. -- 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 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Oct 5 10:29:15 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA29776 for ; Thu, 5 Oct 2000 10:29:14 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id EBAB744342; Thu, 5 Oct 2000 09:29:15 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by lists.bell-labs.com (Postfix) with ESMTP id 608164433D for ; Thu, 5 Oct 2000 09:28:23 -0400 (EDT) Received: from esebh12nok.ntc.nokia.com (esebh12nok.ntc.nokia.com [131.228.10.109]) by mgw-x3.nokia.com (8.10.2/8.10.2/Nokia) with ESMTP id e95ESFB03435; Thu, 5 Oct 2000 17:28:15 +0300 (EET DST) Received: from loki.research.nokia.com ([172.21.33.76]) by esebh12nok.ntc.nokia.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.10) id TXNQGTNW; Thu, 5 Oct 2000 17:28:15 +0300 Received: from kurma.research.nokia.com (IDENT:root@kurma.research.nokia.com [172.21.40.103]) by loki.research.nokia.com (8.9.3/8.9.3) with ESMTP id RAA23900; Thu, 5 Oct 2000 17:28:14 +0300 (EETDST) Received: (from ppessi@localhost) by kurma.research.nokia.com (8.9.3/8.9.3) id NAA01214; Thu, 21 Sep 2000 13:38:48 +0300 X-Authentication-Warning: kurma.research.nokia.com: ppessi set sender to Pekka.Pessi@nokia.com using -f To: sip@lists.bell-labs.com Cc: Subject: Re: [SIP] IPv6 addresses in SIP References: <65256961.0016E94F.00@sampark.hss.hns.com> X-face: #V(jdpv[lI!TNUU=2*oh:="#suS*ponXW"yr6G;~L}uZ\JfD\"IG#G{j`hZI;=DmT\H pfDMyJ`i=:M;BM3R.`[>P^ER8+]i From: Pekka Pessi In-Reply-To: "airoy@hss.hns.com"'s message of "Thu, 21 Sep 2000 09:37:35 +0530" Message-ID: Lines: 25 User-Agent: Gnus/5.0806 (Gnus v5.8.6) XEmacs/21.1 (Capitol Reef) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: 21 Sep 2000 13:38:47 +0300 In message <65256961.0016E94F.00@sampark.hss.hns.com> "airoy@hss.hns.com" writes: >Subject: [SIP] IPv6 addresses in SIP > >3) token is re-defined like this: >>token = "[" IPv6address "]" | real-token >>real-token = 1*< any CHAR except CTL's or separators> >>separators = "(" | ")" | "<" | ">" | "@" | > "," | ";" | ":" | "\" | <"> | > "/" | "[" | "]" | "?" | "=" | > "{" | "}" | SP | HT >>This, of course, may break some old implementations. YMMV. >the issue raised here is valid....however breaking the existing definition >of token doesn't seem to be a very good idea as they would affect a number >of other headers where this definition is not really required. Token >definitiion is a rather generic one and used widely across all headers. I first considered also restricting IPv6 addresses only to parameters, too. However, 'token' is used in many places where a domain name/IP address might be used. Perhaps we should use generic-token there and define generic token to include IPv6 addresses? Pekka _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Oct 5 10:57:16 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA00372 for ; Thu, 5 Oct 2000 10:57:14 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5BA0344342; Thu, 5 Oct 2000 09:57:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from smtprch2.nortel.com (smtprch2.nortelnetworks.com [192.135.215.15]) by lists.bell-labs.com (Postfix) with ESMTP id 596AB4433D for ; Thu, 5 Oct 2000 09:56:16 -0400 (EDT) Received: from zrchb200.us.nortel.com (actually zrchb200) by smtprch2.nortel.com; Thu, 5 Oct 2000 09:52:00 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Thu, 5 Oct 2000 09:55:53 -0500 Message-ID: <36FA02BD7083D411BC9E0000F8073E43D05C08@crchy271.us.nortel.com> From: "Brian Stucker" To: archow@hss.hns.com Cc: sip@lists.bell-labs.com Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP Mobility ) MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C02EDC.5AD894C0" X-Orig: Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 5 Oct 2000 09:55:51 -0500 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_01C02EDC.5AD894C0 Content-Type: text/plain; charset="iso-8859-1" Yes, you could emulate end-points changing their IP address by constantly re-REGISTERing and re-INVITEing every time. However, that's an extremely inefficient way of handling intra-session mobility because you're updating the far end as to where you are, when if the lower layer takes care of this (by a method in which the far end doesn't need to be aware that your IP has changed) you'll be much better off. In a mobile network, the problem of IP mobility is going to exist for anything using IP. Also, only the mobile portion of the network necessarily needs to be made cognizant of this. Elements beyond the edge-router of the mobility capable network don't necessarily need to constantly be made aware every time someone's IP changes. That's why I consider SIP a relatively slow protocol for this purpose, because it works by updating nodes that don't necessarily need to be made aware of the change in the IP address. Here's an example: The solution that you are proposing, if we extended it to a voice cell-phone network boils down to this. Every time you move far enough in the network to need to make an underlying media change (a handover, which can happen every few seconds if you're travelling in a car on a busy highway), you want to have your phone to give the yellow pages a new number for you to be listed at; then tell the person at the far end to hang-up, and call you back at this new number. Yeah, it does the job, but it's incredibly inefficient. Also, in a mobile environment, you could potentially be changing locations (and thus potentially IP addresses) at a rate faster than conventional retransmission timer lengths for SIP. So now you run into race conditions that require even more messages to resolve. If you use a re-INVITE, you're also forcing the media change for the RTP stream (in the case of voice) to now be held hostage to however long it takes SIP to setup a new session. What are you going to do with the voice path during the time that the mobile SIP stack figures out it's IP changed, and it needs to setup a new RTP stream? How are you going to solve problems arising from other network issues such as maybe the endpoint only has enough bandwidth for 1 RTP stream at a time. You're requiring him to multicast 2 streams now until you can get the first one torn down (which doesn't matter because all those packets are going to be lost since they're going to the wrong IP now). What are you going to do if we start seeing that RTP packets are getting to the wrong person (you change IPs, and someone else gets your old IP that's in a call and starts receiving your old RTP packets). There are a lot of implications of trying to solve a transport layer issue at the application layer. If you choose to solve the problem in this manner, and you test it in a lab setting, it will likely work most of the time. Maybe all of the time. However, once this hits the field and you start dealing with the low bandwidth environments that air-links generally present us with today, and higher levels of mobility that you will likely find in a deployed network; you're going to run into some serious problems. Brian Stucker Nortel Networks -----Original Message----- From: archow@hss.hns.com [mailto:archow@hss.hns.com] Sent: Thursday, October 05, 2000 8:16 AM To: Roy, Radhika R, ALCOO Cc: Lewis Karl-QA3387; sip@lists.bell-labs.com Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP Mobility ) Yes- I always liked REGISTER + re-INVITE addressing change of point of attachment. However, I think the basic problem that people had/have with this is that it *may* take too long to propogate. If so, let it be solved more efficiently in lower layers if it can . However, the idea that I can still handle mobility at application level using SIP is equally exciting for me. Just like we handle personal mobility using REGISTER, is there really a problem if we allow a person to do a re-INVITE at application level for dynamic point of att. changes - especially since it does not warrant any changes to existing SIP ? A basic question regarding time: Why exactly do we say that application level re-INV will take too long and that doing it in lower levels is faster ? Is it because the app. level SIP message may traverse more hops ? If so, why cant we make the SIP message traverse the same set of hops as this lower level message would ? Or , is it due to INV-OK-ACK 3 way transaction ? If so, would this be solved if we just used a 2-way re-session establishment which only changes port and IP and not codec for a session ? (probably in this case, there is no real "capability " re-negotiation problems as its only an IP+port change...) Just thinking aloud - am I missing something basic ? Regds Arjun -- Arjun Roychowdhury @ Hughes Software Systems "Roy, Radhika R, ALCOO" on 10/05/2000 06:01:52 PM To: Lewis Karl-QA3387 , Lewis Karl-QA3387 , Lewis Karl-QA3387 , sip@lists.bell-labs.com cc: Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP Mobility ) If one likes to use this opportunity for keeping the updated information in the register, let us allow them to use it. -----Original Message----- From: Lewis Karl-QA3387 [mailto:K.Lewis@motorola.com] Sent: Wednesday, October 04, 2000 5:23 PM To: Roy, Radhika R, ALCOO; Lewis Karl-QA3387; Lewis Karl-QA3387; sip@lists.bell-labs.com Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP Mobility ) _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip ------_=_NextPart_001_01C02EDC.5AD894C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [SIP] Attempt at summarizing current SIP drafts (SIP = Mobility )

Yes, you could emulate end-points changing their IP = address by constantly re-REGISTERing and re-INVITEing every time. = However, that's an extremely inefficient way of handling intra-session = mobility because you're updating the far end as to where you are, when = if the lower layer takes care of this (by a method in which the far end = doesn't need to be aware that your IP has changed) you'll be much = better off.

In a mobile network, the problem of IP mobility is = going to exist for anything using IP. Also, only the mobile portion of = the network necessarily needs to be made cognizant of this. Elements = beyond the edge-router of the mobility capable network don't = necessarily need to constantly be made aware every time someone's IP = changes. That's why I consider SIP a relatively slow protocol for this = purpose, because it works by updating nodes that don't necessarily need = to be made aware of the change in the IP address.

Here's an example: The solution that you are = proposing, if we extended it to a voice cell-phone network boils down = to this. Every time you move far enough in the network to need to make = an underlying media change (a handover, which can happen every few = seconds if you're travelling in a car on a busy highway), you want to = have your phone to give the yellow pages a new number for you to be = listed at; then tell the person at the far end to hang-up, and call you = back at this new number. Yeah, it does the job, but it's incredibly = inefficient.

Also, in a mobile environment, you could potentially = be changing locations (and thus potentially IP addresses) at a rate = faster than conventional retransmission timer lengths for SIP. So now = you run into race conditions that require even more messages to = resolve.

If you use a re-INVITE, you're also forcing the media = change for the RTP stream (in the case of voice) to now be held hostage = to however long it takes SIP to setup a new session. What are you going = to do with the voice path during the time that the mobile SIP stack = figures out it's IP changed, and it needs to setup a new RTP stream? = How are you going to solve problems arising from other network issues = such as maybe the endpoint only has enough bandwidth for 1 RTP stream = at a time. You're requiring him to multicast 2 streams now until you = can get the first one torn down (which doesn't matter because all those = packets are going to be lost since they're going to the wrong IP now). = What are you going to do if we start seeing that RTP packets are = getting to the wrong person (you change IPs, and someone else gets your = old IP that's in a call and starts receiving your old RTP packets). = There are a lot of implications of trying to solve a transport layer = issue at the application layer.

If you choose to solve the problem in this manner, = and you test it in a lab setting, it will likely work most of the time. = Maybe all of the time. However, once this hits the field and you start = dealing with the low bandwidth environments that air-links generally = present us with today, and higher levels of mobility that you will = likely find in a deployed network; you're going to run into some = serious problems.

Brian Stucker
Nortel Networks

-----Original Message-----
From: archow@hss.hns.com [mailto:archow@hss.hns.com]=
Sent: Thursday, October 05, 2000 8:16 AM
To: Roy, Radhika R, ALCOO
Cc: Lewis Karl-QA3387; = sip@lists.bell-labs.com
Subject: RE: [SIP] Attempt at summarizing current = SIP drafts (SIP
Mobility )




Yes-
I always liked REGISTER + re-INVITE addressing = change of point of
attachment. However, I think the basic
problem that people had/have with this is that it = *may* take too long to
propogate. If so, let it be solved more
efficiently in lower layers if it can . However, the = idea that I can still
handle mobility at application level using SIP is = equally
exciting for me. Just like we handle personal = mobility using REGISTER, is
there really a problem if we allow a person
to do a re-INVITE at application level for dynamic = point of att. changes -
especially since it does not warrant any changes to = existing SIP ?

A basic question regarding time: Why exactly do we = say that application
level re-INV will take too long and that doing it = in
lower levels is faster ? Is it because the app. = level SIP message may
traverse more hops ? If so, why cant we make
the SIP message traverse the same set of hops as = this lower level message
would ? Or , is it due to INV-OK-ACK 3 way
transaction ? If so, would this be solved if we just = used a 2-way
re-session establishment which only changes port and = IP
and not codec for a session ? (probably in this = case, there is no real
"capability " re-negotiation problems as = its only an IP+port change...)
Just thinking aloud - am I missing something basic = ?

Regds
Arjun

--
Arjun Roychowdhury @ Hughes Software Systems





"Roy, Radhika R, ALCOO" = <rrroy@att.com> on 10/05/2000 06:01:52 PM

To:   Lewis Karl-QA3387 = <K.Lewis@motorola.com>, Lewis Karl-QA3387
      = <K.Lewis@motorola.com>, Lewis Karl-QA3387 = <K.Lewis@motorola.com>,
      = sip@lists.bell-labs.com
cc:

Subject:  RE: [SIP] Attempt at summarizing = current SIP drafts (SIP Mobility
       )




If one likes to use this opportunity for keeping the = updated information in
the register, let us allow them to use it.

-----Original Message-----
From: Lewis Karl-QA3387 [mailto:K.Lewis@motorola.com]
Sent: Wednesday, October 04, 2000 5:23 PM
To: Roy, Radhika R, ALCOO; Lewis Karl-QA3387; Lewis = Karl-QA3387;
sip@lists.bell-labs.com
Subject: RE: [SIP] Attempt at summarizing current = SIP drafts (SIP
Mobility )







_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip

------_=_NextPart_001_01C02EDC.5AD894C0-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Oct 5 11:14:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA00712 for ; Thu, 5 Oct 2000 11:14:02 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2856244411; Thu, 5 Oct 2000 10:14:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ckmso1.proxy.att.com (ckmso1.att.com [12.20.58.69]) by lists.bell-labs.com (Postfix) with ESMTP id 00E5944410 for ; Thu, 5 Oct 2000 10:13:05 -0400 (EDT) Received: from gab200r1.ems.att.com ([135.37.94.32]) by ckmso1.proxy.att.com (AT&T IPNS/MSO-2.2) with ESMTP id LAA03647; Thu, 5 Oct 2000 11:12:57 -0400 (EDT) Received: from njb140bh2.ems.att.com by gab200r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2) id LAA17777; Thu, 5 Oct 2000 11:14:51 -0400 (EDT) Received: by njb140bh2.ems.att.com with Internet Mail Service (5.5.2652.35) id ; Thu, 5 Oct 2000 11:12:48 -0400 Message-ID: From: "Roy, Radhika R, ALCOO" To: Billy Biggs Cc: "Arnoud van Wijk (ELN)" , "'hammer michael'" , Brian Stucker , Rohan Mahy , sip@lists.bell-labs.com Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP Mobility ) MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 5 Oct 2000 11:12:42 -0400 Hi, Billy: I guess that you have answered (i.e., clarified) most of the questions: 1. You are right that no new extension is needed using re-registration and re-INVITE messages. So, people will be allowed to use these procedures. If this is accepted, I assume that a significant milestone has been achieved (by default, SIP becomes a mobility-aware application). Once we accept this basic fact, people can go back to see what additional things need to be done (some I-Ds are there), if any (may need some minor extensions in SIP as well as some I-Ds suggest). 2. Hand-off is an area to see the impact in the SIP session layer. It is primarily the performance aspect of it. (It is inherent problems for all layers in the case of mobility). 3. Some (minor) extensions may be needed as I mentioned in item 1 (some I-Ds have been proposed, but more can be looked into). 4. Logical call flows may not change at all (something similar to call transfer and/or adding a new party in the call during the creation of ad hoc conference call) to take care-of the hand-off situation. 5. It is not whether the idea is good or bad. It is a basic need of the users to address the issues while the point of attachment changes during the SIP session. Best regards, Radhika R. Roy AT&T -----Original Message----- From: Billy Biggs [mailto:Billy_Biggs@3com.com] Sent: Thursday, October 05, 2000 10:37 AM To: Roy, Radhika R, ALCOO Cc: Arnoud van Wijk (ELN); 'hammer michael'; Brian Stucker; Rohan Mahy; sip@lists.bell-labs.com Subject: Re: [SIP] Attempt at summarizing current SIP drafts (SIP Mobility ) Hi Radhika, > The fact of the matter still remains true that the address information > in the register needs to be updated and one may still like to use the > re-INVITE messages to the new addresses. If this solution is > acceptable to anyone, let us allow them to use it. I'm still confused about what you are asking. I don't think anyone is disallowing you to use this mechanism. Are you asking: 1. What extensions to the SIP REGISTER and INVITE transactions are required to support active session mobility? The consensus on this list seems to be that no extensions are required. Please correct me if I am wrong. We've already established that the Contact address can be updated in a re-INVITE, and I believe this is in the bis. If you deployed a system which used this form of mobility, I believe you would have no problems interoperating with others. 2. What technical problems are there with this solution? Many people have mentioned hand-off time as being a factor, I'd estimate having an upper-bound for a successful change to be about half a minute. Another problem would be handling un-succcessful hand-offs: what if the other end does not accept the INVITE? The call would likely be disconnected if the mobile user cannot remain at the old address. 3. What extensions can we propose to solve these problems? Building a mobile-IP phone that updates the session only as an optimization might be worth pursuing. However, I still don't see any work which may lead to extensions to SIP. I think we have everything we need. 4. What is the specific call-flow for a SIP session hand-off? If you're asking "how do I do it", I believe this has come up before on the list, and I would recommend searching the archives. Regardless, this is simply an afternoon research project. 5. Is it a good idea? This is what I believe most people have been answering. As I've mentioned before, I don't think it's a good idea. However, that shouldn't stop you from researching it. -- Billy Biggs Billy_Biggs@3com.com http://www.div8.net/billy/ billy@div8.net _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Oct 5 11:16:24 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA00765 for ; Thu, 5 Oct 2000 11:16:21 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id CBC5344415; Thu, 5 Oct 2000 10:16:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from zrtps06u.us.nortel.com (unknown [47.140.48.52]) by lists.bell-labs.com (Postfix) with ESMTP id 0848A44417 for ; Thu, 5 Oct 2000 10:15:29 -0400 (EDT) Received: from qhars002.nortel.com (zhars00t.europe.nortel.com [47.101.112.102]) by zrtps06u.us.nortel.com (8.11.0/8.11.0) with ESMTP id e95FF4L08976 for ; Thu, 5 Oct 2000 11:15:04 -0400 (EDT) Received: from zhard00m.europe.nortel.com (actually zhard00m) by qhars002.nortel.com; Thu, 5 Oct 2000 11:25:26 +0100 Received: by zhard00m.europe.nortel.com with Internet Mail Service (5.5.2652.35) id <4JRFCS8T>; Thu, 5 Oct 2000 11:25:23 +0100 Message-ID: <61ABD11436FED21192440000F81F3E3604ED7695@nwcwi1a.europe.nortel.com> From: "Joshua Moloney" To: "'Jon.Peterson@Level3.com'" Cc: sip@lists.bell-labs.com Subject: RE: [SIP] SIP ISUP MIME draft MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C02EB6.8EEE6E90" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 5 Oct 2000 11:25:18 +0100 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_01C02EB6.8EEE6E90 Content-Type: text/plain Sorry to barge in, guys. I like the idea of having this new disposition type, and although 'signal' is better than session, I reckon 'signalling' would be better still. Sorry to be picky, but I just can't help it! Josh Moloney Nortel Networks > -----Original Message----- > From: Jon.Peterson@Level3.com [SMTP:Jon.Peterson@Level3.com] > Sent: 05 October 2000 00:58 > To: jdrosen@dynamicsoft.com; achoksi@vovida.com; Ong, Lyndon > Cc: sip@lists.bell-labs.com > Subject: RE: [SIP] SIP ISUP MIME draft > > > Well, 'session' seemed better than any of the other options listed in the > bis, anyway. I suppose 'session' would then refer exclusively to SDP? > > It was be nice if the disposition-type used for ISUP and QSIG could be the > same, and could cover any other encapsulated signals from other protocols > that are used by interworking UAs, at the very least. Perhaps 'signal' as > a > disposition-type? > > Jon Peterson > Level(3) Communications > > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Wednesday, October 04, 2000 5:02 PM > To: Peterson, Jon; 'achoksi@vovida.com'; 'long@nortelnetworks.com' > Cc: 'sip@lists.bell-labs.com' > Subject: RE: [SIP] SIP ISUP MIME draft > > > > > > > -----Original Message----- > > From: Jon.Peterson@Level3.com [mailto:Jon.Peterson@Level3.com] > > Sent: Wednesday, October 04, 2000 3:38 PM > > To: achoksi@vovida.com; long@nortelnetworks.com > > Cc: sip@lists.bell-labs.com > > Subject: RE: [SIP] SIP ISUP MIME draft > > > > > > > > 2. It is optional, but it has a default value as outlined in > > rfc2543 which > > we are not overloading - namely that the content should be > > considered a > > mandatory content (handling=required), and that in requests and 2xx > > responses 'session' is the assumed disposition for > > backwards-compatibility. > > > > However, rfc2543bis-02 also specifies that if the MIME type > > doesn't have a > > default disposition, then the disposition should be assumed > > to be 'render'. > > This seems to conflict with the backwards compatibility > > mechanism described > > above, and someone should probably fix that. I'd vote for > > mainaining the > > latter statute. > > You are right, this seems to be contradictory. I think the former > one is sort of trying to say that the default content disposition > value for SDP is "session". I agree that the latter statute is better. > > > > > > Now, that much said, the ISUP MIME draft today doesn't > > specify a default > > content disposition for the ISUP MIME type. As the bis asks > > MIME types to > > have a default, I think we probably should define one, and I > > think it should > > be 'session' for ISUP. I suppose it would be the same for > > QSIG... Lyndon, > > have any feelings about that? > > No, I don't think session is write. This is not a session description. It > is > describing > extra information used to support signaling interworking. I think a new > content-disposition > makes sense here. > --- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip ------_=_NextPart_001_01C02EB6.8EEE6E90 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [SIP] SIP ISUP MIME draft

Sorry to barge in, = guys. I like the idea of having this new disposition type, and although = 'signal' is better than session, I reckon 'signalling' would be better = still. Sorry to be picky, but I just can't help it!

Josh Moloney
Nortel = Networks

------_=_NextPart_001_01C02EB6.8EEE6E90-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Oct 5 11:22:17 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA00971 for ; Thu, 5 Oct 2000 11:22:15 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7B8DF44423; Thu, 5 Oct 2000 10:20:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from smtprch2.nortel.com (smtprch2.nortelnetworks.com [192.135.215.15]) by lists.bell-labs.com (Postfix) with ESMTP id 88CCF44422 for ; Thu, 5 Oct 2000 10:19:18 -0400 (EDT) Received: from zrchb200.us.nortel.com (actually zrchb200) by smtprch2.nortel.com; Thu, 5 Oct 2000 10:14:58 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Thu, 5 Oct 2000 10:18:54 -0500 Message-ID: <36FA02BD7083D411BC9E0000F8073E43D05C81@crchy271.us.nortel.com> From: "Brian Stucker" To: "Roy, Radhika R, ALCOO" , Billy Biggs Cc: "Arnoud van Wijk (ELN)" , "'hammer michael'" , Rohan Mahy , sip@lists.bell-labs.com Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP Mobility ) MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C02EDF.91664FC0" X-Orig: Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 5 Oct 2000 10:18:51 -0500 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_01C02EDF.91664FC0 Content-Type: text/plain; charset="iso-8859-1" What are you going to do with the media stream during a re-INVITE? How are you going to ensure there is no RTP muting that results from this "solution"? SIP supports fixed length fields as well, but it's not a good idea at all to implement that way. Brian -----Original Message----- From: Roy, Radhika R, ALCOO [mailto:rrroy@att.com] Sent: Thursday, October 05, 2000 10:13 AM To: Billy Biggs Cc: Arnoud van Wijk (ELN); 'hammer michael'; Stucker, Brian [RICH2:WI12:EXCH]; Rohan Mahy; sip@lists.bell-labs.com Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP Mobility ) Hi, Billy: I guess that you have answered (i.e., clarified) most of the questions: 1. You are right that no new extension is needed using re-registration and re-INVITE messages. So, people will be allowed to use these procedures. If this is accepted, I assume that a significant milestone has been achieved (by default, SIP becomes a mobility-aware application). Once we accept this basic fact, people can go back to see what additional things need to be done (some I-Ds are there), if any (may need some minor extensions in SIP as well as some I-Ds suggest). 2. Hand-off is an area to see the impact in the SIP session layer. It is primarily the performance aspect of it. (It is inherent problems for all layers in the case of mobility). 3. Some (minor) extensions may be needed as I mentioned in item 1 (some I-Ds have been proposed, but more can be looked into). 4. Logical call flows may not change at all (something similar to call transfer and/or adding a new party in the call during the creation of ad hoc conference call) to take care-of the hand-off situation. 5. It is not whether the idea is good or bad. It is a basic need of the users to address the issues while the point of attachment changes during the SIP session. Best regards, Radhika R. Roy AT&T -----Original Message----- From: Billy Biggs [mailto:Billy_Biggs@3com.com] Sent: Thursday, October 05, 2000 10:37 AM To: Roy, Radhika R, ALCOO Cc: Arnoud van Wijk (ELN); 'hammer michael'; Brian Stucker; Rohan Mahy; sip@lists.bell-labs.com Subject: Re: [SIP] Attempt at summarizing current SIP drafts (SIP Mobility ) Hi Radhika, > The fact of the matter still remains true that the address information > in the register needs to be updated and one may still like to use the > re-INVITE messages to the new addresses. If this solution is > acceptable to anyone, let us allow them to use it. I'm still confused about what you are asking. I don't think anyone is disallowing you to use this mechanism. Are you asking: 1. What extensions to the SIP REGISTER and INVITE transactions are required to support active session mobility? The consensus on this list seems to be that no extensions are required. Please correct me if I am wrong. We've already established that the Contact address can be updated in a re-INVITE, and I believe this is in the bis. If you deployed a system which used this form of mobility, I believe you would have no problems interoperating with others. 2. What technical problems are there with this solution? Many people have mentioned hand-off time as being a factor, I'd estimate having an upper-bound for a successful change to be about half a minute. Another problem would be handling un-succcessful hand-offs: what if the other end does not accept the INVITE? The call would likely be disconnected if the mobile user cannot remain at the old address. 3. What extensions can we propose to solve these problems? Building a mobile-IP phone that updates the session only as an optimization might be worth pursuing. However, I still don't see any work which may lead to extensions to SIP. I think we have everything we need. 4. What is the specific call-flow for a SIP session hand-off? If you're asking "how do I do it", I believe this has come up before on the list, and I would recommend searching the archives. Regardless, this is simply an afternoon research project. 5. Is it a good idea? This is what I believe most people have been answering. As I've mentioned before, I don't think it's a good idea. However, that shouldn't stop you from researching it. -- Billy Biggs Billy_Biggs@3com.com http://www.div8.net/billy/ billy@div8.net ------_=_NextPart_001_01C02EDF.91664FC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [SIP] Attempt at summarizing current SIP drafts (SIP = Mobility )

What are you going to do with the media stream during = a re-INVITE? How are you going to ensure there is no RTP muting that = results from this "solution"?

SIP supports fixed length fields as well, but it's = not a good idea at all to implement that way.

Brian

-----Original Message-----
From: Roy, Radhika R, ALCOO [mailto:rrroy@att.com]
Sent: Thursday, October 05, 2000 10:13 AM
To: Billy Biggs
Cc: Arnoud van Wijk (ELN); 'hammer michael'; = Stucker, Brian
[RICH2:WI12:EXCH]; Rohan Mahy; = sip@lists.bell-labs.com
Subject: RE: [SIP] Attempt at summarizing current = SIP drafts (SIP
Mobility )


Hi, Billy:

I guess that you have answered (i.e., clarified) most = of the questions:

1. You are right that no new extension is needed = using re-registration and
re-INVITE messages. So, people will be allowed to = use these procedures. If
this is accepted, I assume that a significant = milestone has been achieved
(by default, SIP becomes a mobility-aware = application).

Once we accept this basic fact, people can go back to = see what additional
things need to be done (some I-Ds are there), if any = (may need some minor
extensions in SIP as well as some I-Ds = suggest).

2. Hand-off is an area to see the impact in the SIP = session layer. It is
primarily the performance aspect of it. (It is = inherent problems for all
layers in the case of mobility).

3. Some (minor) extensions may be needed as I = mentioned in item 1 (some I-Ds
have been proposed, but more can be looked = into).

4. Logical call flows may not change at all = (something similar to call
transfer and/or adding a new party in the call = during the creation of ad hoc
conference call) to take care-of the hand-off = situation.

5. It is not whether the idea is good or bad. It is a = basic need of the
users to address the issues while the point of = attachment changes during the
SIP session.

Best regards,
Radhika R. Roy
AT&T

-----Original Message-----
From: Billy Biggs [mailto:Billy_Biggs@3com.com]
Sent: Thursday, October 05, 2000 10:37 AM
To: Roy, Radhika R, ALCOO
Cc: Arnoud van Wijk (ELN); 'hammer michael'; Brian = Stucker; Rohan Mahy;
sip@lists.bell-labs.com
Subject: Re: [SIP] Attempt at summarizing current = SIP drafts (SIP
Mobility )


  Hi Radhika,

> The fact of the matter still remains true that = the address information
> in the register needs to be updated and one may = still like to use the
> re-INVITE messages to the new addresses. If = this solution is
> acceptable to anyone, let us allow them to use = it.

  I'm still confused about what you are = asking.  I don't think anyone is
disallowing you to use this mechanism.

  Are you asking:

  1. What extensions to the SIP REGISTER and = INVITE transactions are
     required to support active = session mobility?

     The consensus on this list = seems to be that no extensions are
     required.  Please = correct me if I am wrong.  We've already
     established that the = Contact address can be updated in a re-INVITE,
     and I believe this is in = the bis.

     If you deployed a system = which used this form of mobility, I
     believe you would have no = problems interoperating with others.

  2. What technical problems are there with this = solution?

     Many people have mentioned = hand-off time as being a factor, I'd
     estimate having an = upper-bound for a successful change to be about
     half a minute.  = Another problem would be handling un-succcessful
     hand-offs: what if the = other end does not accept the INVITE?  The
     call would likely be = disconnected if the mobile user cannot remain
     at the old address.

  3. What extensions can we propose to solve = these problems?

     Building a mobile-IP phone = that updates the session only as an
     optimization might be worth = pursuing.  However, I still don't see
     any work which may lead to = extensions to SIP.  I think we have
     everything we need.

  4. What is the specific call-flow for a SIP = session hand-off?

     If you're asking "how = do I do it", I believe this has come up
     before on the list, and I = would recommend searching the archives.
     Regardless, this is simply = an afternoon research project.

  5. Is it a good idea?

     This is what I believe most = people have been answering.  As I've
     mentioned before, I don't = think it's a good idea.  However, that
     shouldn't stop you from = researching it.

--
Billy = Biggs           &= nbsp;        = Billy_Biggs@3com.com
http://www.div8.net/billy/    =        billy@div8.net

------_=_NextPart_001_01C02EDF.91664FC0-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Oct 5 11:28:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA01137 for ; Thu, 5 Oct 2000 11:28:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4494044428; Thu, 5 Oct 2000 10:20:09 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14]) by lists.bell-labs.com (Postfix) with ESMTP id D5E0A44422 for ; Thu, 5 Oct 2000 10:19:56 -0400 (EDT) Received: from zrchb200.us.nortel.com (actually zrchb200) by smtprch1.nortel.com; Thu, 5 Oct 2000 10:14:02 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Thu, 5 Oct 2000 10:13:54 -0500 Message-ID: <36FA02BD7083D411BC9E0000F8073E43D05C6C@crchy271.us.nortel.com> From: "Brian Stucker" To: hammer michael , Rohan Mahy , "Roy, Radhika R, ALCOO" Cc: sip@lists.bell-labs.com Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP Mobility ) MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C02EDE.DEB4EB70" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 5 Oct 2000 10:13:52 -0500 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_01C02EDE.DEB4EB70 Content-Type: text/plain; charset="iso-8859-1" That's not necessarily true if I understand you correctly. Your SIP proxy would not necessarily have to keep up with what is going on with the endpoint as long as the transport network does the appropriate routing work for anyone trying to address the mobile. You could have a stateless proxy, for instance. The problem isn't so much with SIP as it is the media exchange being setup through SIP (ie. an RTP stream). Brian -----Original Message----- From: hammer michael [mailto:mhammer@cisco.com] Sent: Wednesday, October 04, 2000 8:48 PM To: Stucker, Brian [RICH2:WI12:EXCH]; Rohan Mahy; Roy, Radhika R, ALCOO Cc: sip@lists.bell-labs.com Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP Mobility ) All, For the record, I agree with the idea that the lower layers should handle mobility. However, one possibility exists that could take the control out of the hands of the lower layer. I'm not sure if this is the issue we are circling, but let me try to describe what I think could happen. The IP layer can address what happens to the communication end-to-end so long as it is really end-to-end. If a proxy is used to patch together two end-to-end IP streams, then any IP-dependent mechanism would be constrained by its knowledge of what the endpoint is. If only one end-to-end stream is used, then the IP layer should be able to maintain flows to that endpoint even as it moves within a network domain. If movement causes the terminal to relinquish an IP address and get a new one in a new network, registrations at the network layer can reestablish IP identities among communicating parties. Also, that same registration mechanism is how a user or proxy finds the other user to begin with. If a message is not acknowledged, then another location request is needed. However, if the real end-point is hidden behind a proxy using another IP stream, then the proxy is burdened with the responsibility to keep track of the end-points on the two streams. But this would be just two instances of the simple example. So, the problem seems to come down to whether the information on the whereabouts of a user is present or can be obtained by some mechanism on a timely basis should an acknowledgement not be received. I had the impression that this was not a problem. Is it the responsibility of the user to push that information to the proxy, or is it the proxy's responsibility to pull that information from the registrar? Either way, that should not be a problem in the time-scale of a session set-up or release. In a world where the terminal is "always on", the role of SIP may be more attuned to whether the user wants to be reached, not where or how to reach the user. But that digresses into another subject. Mike Hammer At 04:23 PM 10/04/2000 -0500, Brian Stucker wrote: I definitely agree with that sentiment. That was the point of my argument. Do nothing in regards to SIP, and if there's something particular to SIP that needs to be addressed in a layer below SIP, then we should be trying to inject requirements and influence the decisions being made there first. Brian -----Original Message----- From: Rohan Mahy [ mailto:rohan@cisco.com ] Sent: Wednesday, October 04, 2000 3:14 PM To: Roy, Radhika R, ALCOO Cc: Stucker, Brian [RICH2:WI12:EXCH]; sip@lists.bell-labs.com Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP Mobility ) At 10:51 AM 9/29/00 , Roy, Radhika R, ALCOO wrote: >Hi, Brian: > >I guess that your mail has provided some technical inputs: 1. Inter-session >mobility and 2. Intra-session mobility. > >For inter-session mobility, you think that SIP in OK. > >For intra-session mobility, it appears that you are feeling comfortable, as >if, SIP is not designed to do this. > >Let us go to the basic: SIP is a session initiation protocol. It is the >mandate of SIP. So, we like to see that it MUST deal with mobility as well *NO* !! Part of SIPs mandate is *personal* mobility, as a user moves from device to device. Personal mobility is a good, useful thing. However, The SIP charter does *NOT* include solving the problem of a device moving through different layer 2 networks. This is a problem for a layer 3 protocol to solve generically. If Mobile IP doesn't do what we need it to, then lets extend it, fix it, or replace it. thanks, -rohan >because people will use it in mobile environment (for both intra- and >inter-session). > >For inter-session, I guess that there may be some involvement of REGISTER >and re-INVITE messages (because of change in location). > >That's all! > >All works are done in the lower layer and SIP is not involved (for example, >some one in the lower layer will find that the location has been changed, >accordingly the upper layer may take some actions, if needed). > >Hope this will clarify the things. > >Best regards, >Radhika R. Roy >AT&T > >-----Original Message----- >From: Brian Stucker [ mailto:bstucker@nortelnetworks.com ] >Sent: Friday, September 29, 2000 1:19 PM >To: sip@lists.bell-labs.com >Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP Mobility ) > > > >My intent isn't to confuse anyone. Quite the contrary. > >My point is that SIP, as an application, should not be concerned about the >vagaries of the underlying media it's being carried on. All applications >that use IP as a transport are going to have to contend with mobility in the >IP space on the intra-session timescale. So IP should solve the problem >because it's a general problem for IP. > >SIP does enough to handle inter-session mobility (I'm at my desk, I'm at >home), and not impede intra-session mobility. It's just simply not suited >for handling anything else because of the nature of the protocol. Any >intra-session mobility must be handled out-of-band as far as SIP is >concerned, and SIP must not make any requirements that would impede this. > >Again, to use wireless voice calls as an example, even with dedicated >transport links, thousands of pages of standards with CDMA/TDMA, IS-41, SS7, >and TCAP, a mobile switching center doesn't attempt to do what you guys are >talking about. It doesn't update the location of a mobile once it's handed >over to another switch in the location database until after your call has >completed, and the mobile registers on the system it moved into. Why? >Because the mobile could be handed back over to the first system, the >handoff could fail, etc. So they don't even attempt to keep the exact >location of the mobile up to date outside of the original switch until the >mobile is stable again, when the call ends. Instead, all incoming calls go >to the first switch, and that switch knows where to go from there to get the >call completed. > >SIP shouldn't be updating the location database every time a wireless >terminal moves around. Some sort of mobile IP proxy function, should instead >be used that knows how to currently find the terminal in it's mobile-aware >IP space. It should route based on the inbound packet's IP address only, and >not care what the payload data is either. > >That solves the problem for SIP, HTTP, FTP, POP3, RTP, you name it. Why >write an extension to every protocol that uses IP as a transport (and have >it solved, and debugged a million different ways) instead of just fixing the >problem at the IP layer (and have it solved, and debugged one way)? > >Brian Stucker >Nortel Networks > >-----Original Message----- >From: Roy, Radhika R, ALCOO [ mailto:rrroy@att.com < mailto:rrroy@att.com > ] >Sent: Friday, September 29, 2000 11:39 AM >To: hammer michael; Michael Thomas; Henry Sinnreich >Cc: Lewis Karl-QA3387; 'Henning Schulzrinne'; sip@lists.bell-labs.com >Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP >Mobility ) > > >Hi, Everyone: > >The need for addressing mobility is clear and SIP is only one part of the >whole equation. > >Let us not confuse people in the name of Pandora's box or otherwise. > >We have to meet the needs solving problems (not to show our back). > >For the SIP WG, it is the SIP session layer that needs to be addressed, if >it turns out that is a need to do some works. > >Best regards, >Radhika R. Roy >AT&T > >-----Original Message----- >From: hammer michael [ mailto:mhammer@cisco.com < mailto:mhammer@cisco.com > ] > >Sent: Friday, September 29, 2000 1:57 PM >To: Roy, Radhika R, ALCOO; Michael Thomas; Henry Sinnreich >Cc: Lewis Karl-QA3387; 'Henning Schulzrinne'; sip@lists.bell-labs.com >Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP >Mobility ) > > >I think Brian aptly pointed out the Pandora's box you open with "mobility." >That should be sufficient motivation to avoid that type of mobility in SIP. > >We are talking about different timescales, e.g.: per packet, per call, and >per registration. > >I thought your term "discrete" captured the idea that the type of >"mobility" you refer to is of the: call me at the office, then later, call >me at home, I'm here now "mobility." Because mobility conjures up so many >more issues, I like the word "presence" better. Presence management may be >more descriptive that mobility management. > >Mike > > >At 04:11 PM 09/28/2000 -0400, Roy, Radhika R, ALCOO wrote: > >Hi, Mike: > > > >Yes, we will have problems if we do not define the terms accurately. > > > >Let us assume that we are using SIP (RFC 2543) and its session layer as our > > >reference. Location, registration, and session are defined in SIP. > > > >Paging (and probably "path") has not been defined in SIP. I will not argue > >to take this abstraction in the SIP layer for now. > > > >Point of attachment has been used as a generic term to indicate "address of > > >the attachment." If we translate this abstraction in the SIP layer, it will > > >mean the addresses that are being used in the SIP layer (e.g., E.164, IP > >address, etc.). > > > >Now let us examine your points: Presence of a person or terminal, etc. > > > >In the SIP layer, I guess, that the presence of a person on a terminal >needs > >to be abstracted in terms of an "address." If that address is also related > >to the point of attachment, then it will also be related to mobility. > > > >(A person behind the terminal may have another ID to deal with personal > >mobility. Let us not address that personal mobility for now.) > > > >In this way, we can extend our analysis for each layer. > > > >Does this answer your question? > > > >Best regards, > >Radhika R. Roy > >AT&T > > > >-----Original Message----- > >From: hammer michael [ mailto:mhammer@cisco.com < mailto:mhammer@cisco.com > >] > >Sent: Thursday, September 28, 2000 6:29 PM > >To: Roy, Radhika R, ALCOO; Michael Thomas; Henry Sinnreich > >Cc: Lewis Karl-QA3387; 'Henning Schulzrinne'; sip@lists.bell-labs.com > >Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP > >Mobility ) > > > > > >Roy, > > > >I need to be very careful what word I choose. Session connection rather > >than path might have been more appropriate. I believe confusion can occur > >if the type of location, registration, location, paging, etc. is not > >accurately defined. I think that the intent of such services revolves > >about maintaining relationships between certain elements, such as between: > > > >user/application and terminal, > >terminal and network end-point, > >network end-point and link end-point, etc. > > > >The act of "registering" may mean different things at different layers and > >use different mechanisms to accomplish them. The question for me is > >whether these are handled independently or does one mechanism attempt to > >manage multiple associations or would one type of registration trigger > >another type at a different layer? > > > >Would SIP then manage the "presence" of a person on a terminal, where > >something else manages the "presence" of a terminal on the network? > > > >Mike Hammer > > > > > >At 12:28 PM 09/28/2000 -0400, Roy, Radhika R, ALCOO wrote: > > >Hi, Mike: > > > > > >You have made excellent points. In fact, you are in the heart of this > > >problem: How the communications path(s) needs to be established as the > >point > > >of attachment is changed during the contiguous mobility. > > > > > >I personally believe that SIP does not need to be involved to set up the > > >communications path(s) per se. > > > > > >However, SIP needs to be used to set up the session: re-INVITE (to the >new > > >address) may need to be used. > > > > > >In the process, location updates, paging, etc. are also involved. If the > > >location update does not have any impact in the SIP layer, I do not think > > > >that SIP should be aware of any change in the lower layer. For example, > > >mobile IP has the power of providing location transparency of the IP >layer > > >(although it has some problems to meet the performance requirements for >the > > >real-time communications like voice). > > > > > >In addition to IP addresses, there are also transport addresses (e.g., >UDP, > > >TCP) for media. One also needs to be careful how to deal with the TCP > > >connection. IP addresses change, but the TCP connections still remains >the > > >same. An update mechanism needs to be defined. In turn, does it mean that > > > >this updated information may also be propagated to the SIP layer (other > > >members may also provide comments on this) because SIP does have the > > >abstraction of the transport address? > > > > > >I have not yet talked about the link layer. > > > > > >I am not trying to solve the mobility problem here. > > > > > >All I am trying to show: If we try to analyze the situation doing an > > >end-to-end analysis, we can easily see what needs to be done in each >layer. > > >Finally, we can answer the question: Whether or not any new work is >needed > > >in the SIP layer to address both discrete and continuos mobility. > > > > > >But you are right that we MUST keep the involvement of the SIP layer to a > > > >minimal level (if possible, we should avoid it) to address the mobility > > >problem. > > > > > >Best regards, > > >Radhika R. Roy > > >AT&T > > > > > >-----Original Message----- > > >From: hammer michael [ mailto:mhammer@cisco.com >< mailto:mhammer@cisco.com > ] > > >Sent: Thursday, September 28, 2000 2:41 PM > > >To: Roy, Radhika R, ALCOO; Michael Thomas; Henry Sinnreich > > >Cc: Lewis Karl-QA3387; 'Henning Schulzrinne'; sip@lists.bell-labs.com > > >Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP > > >Mobility ) > > > > > > > > >Roy, > > > > > >Your use of the terms "discrete" and "continuous" strike to the heart of > > >the issue. In traditional mobile networks, there is an attempt to move >the > > >stream of media with the terminal as it crosses cell boundaries > > >(continuous). There are many papers related to voice and mobile-IP that > > >address how to move the communications path. > > > > > >The discrete case is more an issue of identification of the presence and > > >availability of recipients and the establishment of communications to > > >them. Because names and addresses denoting physical location are often > > >blurred, in essence, personal mobility involves the creation and deletion > > > >of recipients rather than their movement. > > > > > >As I understand it, SIP does not move existing communications so much as >it > > >destroys existing communications paths and replaces them with new ones. >In > > >that respect, some of the traditional mobility issues such as handover >are > > >avoided, but others, e.g. location updates and paging are still needed. > > > > > >While the telcos reverted to addressing hardware-oriented terminal >mobility > > >in PCS, the softer personal mobility is still open to definition. The >same > > >issues have appeared in the net world and each will need to be solved in > > >their respective layers. > > > > > >Mike > > > > > > > > >At 11:01 AM 09/28/2000 -0400, Roy, Radhika R, ALCOO wrote: > > > >Hi, Mike: > > > > > > > >In fact, this is the precisely the test why SIP should be involved or >to > >be > > > >enhanced to support mobility (discrete + continuos) in the case of >Voice, > > > >chat, IM, messaging, conferencing, games, and others. > > > > > > > >If it is found that SIP does not need to be involved, I do not think >that > > > >anyone will force it to do this. > > > > > > > >By the way, do you not see that how SIP (RFC 2543) has taken care of >many > > > >aspects of users' discrete mobility? Has it not been be an excellent >way > >of > > > >involving SIP to solve a kind of mobility in the first place (what >other > > > >applications like H.323 is yet to support)? > > > > > > > >Along the same line, if people come up with the ideas that it is better > > >to > > > >enhance SIP functionality to support other aspects of mobility (if > > > >alternative solutions are not there or not acceptable), I do not think > >that > > > >we should have any objections. > > > > > > > >Let us keep our mind open and judge each proposal with its own merits. > > > > > > > >Best regards, > > > >Radhika R. Roy > > > >AT&T > > > > > > > >-----Original Message----- > > > >From: Michael Thomas [ mailto:mat@cisco.com < mailto:mat@cisco.com > ] > > > >Sent: Wednesday, September 27, 2000 7:01 PM > > > >To: Henry Sinnreich > > > >Cc: Michael Thomas; Roy, Radhika R, ALCOO; Lewis Karl-QA3387; 'Henning > > > >Schulzrinne'; sip@lists.bell-labs.com > > > >Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP > > > >Mobility ) > > > > > > > > > > > >Henry Sinnreich writes: > > > > > >what seems clear is that there are a > > > > > >number of applications which won't be able to do > > > > > >that for a variety of reasons. > > > > > > > > > > Voice, chat, IM, messaging, conferencing, games, etc., are > > > > > plenty of reasons to justify the SIP approach to mobility. > > > > > > > > But what if you could do all of the same things > > > > and not need to modify or involve SIP and have the > > > > additional gain that things like http worked as well? > > > > > > > > Mike > > > > > > > > > > > > > > Henry > > > > > > > > > > >-----Original Message----- > > > > > >From: sip-admin@lists.bell-labs.com > > > > > >[ mailto:sip-admin@lists.bell-labs.com >< mailto:sip-admin@lists.bell-labs.com > ]On Behalf Of > > > > > >Michael Thomas > > > > > >Sent: Wednesday, September 27, 2000 8:33 PM > > > > > >To: Roy, Radhika R, ALCOO > > > > > >Cc: Michael Thomas; Lewis Karl-QA3387; 'Henning Schulzrinne'; > > > > > >sip@lists.bell-labs.com > > > > > >Subject: RE: [SIP] Attempt at summarizing current SIP > > > > > >drafts (SIP > > > > > >Mobility ) > > > > > > > > > > > > > > > > > > > > > > > >I guess what I'm having a hard time with is the > > > > > >starting point that assumes that SIP based > > > > > >application mobility is Good Thing. While it's > > > > > >clear that many applications *could* design in > > > > > >mobility, what seems clear is that there are a > > > > > >number of applications which won't be able to do > > > > > >that for a variety of reasons. Assuming that those > > > > > >applications are important too, then we're already > > > > > >stuck with needing to solve for the general > > > > > >problem. > > > > > > > > > > > >Starting out with the assumption that Mobile IP > > > > > >addresses the more general problem seems > > > > > >attractive because a good solution with fast > > > > > >handoff that addresses AAA and QoS would solve > > > > > >most of the application layer problems in a > > > > > >general way rather than just a SIP specific > > > > > >way. > > > > > > > > > > > >There also seems to be an implicit assumption in > > > > > >the draft of linkage of SIP to a AAA function. > > > > > >I'm going to guess that it is along the same line > > > > > >of thinking of the DQoS gate controller idea. The > > > > > >problem I have with that is that it is in the end > > > > > >an optimization on the normal RSVP/COPS pull > > > > > >model. However, things that don't fit into that > > > > > >model still have the non-optimized way of doing > > > > > >QoS authorization. That's probably not the fault > > > > > >of this draft, but it does seem to make the entire > > > > > >draft a cart-before-horse situation. > > > > > > > > > > > > Mike > > > > > > > > > > > >Roy, Radhika R, ALCOO writes: > > > > > > > Hi, Mike: > > > > > > > > > > > > > > I guess that SIP, as you rightly pointed out, is > > > > > >dealing with the signaling > > > > > > > mechanism in the application layer. So, SIP does > > > > > >not need to deal with L3 > > > > > > > media path. > > > > > > > > > > > > > > SIP does deal with addresses of the source and > > > > > >destination(s). > > > > > > > > > > > > > > In mobile environment, the point of attachment > > > > > >(i.e., addresses) changes: 1. > > > > > > > Between the sessions (discrete mobility) and 2. > > > > > >During the session > > > > > > > (continuous mobility). > > > > > > > > > > > > > > The problem that is being addressed is: What is the > > > > > >impact in SIP layer due > > > > > > > to these two kinds of mobility. > > > > > > > > > > > > > > I guess that for discrete mobility, SIP has > > > > > >probably addressed most of the > > > > > > > problems (others may also provide comments on this). > > > > > > > > > > > > > > For continuous mobility, there may need (or may > > > > > >not??) some works in the SIP > > > > > > > layer, if any (others may also provide comments). > > > > > > > > > > > > > > However, SIP can only address the mobility related > > > > > >problems in the > > > > > > > application layer. This alone may not be enough to > > > > > >solve all problems > > > > > > > because some L3 and L2 problems may also need to be > > > > > >addressed at the same > > > > > > > time to have the complete solution. > > > > > > > > > > > > > > In any solution, SIP mobility needs to be limited > > > > > >only to the application > > > > > > > layer (not L3, L2, etc.). > > > > > > > > > > > > > > Best regards, > > > > > > > Radhika R. Roy > > > > > > > AT&T > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Michael Thomas [ mailto:mat@cisco.com >< mailto:mat@cisco.com > ] > > > > > > > Sent: Wednesday, September 27, 2000 12:32 PM > > > > > > > To: Lewis Karl-QA3387 > > > > > > > Cc: 'Henning Schulzrinne'; sip@lists.bell-labs.com > > > > > > > Subject: RE: [SIP] Attempt at summarizing current SIP drafts > > > > > > > > > > > > > > > > > > > > > > > > > > > > While I'm more than willing to believe that there > > > > > > > are mobility issues that SIP needs to deal with, > > > > > > > this paper seems to be positing SIP as the means > > > > > > > of initiating data sessions altogether. To my > > > > > > > mind, that's a rather bellheaded way of thinking > > > > > > > about how you do what amounts to L3 admission > > > > > > > control. In fact, the IETF already has an L3 > > > > > > > admission control mechanism: RSVP. RSVP's main > > > > > > > advantage is that it follows actual network > > > > > > > topology. SIP is at a distinct disadvantage since > > > > > > > all it knows about is the signaling path which > > > > > > > in normal circumstances has nothing to do with > > > > > > > the actual data path. > > > > > > > > > > > > > > Maybe I'm misreading this whole paper, but it sure > > > > > > > looks like it to me. If my interpretation is > > > > > > > right, however, I'd like to know if the intention > > > > > > > is to signal the access routers providing the > > > > > > > L2/L3 bits using SIP instead of, say, COPS (or > > > > > > > DIAMETER). If so, I'd say that SIP truly has > > > > > > > arrived at becoming the new millenium's kitchen > > > > > > > sink if this is accepted. > > > > > > > > > > > > > > Mike > > > > > > > > > > > > > > Lewis Karl-QA3387 writes: > > > > > > > > I have just reviewed the Mobility Related drafts > > > > > >and am wondering if > > > > > > > anyone > > > > > > > > is aware of the current status of > > > > > >draft-itsumo-sip -mobility-req-01. In > > > > > > > > particular, several issues were identified such > > > > > >as Mobile IP not being > > > > > > > > sufficient for personal mobility and location > > > > > >services, completing > > > > > > > > registration in less than a few seconds, > > > > > >reconfiguration in milliseconds, > > > > > > > > providing location services, support of inter > > > > > >domain soft-hand and secure > > > > > > > > signaling. Have these issues been addressed or > > > > > >actively being worked? > > > > > > > > > > > > > > > > Karl > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Henning Schulzrinne > > > > > [ mailto:schulzrinne@cs.columbia.edu >< mailto:schulzrinne@cs.columbia.edu > ] > > > > > > > Sent: Monday, September 25, 2000 9:20 AM > > > > > > > To: sip@lists.bell-labs.com > > > > > > > Subject: [SIP] Attempt at summarizing current SIP drafts > > > > > > > > > > > > > > > > > > > > > Given the proliferation of SIP-related drafts, I've > > > > > created a summary of > > > > > > > efforts at > > > > > http://www.cs.columbia.edu/~hgs/sip/drafts.html >< http://www.cs.columbia.edu/~hgs/sip/drafts.html > . This is > > > > > > > known to be incomplete, so I'd appreciate if you could > > > > > send me any > > > > > > > additions or corrections. (Jonathan Rosenberg provided > > > > > some of the text; > > > > > > > any mistakes or misrepresentations are mine.) > > > > > > > > > > > > > > It is fairly clear that there are a large number of drafts > > > > > that have not > > > > > > > changed materially for half a year or more. Maybe it's > > > > > time to have a WG > > > > > > > last call or two or ten... > > > > > > > > > > > > > > Henning > > > > > > > -- > > > > > > > Henning Schulzrinne http://www.cs.columbia.edu/~hgs >< http://www.cs.columbia.edu/~hgs > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > SIP mailing list > > > > > > > SIP@lists.bell-labs.com > > > > > > > http://lists.bell-labs.com/mailman/listinfo/sip >< http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > SIP mailing list > > > > > > > SIP@lists.bell-labs.com > > > > > > > http://lists.bell-labs.com/mailman/listinfo/sip >< http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > SIP mailing list > > > > > > SIP@lists.bell-labs.com > > > > > > http://lists.bell-labs.com/mailman/listinfo/sip >< http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > > > > > > _______________________________________________ > > > > > > SIP mailing list > > > > > > SIP@lists.bell-labs.com > > > > > > http://lists.bell-labs.com/mailman/listinfo/sip >< http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > SIP mailing list > > > > > SIP@lists.bell-labs.com > > > > > http://lists.bell-labs.com/mailman/listinfo/sip >< http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > > > > > > > > > > > >_______________________________________________ > > > >SIP mailing list > > > >SIP@lists.bell-labs.com > > > > http://lists.bell-labs.com/mailman/listinfo/sip >< http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > >_______________________________________________ > > > >SIP mailing list > > > >SIP@lists.bell-labs.com > > > > http://lists.bell-labs.com/mailman/listinfo/sip >< http://lists.bell-labs.com/mailman/listinfo/sip > > > >_______________________________________________ >SIP mailing list >SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip >< http://lists.bell-labs.com/mailman/listinfo/sip > > > >_______________________________________________ >SIP mailing list >SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip ------_=_NextPart_001_01C02EDE.DEB4EB70 Content-Type: text/html; charset="iso-8859-1"
That's not necessarily true if I understand you correctly. Your SIP proxy would not necessarily have to keep up with what is going on with the endpoint as long as the transport network does the appropriate routing work for anyone trying to address the mobile. You could have a stateless proxy, for instance. The problem isn't so much with SIP as it is the media exchange being setup through SIP (ie. an RTP stream).
 
Brian
-----Original Message-----
From: hammer michael [mailto:mhammer@cisco.com]
Sent: Wednesday, October 04, 2000 8:48 PM
To: Stucker, Brian [RICH2:WI12:EXCH]; Rohan Mahy; Roy, Radhika R, ALCOO
Cc: sip@lists.bell-labs.com
Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP Mobility )

All,

For the record, I agree with the idea that the lower layers should handle mobility.  However, one possibility exists that could take the control out of the hands of the lower layer.  I'm not sure if this is the issue we are circling, but let me try to describe what I think could happen.

The IP layer can address what happens to the communication end-to-end so long as it is really end-to-end.  If a proxy is used to patch together two end-to-end IP streams, then any IP-dependent mechanism would be constrained by its knowledge of what the endpoint is.

If only one end-to-end stream is used, then the IP layer should be able to maintain flows to that endpoint even as it moves within a network domain.  If movement causes the terminal to relinquish an IP address and get a new one in a new network, registrations at the network layer can reestablish IP identities among communicating parties.  Also, that same registration mechanism is how a user or proxy finds the other user to begin with.  If a message is not acknowledged, then another location request is needed.

However, if the real end-point is hidden behind a proxy using another IP stream, then the proxy is burdened with the responsibility to keep track of the end-points on the two streams.  But this would be just two instances of the simple example.

So, the problem seems to come down to whether the information on the whereabouts of a user is present or can be obtained by some mechanism on a timely basis should an acknowledgement not be received.  I had the impression that this was not a problem.

Is it the responsibility of the user to push that information to the proxy, or is it the proxy's responsibility to pull that information from the registrar?  Either way, that should not be a problem in the time-scale of a session set-up or release.

In a world where the terminal is "always on", the role of SIP may be more attuned to whether the user wants to be reached, not where or how to reach the user.  But that digresses into another subject.

Mike Hammer
 


At 04:23 PM 10/04/2000 -0500, Brian Stucker wrote:

I definitely agree with that sentiment. That was the point of my argument. Do nothing in regards to SIP, and if there's something particular to SIP that needs to be addressed in a layer below SIP, then we should be trying to inject requirements and influence the decisions being made there first.

Brian

-----Original Message-----
From: Rohan Mahy [mailto:rohan@cisco.com]
Sent: Wednesday, October 04, 2000 3:14 PM
To: Roy, Radhika R, ALCOO
Cc: Stucker, Brian [RICH2:WI12:EXCH]; sip@lists.bell-labs.com
Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP
Mobility )

At 10:51 AM 9/29/00 , Roy, Radhika R, ALCOO wrote:
>Hi, Brian:
>
>I guess that your mail has provided some technical inputs: 1. Inter-session
>mobility and 2. Intra-session mobility.
>
>For inter-session mobility, you think that SIP in OK.
>
>For intra-session mobility, it appears that you are feeling comfortable, as
>if, SIP is not designed to do this.
>
>Let us go to the basic: SIP is a session initiation protocol. It is the
>mandate of SIP. So, we like to see that it MUST deal with mobility as well

*NO* !!  Part of SIPs mandate is *personal* mobility, as a user moves from
device to device.  Personal mobility is a good, useful thing.  However, The
SIP charter does *NOT* include solving the problem of a device moving
through different layer 2 networks.  This is a problem for a layer 3
protocol to solve generically.  If Mobile IP doesn't do what we need it to,
then lets extend it, fix it, or replace it.

thanks,
-rohan

>because people will use it in mobile environment (for both intra- and
>inter-session).

>
>For inter-session, I guess that there may be some involvement of REGISTER
>and re-INVITE messages (because of change in location).
>
>That's all!
>
>All works are done in the lower layer and SIP is not involved (for example,
>some one in the lower layer will find that the location has been changed,
>accordingly the upper layer may take some actions, if needed).
>
>Hope this will clarify the things.
>
>Best regards,
>Radhika R. Roy
>AT&T
>
>-----Original Message-----
>From: Brian Stucker [mailto:bstucker@nortelnetworks.com]
>Sent: Friday, September 29, 2000 1:19 PM
>To: sip@lists.bell-labs.com
>Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP Mobility )
>
>
>
>My intent isn't to confuse anyone. Quite the contrary.
>
>My point is that SIP, as an application, should not be concerned about the
>vagaries of the underlying media it's being carried on. All applications
>that use IP as a transport are going to have to contend with mobility in the
>IP space on the intra-session timescale. So IP should solve the problem
>because it's a general problem for IP.
>
>SIP does enough to handle inter-session mobility (I'm at my desk, I'm at
>home), and not impede intra-session mobility. It's just simply not suited
>for handling anything else because of the nature of the protocol. Any
>intra-session mobility must be handled out-of-band as far as SIP is
>concerned, and SIP must not make any requirements that would impede this.
>
>Again, to use wireless voice calls as an example, even with dedicated
>transport links, thousands of pages of standards with CDMA/TDMA, IS-41, SS7,
>and TCAP, a mobile switching center doesn't attempt to do what you guys are
>talking about. It doesn't update the location of a mobile once it's handed
>over to another switch in the location database until after your call has
>completed, and the mobile registers on the system it moved into. Why?
>Because the mobile could be handed back over to the first system, the
>handoff could fail, etc. So they don't even attempt to keep the exact
>location of the mobile up to date outside of the original switch until the
>mobile is stable again, when the call ends. Instead, all incoming calls go
>to the first switch, and that switch knows where to go from there to get the
>call completed.
>
>SIP shouldn't be updating the location database every time a wireless
>terminal moves around. Some sort of mobile IP proxy function, should instead
>be used that knows how to currently find the terminal in it's mobile-aware
>IP space. It should route based on the inbound packet's IP address only, and
>not care what the payload data is either.
>
>That solves the problem for SIP, HTTP, FTP, POP3, RTP, you name it. Why
>write an extension to every protocol that uses IP as a transport (and have
>it solved, and debugged a million different ways) instead of just fixing the
>problem at the IP layer (and have it solved, and debugged one way)?
>
>Brian Stucker
>Nortel Networks
>
>-----Original Message-----
>From: Roy, Radhika R, ALCOO [ mailto:rrroy@att.com <mailto:rrroy@att.com> ]
>Sent: Friday, September 29, 2000 11:39 AM
>To: hammer michael; Michael Thomas; Henry Sinnreich
>Cc: Lewis Karl-QA3387; 'Henning Schulzrinne'; sip@lists.bell-labs.com
>Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP
>Mobility )
>
>
>Hi, Everyone:
>
>The need for addressing mobility is clear and SIP is only one part of the
>whole equation.
>
>Let us not confuse people in the name of Pandora's box or otherwise.
>
>We have to meet the needs solving problems (not to show our back).
>
>For the SIP WG, it is the SIP session layer that needs to be addressed, if
>it turns out that is a need to do some works.
>
>Best regards,
>Radhika R. Roy
>AT&T
>
>-----Original Message-----
>From: hammer michael [ mailto:mhammer@cisco.com <mailto:mhammer@cisco.com> ]
>
>Sent: Friday, September 29, 2000 1:57 PM
>To: Roy, Radhika R, ALCOO; Michael Thomas; Henry Sinnreich
>Cc: Lewis Karl-QA3387; 'Henning Schulzrinne'; sip@lists.bell-labs.com
>Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP
>Mobility )
>
>
>I think Brian aptly pointed out the Pandora's box you open with "mobility."
>That should be sufficient motivation to avoid that type of mobility in SIP.
>
>We are talking about different timescales, e.g.:  per packet, per call, and
>per registration.
>
>I thought your term "discrete" captured the idea that the type of
>"mobility" you refer to is of the:  call me at the office, then later, call
>me at home, I'm here now "mobility."  Because mobility conjures up so many
>more issues, I like the word "presence" better.  Presence management may be
>more descriptive that mobility management.
>
>Mike
>
>
>At 04:11 PM 09/28/2000 -0400, Roy, Radhika R, ALCOO wrote:
> >Hi, Mike:
> >
> >Yes, we will have problems if we do not define the terms accurately.
> >
> >Let us assume that we are using SIP (RFC 2543) and its session layer as our
>
> >reference. Location, registration, and session are defined in SIP.
> >
> >Paging (and probably "path") has not been defined in SIP. I will not argue
> >to take this abstraction in the SIP layer for now.
> >
> >Point of attachment has been used as a generic term to indicate "address of
>
> >the attachment." If we translate this abstraction in the SIP layer, it will
>
> >mean the addresses that are being used in the SIP layer (e.g., E.164, IP
> >address, etc.).
> >
> >Now let us examine your points: Presence of a person or terminal, etc.
> >
> >In the SIP layer, I guess, that the presence of a person on a terminal
>needs
> >to be abstracted in terms of an "address." If that address is also related
> >to the point of attachment, then it will also be related to mobility.
> >
> >(A person behind the terminal may have another ID to deal with personal
> >mobility. Let us not address that personal mobility for now.)
> >
> >In this way, we can extend our analysis for each layer.
> >
> >Does this answer your question?
> >
> >Best regards,
> >Radhika R. Roy
> >AT&T
> >
> >-----Original Message-----
> >From: hammer michael [ mailto:mhammer@cisco.com <mailto:mhammer@cisco.com>
>]
> >Sent: Thursday, September 28, 2000 6:29 PM
> >To: Roy, Radhika R, ALCOO; Michael Thomas; Henry Sinnreich
> >Cc: Lewis Karl-QA3387; 'Henning Schulzrinne'; sip@lists.bell-labs.com
> >Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP
> >Mobility )
> >
> >
> >Roy,
> >
> >I need to be very careful what word I choose.  Session connection rather
> >than path might have been more appropriate.  I believe confusion can occur
> >if the type of location, registration, location, paging, etc. is not
> >accurately defined.  I think that the intent of such services revolves
> >about maintaining relationships between certain elements, such as between:
> >
> >user/application and terminal,
> >terminal and network end-point,
> >network end-point and link end-point, etc.
> >
> >The act of "registering" may mean different things at different layers and
> >use different mechanisms to accomplish them.  The question for me is
> >whether these are handled independently or does one mechanism attempt to
> >manage multiple associations or would one type of registration trigger
> >another type at a different layer?
> >
> >Would SIP then manage the "presence" of a person on a terminal, where
> >something else manages the "presence" of a terminal on the network?
> >
> >Mike Hammer
> >
> >
> >At 12:28 PM 09/28/2000 -0400, Roy, Radhika R, ALCOO wrote:
> > >Hi, Mike:
> > >
> > >You have made excellent points. In fact, you are in the heart of this
> > >problem: How the communications path(s) needs to be established as the
> >point
> > >of attachment is changed during the contiguous mobility.
> > >
> > >I personally believe that SIP does not need to be involved to set up the
> > >communications path(s) per se.
> > >
> > >However, SIP needs to be used to set up the session: re-INVITE (to the
>new
> > >address) may need to be used.
> > >
> > >In the process, location updates, paging, etc. are also involved. If the
> > >location update does not have any impact in the SIP layer, I do not think
>
> > >that SIP should be aware of any change in the lower layer. For example,
> > >mobile IP has the power of providing location transparency of the IP
>layer
> > >(although it has some problems to meet the performance requirements for
>the
> > >real-time communications like voice).
> > >
> > >In addition to IP addresses, there are also transport addresses (e.g.,
>UDP,
> > >TCP) for media. One also needs to be careful how to deal with the TCP
> > >connection. IP addresses change, but the TCP connections still remains
>the
> > >same. An update mechanism needs to be defined. In turn, does it mean that
>
> > >this updated information may also be propagated to the SIP layer (other
> > >members may also provide comments on this) because SIP does have the
> > >abstraction of the transport address?
> > >
> > >I have not yet talked about the link layer.
> > >
> > >I am not trying to solve the mobility problem here.
> > >
> > >All I am trying to show: If we try to analyze the situation doing an
> > >end-to-end analysis, we can easily see what needs to be done in each
>layer.
> > >Finally, we can answer the question: Whether or not any new work is
>needed
> > >in the SIP layer to address both discrete and continuos mobility.
> > >
> > >But you are right that we MUST keep the involvement of the SIP layer to a
>
> > >minimal level (if possible, we should avoid it) to address the mobility
> > >problem.
> > >
> > >Best regards,
> > >Radhika R. Roy
> > >AT&T
> > >
> > >-----Original Message-----
> > >From: hammer michael [ mailto:mhammer@cisco.com
><mailto:mhammer@cisco.com> ]
> > >Sent: Thursday, September 28, 2000 2:41 PM
> > >To: Roy, Radhika R, ALCOO; Michael Thomas; Henry Sinnreich
> > >Cc: Lewis Karl-QA3387; 'Henning Schulzrinne'; sip@lists.bell-labs.com
> > >Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP
> > >Mobility )
> > >
> > >
> > >Roy,
> > >
> > >Your use of the terms "discrete" and "continuous" strike to the heart of
> > >the issue.  In traditional mobile networks, there is an attempt to move
>the
> > >stream of media with the terminal as it crosses cell boundaries
> > >(continuous).  There are many papers related to voice and mobile-IP that
> > >address how to move the communications path.
> > >
> > >The discrete case is more an issue of identification of the presence and
> > >availability of recipients and the establishment of communications to
> > >them.  Because names and addresses denoting physical location are often
> > >blurred, in essence, personal mobility involves the creation and deletion
>
> > >of recipients rather than their movement.
> > >
> > >As I understand it, SIP does not move existing communications so much as
>it
> > >destroys existing communications paths and replaces them with new ones.
>In
> > >that respect, some of the traditional mobility issues such as handover
>are
> > >avoided, but others, e.g. location updates and paging are still needed.
> > >
> > >While the telcos reverted to addressing hardware-oriented terminal
>mobility
> > >in PCS, the softer personal mobility is still open to definition.  The
>same
> > >issues have appeared in the net world and each will need to be solved in
> > >their respective layers.
> > >
> > >Mike
> > >
> > >
> > >At 11:01 AM 09/28/2000 -0400, Roy, Radhika R, ALCOO wrote:
> > > >Hi, Mike:
> > > >
> > > >In fact, this is the precisely the test why SIP should be involved or
>to
> >be
> > > >enhanced to support mobility (discrete + continuos) in the case of
>Voice,
> > > >chat, IM, messaging, conferencing, games, and others.
> > > >
> > > >If it is found that SIP does not need to be involved, I do not think
>that
> > > >anyone will force it to do this.
> > > >
> > > >By the way, do you not see that how SIP (RFC 2543) has taken care of
>many
> > > >aspects of users' discrete mobility? Has it not been be an excellent
>way
> >of
> > > >involving SIP to solve a kind of mobility in the first place (what
>other
> > > >applications like H.323 is yet to support)?
> > > >
> > > >Along the same line, if people come up with the ideas that it is better
>
> >to
> > > >enhance SIP functionality to support other aspects of mobility (if
> > > >alternative solutions are not there or not acceptable), I do not think
> >that
> > > >we should have any objections.
> > > >
> > > >Let us keep our mind open and judge each proposal with its own merits.
> > > >
> > > >Best regards,
> > > >Radhika R. Roy
> > > >AT&T
> > > >
> > > >-----Original Message-----
> > > >From: Michael Thomas [ mailto:mat@cisco.com <mailto:mat@cisco.com> ]
> > > >Sent: Wednesday, September 27, 2000 7:01 PM
> > > >To: Henry Sinnreich
> > > >Cc: Michael Thomas; Roy, Radhika R, ALCOO; Lewis Karl-QA3387; 'Henning
> > > >Schulzrinne'; sip@lists.bell-labs.com
> > > >Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP
> > > >Mobility )
> > > >
> > > >
> > > >Henry Sinnreich writes:
> > > >  > >what seems clear is that there are a
> > > >  > >number of applications which won't be able to do
> > > >  > >that for a variety of reasons.
> > > >  >
> > > >  > Voice, chat, IM, messaging, conferencing, games, etc., are
> > > >  > plenty of reasons to justify the SIP approach to mobility.
> > > >
> > > >    But what if you could do all of the same things
> > > >    and not need to modify or involve SIP and have the
> > > >    additional gain that things like http worked as well?
> > > >
> > > >                    Mike
> > > >
> > > >  >
> > > >  > Henry
> > > >  >
> > > >  > >-----Original Message-----
> > > >  > >From: sip-admin@lists.bell-labs.com
> > > >  > >[ mailto:sip-admin@lists.bell-labs.com
><mailto:sip-admin@lists.bell-labs.com> ]On Behalf Of
> > > >  > >Michael Thomas
> > > >  > >Sent: Wednesday, September 27, 2000 8:33 PM
> > > >  > >To: Roy, Radhika R, ALCOO
> > > >  > >Cc: Michael Thomas; Lewis Karl-QA3387; 'Henning Schulzrinne';
> > > >  > >sip@lists.bell-labs.com
> > > >  > >Subject: RE: [SIP] Attempt at summarizing current SIP
> > > >  > >drafts (SIP
> > > >  > >Mobility )
> > > >  > >
> > > >  > >
> > > >  > >
> > > >  > >I guess what I'm having a hard time with is the
> > > >  > >starting point that assumes that SIP based
> > > >  > >application mobility is Good Thing. While it's
> > > >  > >clear that many applications *could* design in
> > > >  > >mobility, what seems clear is that there are a
> > > >  > >number of applications which won't be able to do
> > > >  > >that for a variety of reasons. Assuming that those
> > > >  > >applications are important too, then we're already
> > > >  > >stuck with needing to solve for the general
> > > >  > >problem.
> > > >  > >
> > > >  > >Starting out with the assumption that Mobile IP
> > > >  > >addresses the more general problem seems
> > > >  > >attractive because a good solution with fast
> > > >  > >handoff that addresses AAA and QoS would solve
> > > >  > >most of the application layer problems in a
> > > >  > >general way rather than just a SIP specific
> > > >  > >way.
> > > >  > >
> > > >  > >There also seems to be an implicit assumption in
> > > >  > >the draft of linkage of SIP to a AAA function.
> > > >  > >I'm going to guess that it is along the same line
> > > >  > >of thinking of the DQoS gate controller idea. The
> > > >  > >problem I have with that is that it is in the end
> > > >  > >an optimization on the normal RSVP/COPS pull
> > > >  > >model. However, things that don't fit into that
> > > >  > >model still have the non-optimized way of doing
> > > >  > >QoS authorization. That's probably not the fault
> > > >  > >of this draft, but it does seem to make the entire
> > > >  > >draft a cart-before-horse situation.
> > > >  > >
> > > >  > >    Mike
> > > >  > >
> > > >  > >Roy, Radhika R, ALCOO writes:
> > > >  > > > Hi, Mike:
> > > >  > > >
> > > >  > > > I guess that SIP, as you rightly pointed out, is
> > > >  > >dealing with the signaling
> > > >  > > > mechanism in the application layer. So, SIP does
> > > >  > >not need to deal with L3
> > > >  > > > media path.
> > > >  > > >
> > > >  > > > SIP does deal with addresses of the source and
> > > >  > >destination(s).
> > > >  > > >
> > > >  > > > In mobile environment, the point of attachment
> > > >  > >(i.e., addresses) changes: 1.
> > > >  > > > Between the sessions (discrete mobility) and 2.
> > > >  > >During the session
> > > >  > > > (continuous mobility).
> > > >  > > >
> > > >  > > > The problem that is being addressed is: What is the
> > > >  > >impact in SIP layer due
> > > >  > > > to these two kinds of mobility.
> > > >  > > >
> > > >  > > > I guess that for discrete mobility, SIP has
> > > >  > >probably addressed most of the
> > > >  > > > problems (others may also provide comments on this).
> > > >  > > >
> > > >  > > > For continuous mobility, there may need (or may
> > > >  > >not??) some works in the SIP
> > > >  > > > layer, if any (others may also provide comments).
> > > >  > > >
> > > >  > > > However, SIP can only address the mobility related
> > > >  > >problems in the
> > > >  > > > application layer. This alone may not be enough to
> > > >  > >solve all problems
> > > >  > > > because some L3 and L2 problems may also need to be
> > > >  > >addressed at the same
> > > >  > > > time to have the complete solution.
> > > >  > > >
> > > >  > > > In any solution, SIP mobility needs to be limited
> > > >  > >only to the application
> > > >  > > > layer (not L3, L2, etc.).
> > > >  > > >
> > > >  > > > Best regards,
> > > >  > > > Radhika R. Roy
> > > >  > > > AT&T
> > > >  > > >
> > > >  > > > -----Original Message-----
> > > >  > > > From: Michael Thomas [ mailto:mat@cisco.com
><mailto:mat@cisco.com> ]
> > > >  > > > Sent: Wednesday, September 27, 2000 12:32 PM
> > > >  > > > To: Lewis Karl-QA3387
> > > >  > > > Cc: 'Henning Schulzrinne'; sip@lists.bell-labs.com
> > > >  > > > Subject: RE: [SIP] Attempt at summarizing current SIP drafts
> > > >  > > >
> > > >  > > >
> > > >  > > >
> > > >  > > > While I'm more than willing to believe that there
> > > >  > > > are mobility issues that SIP needs to deal with,
> > > >  > > > this paper seems to be positing SIP as the means
> > > >  > > > of initiating data sessions altogether. To my
> > > >  > > > mind, that's a rather bellheaded way of thinking
> > > >  > > > about how you do what amounts to L3 admission
> > > >  > > > control. In fact, the IETF already has an L3
> > > >  > > > admission control mechanism: RSVP. RSVP's main
> > > >  > > > advantage is that it follows actual network
> > > >  > > > topology. SIP is at a distinct disadvantage since
> > > >  > > > all it knows about is the signaling path which
> > > >  > > > in normal circumstances has nothing to do with
> > > >  > > > the actual data path.
> > > >  > > >
> > > >  > > > Maybe I'm misreading this whole paper, but it sure
> > > >  > > > looks like it to me. If my interpretation is
> > > >  > > > right, however, I'd like to know if the intention
> > > >  > > > is to signal the access routers providing the
> > > >  > > > L2/L3 bits using SIP instead of, say, COPS (or
> > > >  > > > DIAMETER). If so, I'd say that SIP truly has
> > > >  > > > arrived at becoming the new millenium's kitchen
> > > >  > > > sink if this is accepted.
> > > >  > > >
> > > >  > > >    Mike
> > > >  > > >
> > > >  > > > Lewis Karl-QA3387 writes:
> > > >  > > >  > I have just reviewed the Mobility Related drafts
> > > >  > >and am wondering if
> > > >  > > > anyone
> > > >  > > >  > is aware of the current status of
> > > >  > >draft-itsumo-sip -mobility-req-01. In
> > > >  > > >  > particular, several issues were identified such
> > > >  > >as Mobile IP not being
> > > >  > > >  > sufficient for personal mobility and location
> > > >  > >services, completing
> > > >  > > >  > registration in less than a few seconds,
> > > >  > >reconfiguration in milliseconds,
> > > >  > > >  > providing location services, support of inter
> > > >  > >domain soft-hand and secure
> > > >  > > >  > signaling. Have these issues been addressed or
> > > >  > >actively being worked?
> > > >  > > >  >
> > > >  > > >  > Karl
> > > >  > > >  >
> > > >  > > >  >
> > > >  > > >  >
> > > >  > > >  > -----Original Message-----
> > > >  > > >  > From: Henning Schulzrinne
> > > >  > [ mailto:schulzrinne@cs.columbia.edu
><mailto:schulzrinne@cs.columbia.edu> ]
> > > >  >  >  > Sent: Monday, September 25, 2000 9:20 AM
> > > >  >  >  > To: sip@lists.bell-labs.com
> > > >  >  >  > Subject: [SIP] Attempt at summarizing current SIP drafts
> > > >  >  >  >
> > > >  >  >  >
> > > >  >  >  > Given the proliferation of SIP-related drafts, I've
> > > >  > created a summary of
> > > >  >  >  > efforts at
> > > >  > http://www.cs.columbia.edu/~hgs/sip/drafts.html
><http://www.cs.columbia.edu/~hgs/sip/drafts.html> . This is
> > > >  >  >  > known to be incomplete, so I'd appreciate if you could
> > > >  > send me any
> > > >  >  >  > additions or corrections. (Jonathan Rosenberg provided
> > > >  > some of the text;
> > > >  >  >  > any mistakes or misrepresentations are mine.)
> > > >  >  >  >
> > > >  >  >  > It is fairly clear that there are a large number of drafts
> > > >  > that have not
> > > >  >  >  > changed materially for half a year or more. Maybe it's
> > > >  > time to have a WG
> > > >  >  >  > last call or two or ten...
> > > >  >  >  >
> > > >  >  >  > Henning
> > > >  >  >  > --
> > > >  >  >  > Henning Schulzrinne   http://www.cs.columbia.edu/~hgs
><http://www.cs.columbia.edu/~hgs>
> > > >  >  >  >
> > > >  >  >  >
> > > >  >  >  > _______________________________________________
> > > >  >  >  > SIP mailing list
> > > >  >  >  > SIP@lists.bell-labs.com
> > > >  >  >  > http://lists.bell-labs.com/mailman/listinfo/sip
><http://lists.bell-labs.com/mailman/listinfo/sip>
> > > >  >  >  >
> > > >  >  >  > _______________________________________________
> > > >  >  >  > SIP mailing list
> > > >  >  >  > SIP@lists.bell-labs.com
> > > >  >  >  > http://lists.bell-labs.com/mailman/listinfo/sip
><http://lists.bell-labs.com/mailman/listinfo/sip>
> > > >  >  >  >
> > > >  >  >
> > > >  >  > _______________________________________________
> > > >  >  > SIP mailing list
> > > >  >  > SIP@lists.bell-labs.com
> > > >  >  > http://lists.bell-labs.com/mailman/listinfo/sip
><http://lists.bell-labs.com/mailman/listinfo/sip>
> > > >  >  >
> > > >  >  > _______________________________________________
> > > >  >  > SIP mailing list
> > > >  >  > SIP@lists.bell-labs.com
> > > >  >  > http://lists.bell-labs.com/mailman/listinfo/sip
><http://lists.bell-labs.com/mailman/listinfo/sip>
> > > >  >  >
> > > >  >
> > > >  > _______________________________________________
> > > >  > SIP mailing list
> > > >  > SIP@lists.bell-labs.com
> > > >  > http://lists.bell-labs.com/mailman/listinfo/sip
><http://lists.bell-labs.com/mailman/listinfo/sip>
> > > >  >
> > > >  >
> > > >
> > > >_______________________________________________
> > > >SIP mailing list
> > > >SIP@lists.bell-labs.com
> > > > http://lists.bell-labs.com/mailman/listinfo/sip
><http://lists.bell-labs.com/mailman/listinfo/sip>
> > > >
> > > >_______________________________________________
> > > >SIP mailing list
> > > >SIP@lists.bell-labs.com
> > > > http://lists.bell-labs.com/mailman/listinfo/sip
><http://lists.bell-labs.com/mailman/listinfo/sip>
>
>
>_______________________________________________
>SIP mailing list
>SIP@lists.bell-labs.com
>http://lists.bell-labs.com/mailman/listinfo/sip
><http://lists.bell-labs.com/mailman/listinfo/sip>
>
>
>_______________________________________________
>SIP mailing list
>SIP@lists.bell-labs.com
>http://lists.bell-labs.com/mailman/listinfo/sip

------_=_NextPart_001_01C02EDE.DEB4EB70-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Oct 5 11:39:07 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA01420 for ; Thu, 5 Oct 2000 11:39:06 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D2C4A44411; Thu, 5 Oct 2000 10:39:01 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from almso1.proxy.att.com (almso1.att.com [192.128.167.69]) by lists.bell-labs.com (Postfix) with ESMTP id BC1D144342 for ; Thu, 5 Oct 2000 10:38:53 -0400 (EDT) Received: from gab200r1.ems.att.com ([135.37.94.32]) by almso1.proxy.att.com (AT&T IPNS/MSO-2.2) with ESMTP id LAA15109; Thu, 5 Oct 2000 11:38:49 -0400 (EDT) Received: from njb140bh2.ems.att.com by gab200r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2) id LAA15626; Thu, 5 Oct 2000 11:40:52 -0400 (EDT) Received: by njb140bh2.ems.att.com with Internet Mail Service (5.5.2652.35) id ; Thu, 5 Oct 2000 11:38:49 -0400 Message-ID: From: "Roy, Radhika R, ALCOO" To: Brian Stucker , archow@hss.hns.com Cc: sip@lists.bell-labs.com Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP Mobility ) MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 5 Oct 2000 11:38:45 -0400 Hi, Brian: You have nicely summarized the problems that are related to the media re-direction due to the re-INVITE. It is worthwhile to investigate (I believe that the lower layer [e.g., mobile IP] is also not solving this satisfactorily). The conclusion that you may have reached: Low bandwidth vs. High bandwidth network. However, not all wireless networks have low bandwidth (e.g., wireless LANs, etc. are exceptions). The other thing is that not all hand-offs reach to the SIP layer. The things that we may need to address are as follows: 1. Let there be a general procedure in the SIP layer to deal with mobility. 2. There may be some performance problems when it is implemented in certain networking conditions. Let people address this case by case basis. Best regards, Radhika R. Roy AT&T -----Original Message----- From: Brian Stucker [mailto:bstucker@nortelnetworks.com] Sent: Thursday, October 05, 2000 10:56 AM To: archow@hss.hns.com Cc: sip@lists.bell-labs.com Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP Mobility ) Yes, you could emulate end-points changing their IP address by constantly re-REGISTERing and re-INVITEing every time. However, that's an extremely inefficient way of handling intra-session mobility because you're updating the far end as to where you are, when if the lower layer takes care of this (by a method in which the far end doesn't need to be aware that your IP has changed) you'll be much better off. In a mobile network, the problem of IP mobility is going to exist for anything using IP. Also, only the mobile portion of the network necessarily needs to be made cognizant of this. Elements beyond the edge-router of the mobility capable network don't necessarily need to constantly be made aware every time someone's IP changes. That's why I consider SIP a relatively slow protocol for this purpose, because it works by updating nodes that don't necessarily need to be made aware of the change in the IP address. Here's an example: The solution that you are proposing, if we extended it to a voice cell-phone network boils down to this. Every time you move far enough in the network to need to make an underlying media change (a handover, which can happen every few seconds if you're travelling in a car on a busy highway), you want to have your phone to give the yellow pages a new number for you to be listed at; then tell the person at the far end to hang-up, and call you back at this new number. Yeah, it does the job, but it's incredibly inefficient. Also, in a mobile environment, you could potentially be changing locations (and thus potentially IP addresses) at a rate faster than conventional retransmission timer lengths for SIP. So now you run into race conditions that require even more messages to resolve. If you use a re-INVITE, you're also forcing the media change for the RTP stream (in the case of voice) to now be held hostage to however long it takes SIP to setup a new session. What are you going to do with the voice path during the time that the mobile SIP stack figures out it's IP changed, and it needs to setup a new RTP stream? How are you going to solve problems arising from other network issues such as maybe the endpoint only has enough bandwidth for 1 RTP stream at a time. You're requiring him to multicast 2 streams now until you can get the first one torn down (which doesn't matter because all those packets are going to be lost since they're going to the wrong IP now). What are you going to do if we start seeing that RTP packets are getting to the wrong person (you change IPs, and someone else gets your old IP that's in a call and starts receiving your old RTP packets). There are a lot of implications of trying to solve a transport layer issue at the application layer. If you choose to solve the problem in this manner, and you test it in a lab setting, it will likely work most of the time. Maybe all of the time. However, once this hits the field and you start dealing with the low bandwidth environments that air-links generally present us with today, and higher levels of mobility that you will likely find in a deployed network; you're going to run into some serious problems. Brian Stucker Nortel Networks -----Original Message----- From: archow@hss.hns.com [ mailto:archow@hss.hns.com ] Sent: Thursday, October 05, 2000 8:16 AM To: Roy, Radhika R, ALCOO Cc: Lewis Karl-QA3387; sip@lists.bell-labs.com Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP Mobility ) Yes- I always liked REGISTER + re-INVITE addressing change of point of attachment. However, I think the basic problem that people had/have with this is that it *may* take too long to propogate. If so, let it be solved more efficiently in lower layers if it can . However, the idea that I can still handle mobility at application level using SIP is equally exciting for me. Just like we handle personal mobility using REGISTER, is there really a problem if we allow a person to do a re-INVITE at application level for dynamic point of att. changes - especially since it does not warrant any changes to existing SIP ? A basic question regarding time: Why exactly do we say that application level re-INV will take too long and that doing it in lower levels is faster ? Is it because the app. level SIP message may traverse more hops ? If so, why cant we make the SIP message traverse the same set of hops as this lower level message would ? Or , is it due to INV-OK-ACK 3 way transaction ? If so, would this be solved if we just used a 2-way re-session establishment which only changes port and IP and not codec for a session ? (probably in this case, there is no real "capability " re-negotiation problems as its only an IP+port change...) Just thinking aloud - am I missing something basic ? Regds Arjun -- Arjun Roychowdhury @ Hughes Software Systems "Roy, Radhika R, ALCOO" on 10/05/2000 06:01:52 PM To: Lewis Karl-QA3387 , Lewis Karl-QA3387 , Lewis Karl-QA3387 , sip@lists.bell-labs.com cc: Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP Mobility ) If one likes to use this opportunity for keeping the updated information in the register, let us allow them to use it. -----Original Message----- From: Lewis Karl-QA3387 [ mailto:K.Lewis@motorola.com ] Sent: Wednesday, October 04, 2000 5:23 PM To: Roy, Radhika R, ALCOO; Lewis Karl-QA3387; Lewis Karl-QA3387; sip@lists.bell-labs.com Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP Mobility ) _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Oct 5 11:45:36 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA01596 for ; Thu, 5 Oct 2000 11:45:35 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id BB7844442C; Thu, 5 Oct 2000 10:43:01 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 678944442C for ; Thu, 5 Oct 2000 10:42:12 -0400 (EDT) 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 LAA19700; Thu, 5 Oct 2000 11:41:23 -0400 (EDT) Message-ID: <39DCA123.57DBBE3E@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "Roy, Radhika R, ALCOO" Cc: Billy Biggs , "Arnoud van Wijk (ELN)" , "'hammer michael'" , Brian Stucker , Rohan Mahy , sip@lists.bell-labs.com Subject: Re: [SIP] Attempt at summarizing current SIP drafts (SIP Mobility) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 05 Oct 2000 11:41:23 -0400 Content-Transfer-Encoding: 7bit I don't want to wade too deeply into this discussion, but just note that in many of today's networks, we don't have inter-network mobility between calls. Try asking your local ISP to give you a permanent IP address and run a HA for you... Permanent device IPv6 addresses will presumably be used in 3GPP, so that's not a real deep concern there. In general, from an efficiency perspective, mobile IP, as available today (as opposed to the micro-mobility proposals, which are significantly better), has equivalent or worse update latencies, as any binding updates go to from the MH to the HA and then to the CH, even ssuming that the correspondent host supports binding updates (no common OS do, as far as I know). Thus, I believe that for low-latency audio, mobile IPv4, as currently (barely) available, is not good enough and application-layer mobility can do better. That is likely to be a transient situation, however. Even in the longer-run, if we want hand-offs between two non-cooperating networks (e.g., a UMTS network and my university network), there may well be a role, by necessity and as a fallback solution, for application-layer mobility. As long as you can keep your same IP address (modulo the current practical IPv4 mobility problems), I would use IP mobility, for generality. If that's not an option, it's nice to know that SIP can help out to at least keep your voice or video call up, even if you need to restart your web browser and if your telnet connection goes dead. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Oct 5 12:37:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA02789 for ; Thu, 5 Oct 2000 12:37:04 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 111F544342; Thu, 5 Oct 2000 11:37:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cybertron.div8.net (el05-24-131-150-91.ce.mediaone.net [24.131.150.91]) by lists.bell-labs.com (Postfix) with ESMTP id E6A3B4433D for ; Thu, 5 Oct 2000 09:36:51 -0400 (EDT) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for sip@lists.bell-labs.com; Thu, 5 Oct 2000 09:36:30 -0500 (CDT) From: Billy Biggs To: "Roy, Radhika R, ALCOO" Cc: "Arnoud van Wijk (ELN)" , "'hammer michael'" , Brian Stucker , Rohan Mahy , sip@lists.bell-labs.com Subject: Re: [SIP] Attempt at summarizing current SIP drafts (SIP Mobility ) Message-ID: <20001005093630.A31662@div8.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i In-Reply-To: ; from rrroy@att.com on Thu, Oct 05, 2000 at 08:29:27AM -0400 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 5 Oct 2000 09:36:30 -0500 Hi Radhika, > The fact of the matter still remains true that the address information > in the register needs to be updated and one may still like to use the > re-INVITE messages to the new addresses. If this solution is > acceptable to anyone, let us allow them to use it. I'm still confused about what you are asking. I don't think anyone is disallowing you to use this mechanism. Are you asking: 1. What extensions to the SIP REGISTER and INVITE transactions are required to support active session mobility? The consensus on this list seems to be that no extensions are required. Please correct me if I am wrong. We've already established that the Contact address can be updated in a re-INVITE, and I believe this is in the bis. If you deployed a system which used this form of mobility, I believe you would have no problems interoperating with others. 2. What technical problems are there with this solution? Many people have mentioned hand-off time as being a factor, I'd estimate having an upper-bound for a successful change to be about half a minute. Another problem would be handling un-succcessful hand-offs: what if the other end does not accept the INVITE? The call would likely be disconnected if the mobile user cannot remain at the old address. 3. What extensions can we propose to solve these problems? Building a mobile-IP phone that updates the session only as an optimization might be worth pursuing. However, I still don't see any work which may lead to extensions to SIP. I think we have everything we need. 4. What is the specific call-flow for a SIP session hand-off? If you're asking "how do I do it", I believe this has come up before on the list, and I would recommend searching the archives. Regardless, this is simply an afternoon research project. 5. Is it a good idea? This is what I believe most people have been answering. As I've mentioned before, I don't think it's a good idea. However, that shouldn't stop you from researching it. -- Billy Biggs Billy_Biggs@3com.com http://www.div8.net/billy/ billy@div8.net _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Oct 5 12:38:37 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA02850 for ; Thu, 5 Oct 2000 12:38:36 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3679E44420; Thu, 5 Oct 2000 11:37:14 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cybertron.div8.net (el05-24-131-150-91.ce.mediaone.net [24.131.150.91]) by lists.bell-labs.com (Postfix) with ESMTP id 68B324433D for ; Thu, 5 Oct 2000 09:47:16 -0400 (EDT) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for sip@lists.bell-labs.com; Thu, 5 Oct 2000 09:46:39 -0500 (CDT) From: Billy Biggs To: Henning Schulzrinne Cc: Simon Barber , Jonathan Rosenberg , "'hammer michael'" , Doug Harbert , "'Tom-PT Taylor'" , "'sip'" Subject: Re: [SIP] Re-direct of Media During Ringing Message-ID: <20001005094639.A31680@div8.net> References: <39DA6934.5BC53A43@cs.columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i In-Reply-To: <39DA6934.5BC53A43@cs.columbia.edu>; from schulzrinne@cs.columbia.edu on Tue, Oct 03, 2000 at 07:18:12PM -0400 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 5 Oct 2000 09:46:39 -0500 Henning Schulzrinne (schulzrinne@cs.columbia.edu): > [...] As I said earlier, the whole early media stuff is a kludge. The > less we use it, the better. What is the status of the 183 draft? It seems like even more of a kludge if you don't have reliable provisional responses to negotiate the session. Are there any situations where early media is an absolute requirement? I guess there can't be, since you can always just put your SDP in the ACK and avoid it altogether. I strongly believe that its use should be discouraged in general, because of all these problems. -- Billy Biggs Billy_Biggs@3com.com http://www.div8.net/billy/ billy@div8.net _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Oct 5 14:31:11 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA04481 for ; Thu, 5 Oct 2000 14:31:05 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8DA1B44342; Thu, 5 Oct 2000 13:31:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from pentagon.cisco.com (pentagon.cisco.com [161.44.199.141]) by lists.bell-labs.com (Postfix) with ESMTP id 03B654433D for ; Thu, 5 Oct 2000 13:30:56 -0400 (EDT) Received: from cia.cisco.com (mirapoint@cia.cisco.com [161.44.199.157]) by pentagon.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA20418; Thu, 5 Oct 2000 14:30:52 -0400 (EDT) Received: from mhammer-nt.cisco.com (va-dhcp198-164.cisco.com [161.44.198.164]) by cia.cisco.com (Mirapoint) with ESMTP id ABQ01414; Thu, 5 Oct 2000 14:30:51 -0400 (EDT) Message-Id: <4.3.2.7.2.20001005140043.00b2e5e0@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Brian Stucker" , Rohan Mahy , "Roy, Radhika R, ALCOO" From: hammer michael Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP Mobility ) Cc: sip@lists.bell-labs.com In-Reply-To: <36FA02BD7083D411BC9E0000F8073E43D05C6C@crchy271.us.nortel. com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_19056041==_.ALT" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 05 Oct 2000 14:35:34 -0700 --=====================_19056041==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Brian, My main point was that the scope of control of the transport network extends only as far as the end of the transport connection. If that connection bypasses the proxy, then the proxy would not be informed of the subsequent location of the user. If the proxy was one of the end-points, then the flow of messages would probably keep in informed. But it is best left to the transport network to maintain those connections once established, for all the reasons you pointed out, i.e. handoffs every few seconds. But the question still remains in the bypass situation, as in the function of an HLR, if a new person were to want to contact the moving user, how does the proxy know where he is at any given time. (As you know, from the VLR on down to the radio site, the serving network maintains the call path until the call ends. At which point the user re-registers in the new network. The home network has no idea until that time.) If the user gets handed-off to another network operator and uses a new IP address: - Either the user tells the proxy directly by message to/through the proxy, or - the user tells some registration device (which may be at the network layer), or - the network nodes inform the registration device, and the proxy pulls it from there. Else, as far as the proxy is concerned, the user is incommunicado. Mike At 10:13 AM 10/05/2000 -0500, Brian Stucker wrote: >That's not necessarily true if I understand you correctly. Your SIP proxy >would not necessarily have to keep up with what is going on with the >endpoint as long as the transport network does the appropriate routing >work for anyone trying to address the mobile. You could have a stateless >proxy, for instance. The problem isn't so much with SIP as it is the media >exchange being setup through SIP (ie. an RTP stream). > >Brian >-----Original Message----- >From: hammer michael [mailto:mhammer@cisco.com] >Sent: Wednesday, October 04, 2000 8:48 PM >To: Stucker, Brian [RICH2:WI12:EXCH]; Rohan Mahy; Roy, Radhika R, ALCOO >Cc: sip@lists.bell-labs.com >Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP Mobility ) > >All, > >For the record, I agree with the idea that the lower layers should handle >mobility. However, one possibility exists that could take the control out >of the hands of the lower layer. I'm not sure if this is the issue we are >circling, but let me try to describe what I think could happen. > >The IP layer can address what happens to the communication end-to-end so >long as it is really end-to-end. If a proxy is used to patch together two >end-to-end IP streams, then any IP-dependent mechanism would be >constrained by its knowledge of what the endpoint is. > >If only one end-to-end stream is used, then the IP layer should be able to >maintain flows to that endpoint even as it moves within a network >domain. If movement causes the terminal to relinquish an IP address and >get a new one in a new network, registrations at the network layer can >reestablish IP identities among communicating parties. Also, that same >registration mechanism is how a user or proxy finds the other user to >begin with. If a message is not acknowledged, then another location >request is needed. > >However, if the real end-point is hidden behind a proxy using another IP >stream, then the proxy is burdened with the responsibility to keep track >of the end-points on the two streams. But this would be just two >instances of the simple example. > >So, the problem seems to come down to whether the information on the >whereabouts of a user is present or can be obtained by some mechanism on a >timely basis should an acknowledgement not be received. I had the >impression that this was not a problem. > >Is it the responsibility of the user to push that information to the >proxy, or is it the proxy's responsibility to pull that information from >the registrar? Either way, that should not be a problem in the time-scale >of a session set-up or release. > >In a world where the terminal is "always on", the role of SIP may be more >attuned to whether the user wants to be reached, not where or how to reach >the user. But that digresses into another subject. > >Mike Hammer > > > > >At 04:23 PM 10/04/2000 -0500, Brian Stucker wrote: > >>I definitely agree with that sentiment. That was the point of my >>argument. Do nothing in regards to SIP, and if there's something >>particular to SIP that needs to be addressed in a layer below SIP, then >>we should be trying to inject requirements and influence the decisions >>being made there first. >>Brian >> >>-----Original Message----- >>From: Rohan Mahy [mailto:rohan@cisco.com] >>Sent: Wednesday, October 04, 2000 3:14 PM >>To: Roy, Radhika R, ALCOO >>Cc: Stucker, Brian [RICH2:WI12:EXCH]; sip@lists.bell-labs.com >>Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP >>Mobility ) >> >>At 10:51 AM 9/29/00 , Roy, Radhika R, ALCOO wrote: >> >Hi, Brian: >> > >> >I guess that your mail has provided some technical inputs: 1. >> Inter-session >> >mobility and 2. Intra-session mobility. >> > >> >For inter-session mobility, you think that SIP in OK. >> > >> >For intra-session mobility, it appears that you are feeling >> comfortable, as >> >if, SIP is not designed to do this. >> > >> >Let us go to the basic: SIP is a session initiation protocol. It is the >> >mandate of SIP. So, we like to see that it MUST deal with mobility as well >> >>*NO* !! Part of SIPs mandate is *personal* mobility, as a user moves from >>device to device. Personal mobility is a good, useful thing. However, The >>SIP charter does *NOT* include solving the problem of a device moving >>through different layer 2 networks. This is a problem for a layer 3 >>protocol to solve generically. If Mobile IP doesn't do what we need it to, >>then lets extend it, fix it, or replace it. >> >>thanks, >>-rohan >> >> >because people will use it in mobile environment (for both intra- and >> >inter-session). >> >> > >> >For inter-session, I guess that there may be some involvement of REGISTER >> >and re-INVITE messages (because of change in location). >> > >> >That's all! >> > >> >All works are done in the lower layer and SIP is not involved (for >> example, >> >some one in the lower layer will find that the location has been changed, >> >accordingly the upper layer may take some actions, if needed). >> > >> >Hope this will clarify the things. >> > >> >Best regards, >> >Radhika R. Roy >> >AT&T >> > >> >-----Original Message----- >> >From: Brian Stucker >> [mailto:bstucker@nortelnetworks.com] >> >Sent: Friday, September 29, 2000 1:19 PM >> >To: sip@lists.bell-labs.com >> >Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP >> Mobility ) >> > >> > >> > >> >My intent isn't to confuse anyone. Quite the contrary. >> > >> >My point is that SIP, as an application, should not be concerned about >> the >> >vagaries of the underlying media it's being carried on. All applications >> >that use IP as a transport are going to have to contend with mobility >> in the >> >IP space on the intra-session timescale. So IP should solve the problem >> >because it's a general problem for IP. >> > >> >SIP does enough to handle inter-session mobility (I'm at my desk, I'm at >> >home), and not impede intra-session mobility. It's just simply not suited >> >for handling anything else because of the nature of the protocol. Any >> >intra-session mobility must be handled out-of-band as far as SIP is >> >concerned, and SIP must not make any requirements that would impede this. >> > >> >Again, to use wireless voice calls as an example, even with dedicated >> >transport links, thousands of pages of standards with CDMA/TDMA, IS-41, >> SS7, >> >and TCAP, a mobile switching center doesn't attempt to do what you guys >> are >> >talking about. It doesn't update the location of a mobile once it's >> handed >> >over to another switch in the location database until after your call has >> >completed, and the mobile registers on the system it moved into. Why? >> >Because the mobile could be handed back over to the first system, the >> >handoff could fail, etc. So they don't even attempt to keep the exact >> >location of the mobile up to date outside of the original switch until >> the >> >mobile is stable again, when the call ends. Instead, all incoming calls >> go >> >to the first switch, and that switch knows where to go from there to >> get the >> >call completed. >> > >> >SIP shouldn't be updating the location database every time a wireless >> >terminal moves around. Some sort of mobile IP proxy function, should >> instead >> >be used that knows how to currently find the terminal in it's >> mobile-aware >> >IP space. It should route based on the inbound packet's IP address >> only, and >> >not care what the payload data is either. >> > >> >That solves the problem for SIP, HTTP, FTP, POP3, RTP, you name it. Why >> >write an extension to every protocol that uses IP as a transport (and >> have >> >it solved, and debugged a million different ways) instead of just >> fixing the >> >problem at the IP layer (and have it solved, and debugged one way)? >> > >> >Brian Stucker >> >Nortel Networks >> > >> >-----Original Message----- >> >From: Roy, Radhika R, ALCOO [ >> mailto:rrroy@att.com ] >> >Sent: Friday, September 29, 2000 11:39 AM >> >To: hammer michael; Michael Thomas; Henry Sinnreich >> >Cc: Lewis Karl-QA3387; 'Henning Schulzrinne'; sip@lists.bell-labs.com >> >Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP >> >Mobility ) >> > >> > >> >Hi, Everyone: >> > >> >The need for addressing mobility is clear and SIP is only one part of the >> >whole equation. >> > >> >Let us not confuse people in the name of Pandora's box or otherwise. >> > >> >We have to meet the needs solving problems (not to show our back). >> > >> >For the SIP WG, it is the SIP session layer that needs to be addressed, >> if >> >it turns out that is a need to do some works. >> > >> >Best regards, >> >Radhika R. Roy >> >AT&T >> > >> >-----Original Message----- >> >From: hammer michael [ >> mailto:mhammer@cisco.com >> ] >> > >> >Sent: Friday, September 29, 2000 1:57 PM >> >To: Roy, Radhika R, ALCOO; Michael Thomas; Henry Sinnreich >> >Cc: Lewis Karl-QA3387; 'Henning Schulzrinne'; sip@lists.bell-labs.com >> >Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP >> >Mobility ) >> > >> > >> >I think Brian aptly pointed out the Pandora's box you open with >> "mobility." >> >That should be sufficient motivation to avoid that type of mobility in >> SIP. >> > >> >We are talking about different timescales, e.g.: per packet, per call, >> and >> >per registration. >> > >> >I thought your term "discrete" captured the idea that the type of >> >"mobility" you refer to is of the: call me at the office, then later, >> call >> >me at home, I'm here now "mobility." Because mobility conjures up so >> many >> >more issues, I like the word "presence" better. Presence management >> may be >> >more descriptive that mobility management. >> > >> >Mike >> > >> > >> >At 04:11 PM 09/28/2000 -0400, Roy, Radhika R, ALCOO wrote: >> > >Hi, Mike: >> > > >> > >Yes, we will have problems if we do not define the terms accurately. >> > > >> > >Let us assume that we are using SIP (RFC 2543) and its session layer >> as our >> > >> > >reference. Location, registration, and session are defined in SIP. >> > > >> > >Paging (and probably "path") has not been defined in SIP. I will not >> argue >> > >to take this abstraction in the SIP layer for now. >> > > >> > >Point of attachment has been used as a generic term to indicate >> "address of >> > >> > >the attachment." If we translate this abstraction in the SIP layer, >> it will >> > >> > >mean the addresses that are being used in the SIP layer (e.g., E.164, >> IP >> > >address, etc.). >> > > >> > >Now let us examine your points: Presence of a person or terminal, etc. >> > > >> > >In the SIP layer, I guess, that the presence of a person on a terminal >> >needs >> > >to be abstracted in terms of an "address." If that address is also >> related >> > >to the point of attachment, then it will also be related to mobility. >> > > >> > >(A person behind the terminal may have another ID to deal with personal >> > >mobility. Let us not address that personal mobility for now.) >> > > >> > >In this way, we can extend our analysis for each layer. >> > > >> > >Does this answer your question? >> > > >> > >Best regards, >> > >Radhika R. Roy >> > >AT&T >> > > >> > >-----Original Message----- >> > >From: hammer michael [ >> mailto:mhammer@cisco.com >> >] >> > >Sent: Thursday, September 28, 2000 6:29 PM >> > >To: Roy, Radhika R, ALCOO; Michael Thomas; Henry Sinnreich >> > >Cc: Lewis Karl-QA3387; 'Henning Schulzrinne'; sip@lists.bell-labs.com >> > >Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP >> > >Mobility ) >> > > >> > > >> > >Roy, >> > > >> > >I need to be very careful what word I choose. Session connection >> rather >> > >than path might have been more appropriate. I believe confusion can >> occur >> > >if the type of location, registration, location, paging, etc. is not >> > >accurately defined. I think that the intent of such services revolves >> > >about maintaining relationships between certain elements, such as >> between: >> > > >> > >user/application and terminal, >> > >terminal and network end-point, >> > >network end-point and link end-point, etc. >> > > >> > >The act of "registering" may mean different things at different >> layers and >> > >use different mechanisms to accomplish them. The question for me is >> > >whether these are handled independently or does one mechanism attempt >> to >> > >manage multiple associations or would one type of registration trigger >> > >another type at a different layer? >> > > >> > >Would SIP then manage the "presence" of a person on a terminal, where >> > >something else manages the "presence" of a terminal on the network? >> > > >> > >Mike Hammer >> > > >> > > >> > >At 12:28 PM 09/28/2000 -0400, Roy, Radhika R, ALCOO wrote: >> > > >Hi, Mike: >> > > > >> > > >You have made excellent points. In fact, you are in the heart of this >> > > >problem: How the communications path(s) needs to be established as >> the >> > >point >> > > >of attachment is changed during the contiguous mobility. >> > > > >> > > >I personally believe that SIP does not need to be involved to set >> up the >> > > >communications path(s) per se. >> > > > >> > > >However, SIP needs to be used to set up the session: re-INVITE (to >> the >> >new >> > > >address) may need to be used. >> > > > >> > > >In the process, location updates, paging, etc. are also involved. >> If the >> > > >location update does not have any impact in the SIP layer, I do not >> think >> > >> > > >that SIP should be aware of any change in the lower layer. For >> example, >> > > >mobile IP has the power of providing location transparency of the IP >> >layer >> > > >(although it has some problems to meet the performance requirements >> for >> >the >> > > >real-time communications like voice). >> > > > >> > > >In addition to IP addresses, there are also transport addresses >> (e.g., >> >UDP, >> > > >TCP) for media. One also needs to be careful how to deal with the TCP >> > > >connection. IP addresses change, but the TCP connections still >> remains >> >the >> > > >same. An update mechanism needs to be defined. In turn, does it >> mean that >> > >> > > >this updated information may also be propagated to the SIP layer >> (other >> > > >members may also provide comments on this) because SIP does have the >> > > >abstraction of the transport address? >> > > > >> > > >I have not yet talked about the link layer. >> > > > >> > > >I am not trying to solve the mobility problem here. >> > > > >> > > >All I am trying to show: If we try to analyze the situation doing an >> > > >end-to-end analysis, we can easily see what needs to be done in each >> >layer. >> > > >Finally, we can answer the question: Whether or not any new work is >> >needed >> > > >in the SIP layer to address both discrete and continuos mobility. >> > > > >> > > >But you are right that we MUST keep the involvement of the SIP >> layer to a >> > >> > > >minimal level (if possible, we should avoid it) to address the >> mobility >> > > >problem. >> > > > >> > > >Best regards, >> > > >Radhika R. Roy >> > > >AT&T >> > > > >> > > >-----Original Message----- >> > > >From: hammer michael [ >> mailto:mhammer@cisco.com >> > ] >> > > >Sent: Thursday, September 28, 2000 2:41 PM >> > > >To: Roy, Radhika R, ALCOO; Michael Thomas; Henry Sinnreich >> > > >Cc: Lewis Karl-QA3387; 'Henning Schulzrinne'; sip@lists.bell-labs.com >> > > >Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP >> > > >Mobility ) >> > > > >> > > > >> > > >Roy, >> > > > >> > > >Your use of the terms "discrete" and "continuous" strike to the >> heart of >> > > >the issue. In traditional mobile networks, there is an attempt to >> move >> >the >> > > >stream of media with the terminal as it crosses cell boundaries >> > > >(continuous). There are many papers related to voice and mobile-IP >> that >> > > >address how to move the communications path. >> > > > >> > > >The discrete case is more an issue of identification of the >> presence and >> > > >availability of recipients and the establishment of communications to >> > > >them. Because names and addresses denoting physical location are >> often >> > > >blurred, in essence, personal mobility involves the creation and >> deletion >> > >> > > >of recipients rather than their movement. >> > > > >> > > >As I understand it, SIP does not move existing communications so >> much as >> >it >> > > >destroys existing communications paths and replaces them with new >> ones. >> >In >> > > >that respect, some of the traditional mobility issues such as >> handover >> >are >> > > >avoided, but others, e.g. location updates and paging are still >> needed. >> > > > >> > > >While the telcos reverted to addressing hardware-oriented terminal >> >mobility >> > > >in PCS, the softer personal mobility is still open to >> definition. The >> >same >> > > >issues have appeared in the net world and each will need to be >> solved in >> > > >their respective layers. >> > > > >> > > >Mike >> > > > >> > > > >> > > >At 11:01 AM 09/28/2000 -0400, Roy, Radhika R, ALCOO wrote: >> > > > >Hi, Mike: >> > > > > >> > > > >In fact, this is the precisely the test why SIP should be >> involved or >> >to >> > >be >> > > > >enhanced to support mobility (discrete + continuos) in the case of >> >Voice, >> > > > >chat, IM, messaging, conferencing, games, and others. >> > > > > >> > > > >If it is found that SIP does not need to be involved, I do not >> think >> >that >> > > > >anyone will force it to do this. >> > > > > >> > > > >By the way, do you not see that how SIP (RFC 2543) has taken care >> of >> >many >> > > > >aspects of users' discrete mobility? Has it not been be an >> excellent >> >way >> > >of >> > > > >involving SIP to solve a kind of mobility in the first place (what >> >other >> > > > >applications like H.323 is yet to support)? >> > > > > >> > > > >Along the same line, if people come up with the ideas that it is >> better >> > >> > >to >> > > > >enhance SIP functionality to support other aspects of mobility (if >> > > > >alternative solutions are not there or not acceptable), I do not >> think >> > >that >> > > > >we should have any objections. >> > > > > >> > > > >Let us keep our mind open and judge each proposal with its own >> merits. >> > > > > >> > > > >Best regards, >> > > > >Radhika R. Roy >> > > > >AT&T >> > > > > >> > > > >-----Original Message----- >> > > > >From: Michael Thomas [ mailto:mat@cisco.com >> ] >> > > > >Sent: Wednesday, September 27, 2000 7:01 PM >> > > > >To: Henry Sinnreich >> > > > >Cc: Michael Thomas; Roy, Radhika R, ALCOO; Lewis Karl-QA3387; >> 'Henning >> > > > >Schulzrinne'; sip@lists.bell-labs.com >> > > > >Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP >> > > > >Mobility ) >> > > > > >> > > > > >> > > > >Henry Sinnreich writes: >> > > > > > >what seems clear is that there are a >> > > > > > >number of applications which won't be able to do >> > > > > > >that for a variety of reasons. >> > > > > > >> > > > > > Voice, chat, IM, messaging, conferencing, games, etc., are >> > > > > > plenty of reasons to justify the SIP approach to mobility. >> > > > > >> > > > > But what if you could do all of the same things >> > > > > and not need to modify or involve SIP and have the >> > > > > additional gain that things like http worked as well? >> > > > > >> > > > > Mike >> > > > > >> > > > > > >> > > > > > Henry >> > > > > > >> > > > > > >-----Original Message----- >> > > > > > >From: sip-admin@lists.bell-labs.com >> > > > > > >[ >> mailto:sip-admin@lists.bell-labs.com >> > ]On Behalf Of >> > > > > > >Michael Thomas >> > > > > > >Sent: Wednesday, September 27, 2000 8:33 PM >> > > > > > >To: Roy, Radhika R, ALCOO >> > > > > > >Cc: Michael Thomas; Lewis Karl-QA3387; 'Henning Schulzrinne'; >> > > > > > >sip@lists.bell-labs.com >> > > > > > >Subject: RE: [SIP] Attempt at summarizing current SIP >> > > > > > >drafts (SIP >> > > > > > >Mobility ) >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > >I guess what I'm having a hard time with is the >> > > > > > >starting point that assumes that SIP based >> > > > > > >application mobility is Good Thing. While it's >> > > > > > >clear that many applications *could* design in >> > > > > > >mobility, what seems clear is that there are a >> > > > > > >number of applications which won't be able to do >> > > > > > >that for a variety of reasons. Assuming that those >> > > > > > >applications are important too, then we're already >> > > > > > >stuck with needing to solve for the general >> > > > > > >problem. >> > > > > > > >> > > > > > >Starting out with the assumption that Mobile IP >> > > > > > >addresses the more general problem seems >> > > > > > >attractive because a good solution with fast >> > > > > > >handoff that addresses AAA and QoS would solve >> > > > > > >most of the application layer problems in a >> > > > > > >general way rather than just a SIP specific >> > > > > > >way. >> > > > > > > >> > > > > > >There also seems to be an implicit assumption in >> > > > > > >the draft of linkage of SIP to a AAA function. >> > > > > > >I'm going to guess that it is along the same line >> > > > > > >of thinking of the DQoS gate controller idea. The >> > > > > > >problem I have with that is that it is in the end >> > > > > > >an optimization on the normal RSVP/COPS pull >> > > > > > >model. However, things that don't fit into that >> > > > > > >model still have the non-optimized way of doing >> > > > > > >QoS authorization. That's probably not the fault >> > > > > > >of this draft, but it does seem to make the entire >> > > > > > >draft a cart-before-horse situation. >> > > > > > > >> > > > > > > Mike >> > > > > > > >> > > > > > >Roy, Radhika R, ALCOO writes: >> > > > > > > > Hi, Mike: >> > > > > > > > >> > > > > > > > I guess that SIP, as you rightly pointed out, is >> > > > > > >dealing with the signaling >> > > > > > > > mechanism in the application layer. So, SIP does >> > > > > > >not need to deal with L3 >> > > > > > > > media path. >> > > > > > > > >> > > > > > > > SIP does deal with addresses of the source and >> > > > > > >destination(s). >> > > > > > > > >> > > > > > > > In mobile environment, the point of attachment >> > > > > > >(i.e., addresses) changes: 1. >> > > > > > > > Between the sessions (discrete mobility) and 2. >> > > > > > >During the session >> > > > > > > > (continuous mobility). >> > > > > > > > >> > > > > > > > The problem that is being addressed is: What is the >> > > > > > >impact in SIP layer due >> > > > > > > > to these two kinds of mobility. >> > > > > > > > >> > > > > > > > I guess that for discrete mobility, SIP has >> > > > > > >probably addressed most of the >> > > > > > > > problems (others may also provide comments on this). >> > > > > > > > >> > > > > > > > For continuous mobility, there may need (or may >> > > > > > >not??) some works in the SIP >> > > > > > > > layer, if any (others may also provide comments). >> > > > > > > > >> > > > > > > > However, SIP can only address the mobility related >> > > > > > >problems in the >> > > > > > > > application layer. This alone may not be enough to >> > > > > > >solve all problems >> > > > > > > > because some L3 and L2 problems may also need to be >> > > > > > >addressed at the same >> > > > > > > > time to have the complete solution. >> > > > > > > > >> > > > > > > > In any solution, SIP mobility needs to be limited >> > > > > > >only to the application >> > > > > > > > layer (not L3, L2, etc.). >> > > > > > > > >> > > > > > > > Best regards, >> > > > > > > > Radhika R. Roy >> > > > > > > > AT&T >> > > > > > > > >> > > > > > > > -----Original Message----- >> > > > > > > > From: Michael Thomas [ >> mailto:mat@cisco.com >> > ] >> > > > > > > > Sent: Wednesday, September 27, 2000 12:32 PM >> > > > > > > > To: Lewis Karl-QA3387 >> > > > > > > > Cc: 'Henning Schulzrinne'; sip@lists.bell-labs.com >> > > > > > > > Subject: RE: [SIP] Attempt at summarizing current SIP >> drafts >> > > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > > While I'm more than willing to believe that there >> > > > > > > > are mobility issues that SIP needs to deal with, >> > > > > > > > this paper seems to be positing SIP as the means >> > > > > > > > of initiating data sessions altogether. To my >> > > > > > > > mind, that's a rather bellheaded way of thinking >> > > > > > > > about how you do what amounts to L3 admission >> > > > > > > > control. In fact, the IETF already has an L3 >> > > > > > > > admission control mechanism: RSVP. RSVP's main >> > > > > > > > advantage is that it follows actual network >> > > > > > > > topology. SIP is at a distinct disadvantage since >> > > > > > > > all it knows about is the signaling path which >> > > > > > > > in normal circumstances has nothing to do with >> > > > > > > > the actual data path. >> > > > > > > > >> > > > > > > > Maybe I'm misreading this whole paper, but it sure >> > > > > > > > looks like it to me. If my interpretation is >> > > > > > > > right, however, I'd like to know if the intention >> > > > > > > > is to signal the access routers providing the >> > > > > > > > L2/L3 bits using SIP instead of, say, COPS (or >> > > > > > > > DIAMETER). If so, I'd say that SIP truly has >> > > > > > > > arrived at becoming the new millenium's kitchen >> > > > > > > > sink if this is accepted. >> > > > > > > > >> > > > > > > > Mike >> > > > > > > > >> > > > > > > > Lewis Karl-QA3387 writes: >> > > > > > > > > I have just reviewed the Mobility Related drafts >> > > > > > >and am wondering if >> > > > > > > > anyone >> > > > > > > > > is aware of the current status of >> > > > > > >draft-itsumo-sip -mobility-req-01. In >> > > > > > > > > particular, several issues were identified such >> > > > > > >as Mobile IP not being >> > > > > > > > > sufficient for personal mobility and location >> > > > > > >services, completing >> > > > > > > > > registration in less than a few seconds, >> > > > > > >reconfiguration in milliseconds, >> > > > > > > > > providing location services, support of inter >> > > > > > >domain soft-hand and secure >> > > > > > > > > signaling. Have these issues been addressed or >> > > > > > >actively being worked? >> > > > > > > > > >> > > > > > > > > Karl >> > > > > > > > > >> > > > > > > > > >> > > > > > > > > >> > > > > > > > > -----Original Message----- >> > > > > > > > > From: Henning Schulzrinne >> > > > > > [ >> mailto:schulzrinne@cs.columbia.edu >> > ] >> > > > > > > > Sent: Monday, September 25, 2000 9:20 AM >> > > > > > > > To: sip@lists.bell-labs.com >> > > > > > > > Subject: [SIP] Attempt at summarizing current SIP drafts >> > > > > > > > >> > > > > > > > >> > > > > > > > Given the proliferation of SIP-related drafts, I've >> > > > > > created a summary of >> > > > > > > > efforts at >> > > > > > >> http://www.cs.columbia.edu/~hgs/sip/drafts.html >> >> > . This is >> > > > > > > > known to be incomplete, so I'd appreciate if you could >> > > > > > send me any >> > > > > > > > additions or corrections. (Jonathan Rosenberg provided >> > > > > > some of the text; >> > > > > > > > any mistakes or misrepresentations are mine.) >> > > > > > > > >> > > > > > > > It is fairly clear that there are a large number of >> drafts >> > > > > > that have not >> > > > > > > > changed materially for half a year or more. Maybe it's >> > > > > > time to have a WG >> > > > > > > > last call or two or ten... >> > > > > > > > >> > > > > > > > Henning >> > > > > > > > -- >> > > > > > > > Henning >> Schulzrinne >> http://www.cs.columbia.edu/~hgs >> > >> > > > > > > > >> > > > > > > > >> > > > > > > > _______________________________________________ >> > > > > > > > SIP mailing list >> > > > > > > > SIP@lists.bell-labs.com >> > > > > > > > >> http://lists.bell-labs.com/mailman/listinfo/sip >> >> > >> > > > > > > > >> > > > > > > > _______________________________________________ >> > > > > > > > SIP mailing list >> > > > > > > > SIP@lists.bell-labs.com >> > > > > > > > >> http://lists.bell-labs.com/mailman/listinfo/sip >> >> > >> > > > > > > > >> > > > > > > >> > > > > > > _______________________________________________ >> > > > > > > SIP mailing list >> > > > > > > SIP@lists.bell-labs.com >> > > > > > > >> http://lists.bell-labs.com/mailman/listinfo/sip >> >> > >> > > > > > > >> > > > > > > _______________________________________________ >> > > > > > > SIP mailing list >> > > > > > > SIP@lists.bell-labs.com >> > > > > > > >> http://lists.bell-labs.com/mailman/listinfo/sip >> >> > >> > > > > > > >> > > > > > >> > > > > > _______________________________________________ >> > > > > > SIP mailing list >> > > > > > SIP@lists.bell-labs.com >> > > > > > >> http://lists.bell-labs.com/mailman/listinfo/sip >> >> > >> > > > > > >> > > > > > >> > > > > >> > > > >_______________________________________________ >> > > > >SIP mailing list >> > > > >SIP@lists.bell-labs.com >> > > > > >> http://lists.bell-labs.com/mailman/listinfo/sip >> >> > >> > > > > >> > > > >_______________________________________________ >> > > > >SIP mailing list >> > > > >SIP@lists.bell-labs.com >> > > > > >> http://lists.bell-labs.com/mailman/listinfo/sip >> >> > >> > >> > >> >_______________________________________________ >> >SIP mailing list >> >SIP@lists.bell-labs.com >> >http://lists.bell-labs. >> com/mailman/listinfo/sip >> > >> > >> > >> >_______________________________________________ >> >SIP mailing list >> >SIP@lists.bell-labs.com >> >http://lists.bell-labs. >> com/mailman/listinfo/sip --=====================_19056041==_.ALT Content-Type: text/html; charset="us-ascii" Brian,

My main point was that the scope of control of the transport network extends only as far as the end of the transport connection.  If that connection bypasses the proxy, then the proxy would not be informed of the subsequent location of the user.  If the proxy was one of the end-points, then the flow of messages would probably keep in informed.  But it is best left to the transport network to maintain those connections once established, for all the reasons you pointed out, i.e. handoffs every few seconds.

But the question still remains in the bypass situation, as in the function of an HLR, if a new person were to want to contact the moving user, how does the proxy know where he is at any given time.  (As you know, from the VLR on down to the radio site, the serving network maintains the call path until the call ends.  At which point the user re-registers in the new network.  The home network has no idea until that time.) 

If the user gets handed-off to another network operator and uses a new IP address:
-   Either the user tells the proxy directly by message to/through the proxy, or
-   the user tells some registration device (which may be at the network layer), or
-   the network nodes inform the registration device, and the proxy pulls it from there. 

Else, as far as the proxy is concerned, the user is incommunicado.

Mike


At 10:13 AM 10/05/2000 -0500, Brian Stucker wrote:
That's not necessarily true if I understand you correctly. Your SIP proxy would not necessarily have to keep up with what is going on with the endpoint as long as the transport network does the appropriate routing work for anyone trying to address the mobile. You could have a stateless proxy, for instance. The problem isn't so much with SIP as it is the media exchange being setup through SIP (ie. an RTP stream).
 
Brian
-----Original Message-----
From: hammer michael [mailto:mhammer@cisco.com]
Sent: Wednesday, October 04, 2000 8:48 PM
To: Stucker, Brian [RICH2:WI12:EXCH]; Rohan Mahy; Roy, Radhika R, ALCOO
Cc: sip@lists.bell-labs.com
Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP Mobility )
All,

For the record, I agree with the idea that the lower layers should handle mobility.  However, one possibility exists that could take the control out of the hands of the lower layer.  I'm not sure if this is the issue we are circling, but let me try to describe what I think could happen.

The IP layer can address what happens to the communication end-to-end so long as it is really end-to-end.  If a proxy is used to patch together two end-to-end IP streams, then any IP-dependent mechanism would be constrained by its knowledge of what the endpoint is.

If only one end-to-end stream is used, then the IP layer should be able to maintain flows to that endpoint even as it moves within a network domain.  If movement causes the terminal to relinquish an IP address and get a new one in a new network, registrations at the network layer can reestablish IP identities among communicating parties.  Also, that same registration mechanism is how a user or proxy finds the other user to begin with.  If a message is not acknowledged, then another location request is needed.

However, if the real end-point is hidden behind a proxy using another IP stream, then the proxy is burdened with the responsibility to keep track of the end-points on the two streams.  But this would be just two instances of the simple example.

So, the problem seems to come down to whether the information on the whereabouts of a user is present or can be obtained by some mechanism on a timely basis should an acknowledgement not be received.  I had the impression that this was not a problem.

Is it the responsibility of the user to push that information to the proxy, or is it the proxy's responsibility to pull that information from the registrar?  Either way, that should not be a problem in the time-scale of a session set-up or release.

In a world where the terminal is "always on", the role of SIP may be more attuned to whether the user wants to be reached, not where or how to reach the user.  But that digresses into another subject.

Mike Hammer
 



At 04:23 PM 10/04/2000 -0500, Brian Stucker wrote:

I definitely agree with that sentiment. That was the point of my argument. Do nothing in regards to SIP, and if there's something particular to SIP that needs to be addressed in a layer below SIP, then we should be trying to inject requirements and influence the decisions being made there first.
Brian

-----Original Message-----
From: Rohan Mahy [mailto:rohan@cisco.com]
Sent: Wednesday, October 04, 2000 3:14 PM
To: Roy, Radhika R, ALCOO
Cc: Stucker, Brian [RICH2:WI12:EXCH]; sip@lists.bell-labs.com
Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP
Mobility )

At 10:51 AM 9/29/00 , Roy, Radhika R, ALCOO wrote:
>Hi, Brian:
>
>I guess that your mail has provided some technical inputs: 1. Inter-session
>mobility and 2. Intra-session mobility.
>
>For inter-session mobility, you think that SIP in OK.
>
>For intra-session mobility, it appears that you are feeling comfortable, as
>if, SIP is not designed to do this.
>
>Let us go to the basic: SIP is a session initiation protocol. It is the
>mandate of SIP. So, we like to see that it MUST deal with mobility as well

*NO* !!  Part of SIPs mandate is *personal* mobility, as a user moves from
device to device.  Personal mobility is a good, useful thing.  However, The
SIP charter does *NOT* include solving the problem of a device moving
through different layer 2 networks.  This is a problem for a layer 3
protocol to solve generically.  If Mobile IP doesn't do what we need it to,
then lets extend it, fix it, or replace it.

thanks,
-rohan

>because people will use it in mobile environment (for both intra- and
>inter-session).

>
>For inter-session, I guess that there may be some involvement of REGISTER
>and re-INVITE messages (because of change in location).
>
>That's all!
>
>All works are done in the lower layer and SIP is not involved (for example,
>some one in the lower layer will find that the location has been changed,
>accordingly the upper layer may take some actions, if needed).
>
>Hope this will clarify the things.
>
>Best regards,
>Radhika R. Roy
>AT&T
>
>-----Original Message-----
>From: Brian Stucker [mailto:bstucker@nortelnetworks.com]
>Sent: Friday, September 29, 2000 1:19 PM
>To: sip@lists.bell-labs.com
>Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP Mobility )
>
>
>
>My intent isn't to confuse anyone. Quite the contrary.
>
>My point is that SIP, as an application, should not be concerned about the
>vagaries of the underlying media it's being carried on. All applications
>that use IP as a transport are going to have to contend with mobility in the
>IP space on the intra-session timescale. So IP should solve the problem
>because it's a general problem for IP.
>
>SIP does enough to handle inter-session mobility (I'm at my desk, I'm at
>home), and not impede intra-session mobility. It's just simply not suited
>for handling anything else because of the nature of the protocol. Any
>intra-session mobility must be handled out-of-band as far as SIP is
>concerned, and SIP must not make any requirements that would impede this.
>
>Again, to use wireless voice calls as an example, even with dedicated
>transport links, thousands of pages of standards with CDMA/TDMA, IS-41, SS7,
>and TCAP, a mobile switching center doesn't attempt to do what you guys are
>talking about. It doesn't update the location of a mobile once it's handed
>over to another switch in the location database until after your call has
>completed, and the mobile registers on the system it moved into. Why?
>Because the mobile could be handed back over to the first system, the
>handoff could fail, etc. So they don't even attempt to keep the exact
>location of the mobile up to date outside of the original switch until the
>mobile is stable again, when the call ends. Instead, all incoming calls go
>to the first switch, and that switch knows where to go from there to get the
>call completed.
>
>SIP shouldn't be updating the location database every time a wireless
>terminal moves around. Some sort of mobile IP proxy function, should instead
>be used that knows how to currently find the terminal in it's mobile-aware
>IP space. It should route based on the inbound packet's IP address only, and
>not care what the payload data is either.
>
>That solves the problem for SIP, HTTP, FTP, POP3, RTP, you name it. Why
>write an extension to every protocol that uses IP as a transport (and have
>it solved, and debugged a million different ways) instead of just fixing the
>problem at the IP layer (and have it solved, and debugged one way)?
>
>Brian Stucker
>Nortel Networks
>
>-----Original Message-----
>From: Roy, Radhika R, ALCOO [ mailto:rrroy@att.com <mailto:rrroy@att.com> ]
>Sent: Friday, September 29, 2000 11:39 AM
>To: hammer michael; Michael Thomas; Henry Sinnreich
>Cc: Lewis Karl-QA3387; 'Henning Schulzrinne'; sip@lists.bell-labs.com
>Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP
>Mobility )
>
>
>Hi, Everyone:
>
>The need for addressing mobility is clear and SIP is only one part of the
>whole equation.
>
>Let us not confuse people in the name of Pandora's box or otherwise.
>
>We have to meet the needs solving problems (not to show our back).
>
>For the SIP WG, it is the SIP session layer that needs to be addressed, if
>it turns out that is a need to do some works.
>
>Best regards,
>Radhika R. Roy
>AT&T
>
>-----Original Message-----
>From: hammer michael [ mailto:mhammer@cisco.com <mailto:mhammer@cisco.com> ]
>
>Sent: Friday, September 29, 2000 1:57 PM
>To: Roy, Radhika R, ALCOO; Michael Thomas; Henry Sinnreich
>Cc: Lewis Karl-QA3387; 'Henning Schulzrinne'; sip@lists.bell-labs.com
>Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP
>Mobility )
>
>
>I think Brian aptly pointed out the Pandora's box you open with "mobility."
>That should be sufficient motivation to avoid that type of mobility in SIP.
>
>We are talking about different timescales, e.g.:  per packet, per call, and
>per registration.
>
>I thought your term "discrete" captured the idea that the type of
>"mobility" you refer to is of the:  call me at the office, then later, call
>me at home, I'm here now "mobility."  Because mobility conjures up so many
>more issues, I like the word "presence" better.  Presence management may be
>more descriptive that mobility management.
>
>Mike
>
>
>At 04:11 PM 09/28/2000 -0400, Roy, Radhika R, ALCOO wrote:
> >Hi, Mike:
> >
> >Yes, we will have problems if we do not define the terms accurately.
> >
> >Let us assume that we are using SIP (RFC 2543) and its session layer as our
>
> >reference. Location, registration, and session are defined in SIP.
> >
> >Paging (and probably "path") has not been defined in SIP. I will not argue
> >to take this abstraction in the SIP layer for now.
> >
> >Point of attachment has been used as a generic term to indicate "address of
>
> >the attachment." If we translate this abstraction in the SIP layer, it will
>
> >mean the addresses that are being used in the SIP layer (e.g., E.164, IP
> >address, etc.).
> >
> >Now let us examine your points: Presence of a person or terminal, etc.
> >
> >In the SIP layer, I guess, that the presence of a person on a terminal
>needs
> >to be abstracted in terms of an "address." If that address is also related
> >to the point of attachment, then it will also be related to mobility.
> >
> >(A person behind the terminal may have another ID to deal with personal
> >mobility. Let us not address that personal mobility for now.)
> >
> >In this way, we can extend our analysis for each layer.
> >
> >Does this answer your question?
> >
> >Best regards,
> >Radhika R. Roy
> >AT&T
> >
> >-----Original Message-----
> >From: hammer michael [ mailto:mhammer@cisco.com <mailto:mhammer@cisco.com>
>]
> >Sent: Thursday, September 28, 2000 6:29 PM
> >To: Roy, Radhika R, ALCOO; Michael Thomas; Henry Sinnreich
> >Cc: Lewis Karl-QA3387; 'Henning Schulzrinne'; sip@lists.bell-labs.com
> >Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP
> >Mobility )
> >
> >
> >Roy,
> >
> >I need to be very careful what word I choose.  Session connection rather
> >than path might have been more appropriate.  I believe confusion can occur
> >if the type of location, registration, location, paging, etc. is not
> >accurately defined.  I think that the intent of such services revolves
> >about maintaining relationships between certain elements, such as between:
> >
> >user/application and terminal,
> >terminal and network end-point,
> >network end-point and link end-point, etc.
> >
> >The act of "registering" may mean different things at different layers and
> >use different mechanisms to accomplish them.  The question for me is
> >whether these are handled independently or does one mechanism attempt to
> >manage multiple associations or would one type of registration trigger
> >another type at a different layer?
> >
> >Would SIP then manage the "presence" of a person on a terminal, where
> >something else manages the "presence" of a terminal on the network?
> >
> >Mike Hammer
> >
> >
> >At 12:28 PM 09/28/2000 -0400, Roy, Radhika R, ALCOO wrote:
> > >Hi, Mike:
> > >
> > >You have made excellent points. In fact, you are in the heart of this
> > >problem: How the communications path(s) needs to be established as the
> >point
> > >of attachment is changed during the contiguous mobility.
> > >
> > >I personally believe that SIP does not need to be involved to set up the
> > >communications path(s) per se.
> > >
> > >However, SIP needs to be used to set up the session: re-INVITE (to the
>new
> > >address) may need to be used.
> > >
> > >In the process, location updates, paging, etc. are also involved. If the
> > >location update does not have any impact in the SIP layer, I do not think
>
> > >that SIP should be aware of any change in the lower layer. For example,
> > >mobile IP has the power of providing location transparency of the IP
>layer
> > >(although it has some problems to meet the performance requirements for
>the
> > >real-time communications like voice).
> > >
> > >In addition to IP addresses, there are also transport addresses (e.g.,
>UDP,
> > >TCP) for media. One also needs to be careful how to deal with the TCP
> > >connection. IP addresses change, but the TCP connections still remains
>the
> > >same. An update mechanism needs to be defined. In turn, does it mean that
>
> > >this updated information may also be propagated to the SIP layer (other
> > >members may also provide comments on this) because SIP does have the
> > >abstraction of the transport address?
> > >
> > >I have not yet talked about the link layer.
> > >
> > >I am not trying to solve the mobility problem here.
> > >
> > >All I am trying to show: If we try to analyze the situation doing an
> > >end-to-end analysis, we can easily see what needs to be done in each
>layer.
> > >Finally, we can answer the question: Whether or not any new work is
>needed
> > >in the SIP layer to address both discrete and continuos mobility.
> > >
> > >But you are right that we MUST keep the involvement of the SIP layer to a
>
> > >minimal level (if possible, we should avoid it) to address the mobility
> > >problem.
> > >
> > >Best regards,
> > >Radhika R. Roy
> > >AT&T
> > >
> > >-----Original Message-----
> > >From: hammer michael [ mailto:mhammer@cisco.com
><mailto:mhammer@cisco.com> ]
> > >Sent: Thursday, September 28, 2000 2:41 PM
> > >To: Roy, Radhika R, ALCOO; Michael Thomas; Henry Sinnreich
> > >Cc: Lewis Karl-QA3387; 'Henning Schulzrinne'; sip@lists.bell-labs.com
> > >Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP
> > >Mobility )
> > >
> > >
> > >Roy,
> > >
> > >Your use of the terms "discrete" and "continuous" strike to the heart of
> > >the issue.  In traditional mobile networks, there is an attempt to move
>the
> > >stream of media with the terminal as it crosses cell boundaries
> > >(continuous).  There are many papers related to voice and mobile-IP that
> > >address how to move the communications path.
> > >
> > >The discrete case is more an issue of identification of the presence and
> > >availability of recipients and the establishment of communications to
> > >them.  Because names and addresses denoting physical location are often
> > >blurred, in essence, personal mobility involves the creation and deletion
>
> > >of recipients rather than their movement.
> > >
> > >As I understand it, SIP does not move existing communications so much as
>it
> > >destroys existing communications paths and replaces them with new ones.
>In
> > >that respect, some of the traditional mobility issues such as handover
>are
> > >avoided, but others, e.g. location updates and paging are still needed.
> > >
> > >While the telcos reverted to addressing hardware-oriented terminal
>mobility
> > >in PCS, the softer personal mobility is still open to definition.  The
>same
> > >issues have appeared in the net world and each will need to be solved in
> > >their respective layers.
> > >
> > >Mike
> > >
> > >
> > >At 11:01 AM 09/28/2000 -0400, Roy, Radhika R, ALCOO wrote:
> > > >Hi, Mike:
> > > >
> > > >In fact, this is the precisely the test why SIP should be involved or
>to
> >be
> > > >enhanced to support mobility (discrete + continuos) in the case of
>Voice,
> > > >chat, IM, messaging, conferencing, games, and others.
> > > >
> > > >If it is found that SIP does not need to be involved, I do not think
>that
> > > >anyone will force it to do this.
> > > >
> > > >By the way, do you not see that how SIP (RFC 2543) has taken care of
>many
> > > >aspects of users' discrete mobility? Has it not been be an excellent
>way
> >of
> > > >involving SIP to solve a kind of mobility in the first place (what
>other
> > > >applications like H.323 is yet to support)?
> > > >
> > > >Along the same line, if people come up with the ideas that it is better
>
> >to
> > > >enhance SIP functionality to support other aspects of mobility (if
> > > >alternative solutions are not there or not acceptable), I do not think
> >that
> > > >we should have any objections.
> > > >
> > > >Let us keep our mind open and judge each proposal with its own merits.
> > > >
> > > >Best regards,
> > > >Radhika R. Roy
> > > >AT&T
> > > >
> > > >-----Original Message-----
> > > >From: Michael Thomas [ mailto:mat@cisco.com <mailto:mat@cisco.com> ]
> > > >Sent: Wednesday, September 27, 2000 7:01 PM
> > > >To: Henry Sinnreich
> > > >Cc: Michael Thomas; Roy, Radhika R, ALCOO; Lewis Karl-QA3387; 'Henning
> > > >Schulzrinne'; sip@lists.bell-labs.com
> > > >Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP
> > > >Mobility )
> > > >
> > > >
> > > >Henry Sinnreich writes:
> > > >  > >what seems clear is that there are a
> > > >  > >number of applications which won't be able to do
> > > >  > >that for a variety of reasons.
> > > >  >
> > > >  > Voice, chat, IM, messaging, conferencing, games, etc., are
> > > >  > plenty of reasons to justify the SIP approach to mobility.
> > > >
> > > >    But what if you could do all of the same things
> > > >    and not need to modify or involve SIP and have the
> > > >    additional gain that things like http worked as well?
> > > >
> > > >                    Mike
> > > >
> > > >  >
> > > >  > Henry
> > > >  >
> > > >  > >-----Original Message-----
> > > >  > >From: sip-admin@lists.bell-labs.com
> > > >  > >[ mailto:sip-admin@lists.bell-labs.com
><mailto:sip-admin@lists.bell-labs.com> ]On Behalf Of
> > > >  > >Michael Thomas
> > > >  > >Sent: Wednesday, September 27, 2000 8:33 PM
> > > >  > >To: Roy, Radhika R, ALCOO
> > > >  > >Cc: Michael Thomas; Lewis Karl-QA3387; 'Henning Schulzrinne';
> > > >  > >sip@lists.bell-labs.com
> > > >  > >Subject: RE: [SIP] Attempt at summarizing current SIP
> > > >  > >drafts (SIP
> > > >  > >Mobility )
> > > >  > >
> > > >  > >
> > > >  > >
> > > >  > >I guess what I'm having a hard time with is the
> > > >  > >starting point that assumes that SIP based
> > > >  > >application mobility is Good Thing. While it's
> > > >  > >clear that many applications *could* design in
> > > >  > >mobility, what seems clear is that there are a
> > > >  > >number of applications which won't be able to do
> > > >  > >that for a variety of reasons. Assuming that those
> > > >  > >applications are important too, then we're already
> > > >  > >stuck with needing to solve for the general
> > > >  > >problem.
> > > >  > >
> > > >  > >Starting out with the assumption that Mobile IP
> > > >  > >addresses the more general problem seems
> > > >  > >attractive because a good solution with fast
> > > >  > >handoff that addresses AAA and QoS would solve
> > > >  > >most of the application layer problems in a
> > > >  > >general way rather than just a SIP specific
> > > >  > >way.
> > > >  > >
> > > >  > >There also seems to be an implicit assumption in
> > > >  > >the draft of linkage of SIP to a AAA function.
> > > >  > >I'm going to guess that it is along the same line
> > > >  > >of thinking of the DQoS gate controller idea. The
> > > >  > >problem I have with that is that it is in the end
> > > >  > >an optimization on the normal RSVP/COPS pull
> > > >  > >model. However, things that don't fit into that
> > > >  > >model still have the non-optimized way of doing
> > > >  > >QoS authorization. That's probably not the fault
> > > >  > >of this draft, but it does seem to make the entire
> > > >  > >draft a cart-before-horse situation.
> > > >  > >
> > > >  > >    Mike
> > > >  > >
> > > >  > >Roy, Radhika R, ALCOO writes:
> > > >  > > > Hi, Mike:
> > > >  > > >
> > > >  > > > I guess that SIP, as you rightly pointed out, is
> > > >  > >dealing with the signaling
> > > >  > > > mechanism in the application layer. So, SIP does
> > > >  > >not need to deal with L3
> > > >  > > > media path.
> > > >  > > >
> > > >  > > > SIP does deal with addresses of the source and
> > > >  > >destination(s).
> > > >  > > >
> > > >  > > > In mobile environment, the point of attachment
> > > >  > >(i.e., addresses) changes: 1.
> > > >  > > > Between the sessions (discrete mobility) and 2.
> > > >  > >During the session
> > > >  > > > (continuous mobility).
> > > >  > > >
> > > >  > > > The problem that is being addressed is: What is the
> > > >  > >impact in SIP layer due
> > > >  > > > to these two kinds of mobility.
> > > >  > > >
> > > >  > > > I guess that for discrete mobility, SIP has
> > > >  > >probably addressed most of the
> > > >  > > > problems (others may also provide comments on this).
> > > >  > > >
> > > >  > > > For continuous mobility, there may need (or may
> > > >  > >not??) some works in the SIP
> > > >  > > > layer, if any (others may also provide comments).
> > > >  > > >
> > > >  > > > However, SIP can only address the mobility related
> > > >  > >problems in the
> > > >  > > > application layer. This alone may not be enough to
> > > >  > >solve all problems
> > > >  > > > because some L3 and L2 problems may also need to be
> > > >  > >addressed at the same
> > > >  > > > time to have the complete solution.
> > > >  > > >
> > > >  > > > In any solution, SIP mobility needs to be limited
> > > >  > >only to the application
> > > >  > > > layer (not L3, L2, etc.).
> > > >  > > >
> > > >  > > > Best regards,
> > > >  > > > Radhika R. Roy
> > > >  > > > AT&T
> > > >  > > >
> > > >  > > > -----Original Message-----
> > > >  > > > From: Michael Thomas [ mailto:mat@cisco.com
><mailto:mat@cisco.com> ]
> > > >  > > > Sent: Wednesday, September 27, 2000 12:32 PM
> > > >  > > > To: Lewis Karl-QA3387
> > > >  > > > Cc: 'Henning Schulzrinne'; sip@lists.bell-labs.com
> > > >  > > > Subject: RE: [SIP] Attempt at summarizing current SIP drafts
> > > >  > > >
> > > >  > > >
> > > >  > > >
> > > >  > > > While I'm more than willing to believe that there
> > > >  > > > are mobility issues that SIP needs to deal with,
> > > >  > > > this paper seems to be positing SIP as the means
> > > >  > > > of initiating data sessions altogether. To my
> > > >  > > > mind, that's a rather bellheaded way of thinking
> > > >  > > > about how you do what amounts to L3 admission
> > > >  > > > control. In fact, the IETF already has an L3
> > > >  > > > admission control mechanism: RSVP. RSVP's main
> > > >  > > > advantage is that it follows actual network
> > > >  > > > topology. SIP is at a distinct disadvantage since
> > > >  > > > all it knows about is the signaling path which
> > > >  > > > in normal circumstances has nothing to do with
> > > >  > > > the actual data path.
> > > >  > > >
> > > >  > > > Maybe I'm misreading this whole paper, but it sure
> > > >  > > > looks like it to me. If my interpretation is
> > > >  > > > right, however, I'd like to know if the intention
> > > >  > > > is to signal the access routers providing the
> > > >  > > > L2/L3 bits using SIP instead of, say, COPS (or
> > > >  > > > DIAMETER). If so, I'd say that SIP truly has
> > > >  > > > arrived at becoming the new millenium's kitchen
> > > >  > > > sink if this is accepted.
> > > >  > > >
> > > >  > > >    Mike
> > > >  > > >
> > > >  > > > Lewis Karl-QA3387 writes:
> > > >  > > >  > I have just reviewed the Mobility Related drafts
> > > >  > >and am wondering if
> > > >  > > > anyone
> > > >  > > >  > is aware of the current status of
> > > >  > >draft-itsumo-sip -mobility-req-01. In
> > > >  > > >  > particular, several issues were identified such
> > > >  > >as Mobile IP not being
> > > >  > > >  > sufficient for personal mobility and location
> > > >  > >services, completing
> > > >  > > >  > registration in less than a few seconds,
> > > >  > >reconfiguration in milliseconds,
> > > >  > > >  > providing location services, support of inter
> > > >  > >domain soft-hand and secure
> > > >  > > >  > signaling. Have these issues been addressed or
> > > >  > >actively being worked?
> > > >  > > >  >
> > > >  > > >  > Karl
> > > >  > > >  >
> > > >  > > >  >
> > > >  > > >  >
> > > >  > > >  > -----Original Message-----
> > > >  > > >  > From: Henning Schulzrinne
> > > >  > [ mailto:schulzrinne@cs.columbia.edu
><mailto:schulzrinne@cs.columbia.edu> ]
> > > >  >  >  > Sent: Monday, September 25, 2000 9:20 AM
> > > >  >  >  > To: sip@lists.bell-labs.com
> > > >  >  >  > Subject: [SIP] Attempt at summarizing current SIP drafts
> > > >  >  >  >
> > > >  >  >  >
> > > >  >  >  > Given the proliferation of SIP-related drafts, I've
> > > >  > created a summary of
> > > >  >  >  > efforts at
> > > >  > http://www.cs.columbia.edu/~hgs/sip/drafts.html
><http://www.cs.columbia.edu/~hgs/sip/drafts.html> . This is
> > > >  >  >  > known to be incomplete, so I'd appreciate if you could
> > > >  > send me any
> > > >  >  >  > additions or corrections. (Jonathan Rosenberg provided
> > > >  > some of the text;
> > > >  >  >  > any mistakes or misrepresentations are mine.)
> > > >  >  >  >
> > > >  >  >  > It is fairly clear that there are a large number of drafts
> > > >  > that have not
> > > >  >  >  > changed materially for half a year or more. Maybe it's
> > > >  > time to have a WG
> > > >  >  >  > last call or two or ten...
> > > >  >  >  >
> > > >  >  >  > Henning
> > > >  >  >  > --
> > > >  >  >  > Henning Schulzrinne   http://www.cs.columbia.edu/~hgs
><http://www.cs.columbia.edu/~hgs>
> > > >  >  >  >
> > > >  >  >  >
> > > >  >  >  > _______________________________________________
> > > >  >  >  > SIP mailing list
> > > >  >  >  > SIP@lists.bell-labs.com
> > > >  >  >  > http://lists.bell-labs.com/mailman/listinfo/sip
><http://lists.bell-labs.com/mailman/listinfo/sip>
> > > >  >  >  >
> > > >  >  >  > _______________________________________________
> > > >  >  >  > SIP mailing list
> > > >  >  >  > SIP@lists.bell-labs.com
> > > >  >  >  > http://lists.bell-labs.com/mailman/listinfo/sip
><http://lists.bell-labs.com/mailman/listinfo/sip>
> > > >  >  >  >
> > > >  >  >
> > > >  >  > _______________________________________________
> > > >  >  > SIP mailing list
> > > >  >  > SIP@lists.bell-labs.com
> > > >  >  > http://lists.bell-labs.com/mailman/listinfo/sip
><http://lists.bell-labs.com/mailman/listinfo/sip>
> > > >  >  >
> > > >  >  > _______________________________________________
> > > >  >  > SIP mailing list
> > > >  >  > SIP@lists.bell-labs.com
> > > >  >  > http://lists.bell-labs.com/mailman/listinfo/sip
><http://lists.bell-labs.com/mailman/listinfo/sip>
> > > >  >  >
> > > >  >
> > > >  > _______________________________________________
> > > >  > SIP mailing list
> > > >  > SIP@lists.bell-labs.com
> > > >  > http://lists.bell-labs.com/mailman/listinfo/sip
><http://lists.bell-labs.com/mailman/listinfo/sip>
> > > >  >
> > > >  >
> > > >
> > > >_______________________________________________
> > > >SIP mailing list
> > > >SIP@lists.bell-labs.com
> > > > http://lists.bell-labs.com/mailman/listinfo/sip
><http://lists.bell-labs.com/mailman/listinfo/sip>
> > > >
> > > >_______________________________________________
> > > >SIP mailing list
> > > >SIP@lists.bell-labs.com
> > > > http://lists.bell-labs.com/mailman/listinfo/sip
><http://lists.bell-labs.com/mailman/listinfo/sip>
>
>
>_______________________________________________
>SIP mailing list
>SIP@lists.bell-labs.com
>http://lists.bell-labs.com/mailman/listinfo/sip
><http://lists.bell-labs.com/mailman/listinfo/sip>
>
>
>_______________________________________________
>SIP mailing list
>SIP@lists.bell-labs.com
>http://lists.bell-labs.com/mailman/listinfo/sip

--=====================_19056041==_.ALT-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Oct 5 14:47:15 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA04756 for ; Thu, 5 Oct 2000 14:47:14 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id F07AE4442C; Thu, 5 Oct 2000 13:47:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from pigeon.vovida.com (a98.vovida.com [209.237.8.98]) by lists.bell-labs.com (Postfix) with ESMTP id 153984433D for ; Thu, 5 Oct 2000 13:46:50 -0400 (EDT) Received: from vovida.com ([209.237.8.113]) by pigeon.vovida.com (Netscape Messaging Server 4.15) with ESMTP id G1YZVI00.Q9Q for ; Thu, 5 Oct 2000 11:40:30 -0700 Message-ID: <39DCCC97.70F90F64@vovida.com> From: Sunitha Kumar Organization: Vovida Networks X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14 i686) X-Accept-Language: en MIME-Version: 1.0 To: sip bell labs Content-Type: multipart/alternative; boundary="------------9C88C727D666E45DAD000ED8" Subject: [SIP] SIP 183 Session Progress Message Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 05 Oct 2000 11:46:48 -0700 --------------9C88C727D666E45DAD000ED8 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit This draft has expired April 2000. Does any body know, if there is ongoing work on this? thanks much -- Sunitha Kumar http://www.vovida.com --------------9C88C727D666E45DAD000ED8 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit This draft has expired April 2000. Does any body know, if there is ongoing work on this?

thanks much 

-- 
Sunitha Kumar
http://www.vovida.com
  --------------9C88C727D666E45DAD000ED8-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Oct 5 16:05:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA06112 for ; Thu, 5 Oct 2000 16:05:03 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3A44D4433D; Thu, 5 Oct 2000 15:05:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 72A6344339 for ; Thu, 5 Oct 2000 15:04:48 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id QAA05452; Thu, 5 Oct 2000 16:06:36 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Thu, 5 Oct 2000 16:01:04 -0400 Message-ID: From: Jonathan Rosenberg To: "'Sunitha Kumar'" , "'sip bell labs'" Subject: RE: [SIP] SIP 183 Session Progress Message MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 5 Oct 2000 16:00:56 -0400 -----Original Message----- >From: Sunitha Kumar [mailto:skumar@vovida.com] >Sent: Thursday, October 05, 2000 2:47 PM >To: sip bell labs >Subject: [SIP] SIP 183 Session Progress Message > > >This draft has expired April 2000. Does any body know, if there is ongoing work on this? >thanks much Since 183 is just a response code, there doesn't need to be an extension to define it; its already supported by the baseline. All we need to do is add a default reason phrase and recommended usage. This will be folded into the bis draft. The other part of the 183 draft, the session header, has also been folded into the bis draft as part of the content-disposition header. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Oct 5 16:26:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA06354 for ; Thu, 5 Oct 2000 16:26:03 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E04334433D; Thu, 5 Oct 2000 15:26:01 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 23F4444339 for ; Thu, 5 Oct 2000 15:25:05 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id QAA05800; Thu, 5 Oct 2000 16:26:57 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Thu, 5 Oct 2000 16:21:24 -0400 Message-ID: From: Jonathan Rosenberg To: "'Joshua Moloney'" , "'Jon.Peterson@Level3.com'" Cc: "'sip@lists.bell-labs.com'" Subject: RE: [SIP] SIP ISUP MIME draft MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C02F09.D4FD684A" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 5 Oct 2000 16:21:17 -0400 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_01C02F09.D4FD684A Content-Type: text/plain; charset="iso-8859-1" A rose by any other name.... It shouldn't be session. signal, signaling, sig, whatever. I propose that the author of the draft pick something and let us know. -Jonathan R. Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com -----Original Message----- From: Joshua Moloney [mailto:jmoloney@nortelnetworks.com] Sent: Thursday, October 05, 2000 6:25 AM To: 'Jon.Peterson@Level3.com' Cc: sip@lists.bell-labs.com Subject: RE: [SIP] SIP ISUP MIME draft Sorry to barge in, guys. I like the idea of having this new disposition type, and although 'signal' is better than session, I reckon 'signalling' would be better still. Sorry to be picky, but I just can't help it! Josh Moloney Nortel Networks -----Original Message----- From: Jon.Peterson@Level3.com [SMTP:Jon.Peterson@Level3.com] Sent: 05 October 2000 00:58 To: jdrosen@dynamicsoft.com; achoksi@vovida.com; Ong, Lyndon Cc: sip@lists.bell-labs.com Subject: RE: [SIP] SIP ISUP MIME draft Well, 'session' seemed better than any of the other options listed in the bis, anyway. I suppose 'session' would then refer exclusively to SDP? It was be nice if the disposition-type used for ISUP and QSIG could be the same, and could cover any other encapsulated signals from other protocols that are used by interworking UAs, at the very least. Perhaps 'signal' as a disposition-type? Jon Peterson Level(3) Communications -----Original Message----- From: Jonathan Rosenberg [ mailto:jdrosen@dynamicsoft.com ] Sent: Wednesday, October 04, 2000 5:02 PM To: Peterson, Jon; 'achoksi@vovida.com'; 'long@nortelnetworks.com' Cc: 'sip@lists.bell-labs.com' Subject: RE: [SIP] SIP ISUP MIME draft > -----Original Message----- > From: Jon.Peterson@Level3.com [ mailto:Jon.Peterson@Level3.com ] > Sent: Wednesday, October 04, 2000 3:38 PM > To: achoksi@vovida.com; long@nortelnetworks.com > Cc: sip@lists.bell-labs.com > Subject: RE: [SIP] SIP ISUP MIME draft > > > > 2. It is optional, but it has a default value as outlined in > rfc2543 which > we are not overloading - namely that the content should be > considered a > mandatory content (handling=required), and that in requests and 2xx > responses 'session' is the assumed disposition for > backwards-compatibility. > > However, rfc2543bis-02 also specifies that if the MIME type > doesn't have a > default disposition, then the disposition should be assumed > to be 'render'. > This seems to conflict with the backwards compatibility > mechanism described > above, and someone should probably fix that. I'd vote for > mainaining the > latter statute. You are right, this seems to be contradictory. I think the former one is sort of trying to say that the default content disposition value for SDP is "session". I agree that the latter statute is better. > > Now, that much said, the ISUP MIME draft today doesn't > specify a default > content disposition for the ISUP MIME type. As the bis asks > MIME types to > have a default, I think we probably should define one, and I > think it should > be 'session' for ISUP. I suppose it would be the same for > QSIG... Lyndon, > have any feelings about that? No, I don't think session is write. This is not a session description. It is describing extra information used to support signaling interworking. I think a new content-disposition makes sense here. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip ------_=_NextPart_001_01C02F09.D4FD684A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [SIP] SIP ISUP MIME draft
A = rose by any=20 other name....
 
It = shouldn't be=20 session. signal, signaling, sig, whatever. I propose that the author of = the=20 draft pick something and let us know.
 
-Jonathan=20 R.
 

Jonathan D.=20 Rosenberg          &nb= sp;           =20 72 Eagle Rock Ave.
Chief=20 Scientist          &nb= sp;           &nb= sp;     =20 First=20 Floor
dynamicsoft        &nbs= p;           &nbs= p;           =20 East Hanover, NJ=20 07936
jdrosen@dynamicsoft.com      &nbs= p;           &nbs= p; =20 FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen   = ;     =20 PHONE: (732) 741-7244
http://www.dynamicsoft.com

-----Original Message-----
From: Joshua Moloney=20 [mailto:jmoloney@nortelnetworks.com]
Sent: Thursday, = October 05,=20 2000 6:25 AM
To: 'Jon.Peterson@Level3.com'
Cc:=20 sip@lists.bell-labs.com
Subject: RE: [SIP] SIP ISUP MIME=20 draft

Sorry to barge in, = guys. I like the=20 idea of having this new disposition type, and although 'signal' is = better than=20 session, I reckon 'signalling' would be better still. Sorry to be = picky, but I=20 just can't help it!

Josh Moloney =
Nortel Networks

    -----Original Message----- =
    From:       Jon.Peterson@Level3.com = [SMTP:Jon.Peterson@Level3.com]=20
    Sent:   = 05 October 2000 00:58
    To:     jdrosen@dynamicsoft.com; achoksi@vovida.com; Ong, Lyndon=20
    Cc:    =20 sip@lists.bell-labs.com =
    Subject:            = RE: [SIP] SIP ISUP MIME draft


    Well, 'session' seemed better than = any of the=20 other options listed in the
    bis, anyway.=20 I suppose 'session' would then refer exclusively to SDP? =

    It was be nice if the = disposition-type used for=20 ISUP and QSIG could be the
    same, and=20 could cover any other encapsulated signals from other = protocols=20
    that are used by interworking UAs, = at the very=20 least. Perhaps 'signal' as a
    disposition-type?

    Jon Peterson
    Level(3) Communications

    -----Original Message----- =
    From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]=20
    Sent: Wednesday, October 04, 2000 = 5:02 PM=20
    To: Peterson, Jon; = 'achoksi@vovida.com';=20 'long@nortelnetworks.com'
    Cc:=20 'sip@lists.bell-labs.com'
    Subject: RE:=20 [SIP] SIP ISUP MIME draft





    > -----Original = Message-----
    > From: Jon.Peterson@Level3.com [mailto:Jon.Peterson@Level3.com]=20
    > Sent: Wednesday, October 04, = 2000 3:38=20 PM
    > To: = achoksi@vovida.com;=20 long@nortelnetworks.com
    > = Cc:=20 sip@lists.bell-labs.com
    > = Subject: RE:=20 [SIP] SIP ISUP MIME draft
    >=20
    >
    >
    > 2. It is = optional, but=20 it has a default value as outlined in
    > rfc2543 which
    > we are not=20 overloading - namely that the content should be
    > considered a
    > mandatory=20 content (handling=3Drequired), and that in requests and 2xx =
    > responses 'session' is the assumed = disposition for=20
    > = backwards-compatibility.=20
    >
    >=20 However, rfc2543bis-02 also specifies that if the MIME type =
    > doesn't have a
    > default disposition, then the disposition should be = assumed=20
    > to be 'render'. =
    > This seems to conflict with the = backwards=20 compatibility
    > mechanism = described
    > above, and = someone should=20 probably fix that. I'd vote for
    >=20 mainaining the
    > latter=20 statute.

    You are right, this seems to be = contradictory. I=20 think the former
    one is sort = of trying to=20 say that the default content disposition
    value for SDP is "session". I agree that the latter = statute is=20 better.


    >
    > Now,=20 that much said, the ISUP MIME draft today doesn't
    > specify a default
    > content disposition for the ISUP MIME type. As the = bis asks=20
    > MIME types to =
    > have a default, I think we probably = should define=20 one, and I
    > think it = should=20
    > be 'session' for ISUP. I = suppose it would=20 be the same for
    > QSIG... = Lyndon,
    > have any = feelings about=20 that?

    No, I don't think session is write. = This is not a=20 session description. It is
    describing
    extra = information used=20 to support signaling interworking. I think a new
    content-disposition
    makes sense=20 here.
    ---
    Jonathan D.=20 = Rosenberg          &nb= sp;           =20 72 Eagle Rock Ave.
    Chief=20 = Scientist          &nb= sp;           &nb= sp;     =20 First Floor
    dynamicsoft        &nbs= p;           &nbs= p;           =20 East Hanover, NJ 07936
    jdrosen@dynamicsoft.com      &nbs= p;           &nbs= p; =20 FAX:   (973) 952-5050
    http://www.cs.columbia.edu/~jdrosen   = ;     =20 PHONE: (973) 952-5000
    http://www.dynamicsoft.com

    _______________________________________________ =
    SIP mailing list
    SIP@lists.bell-labs.com
    http://lists.bell-labs.com/mailman/listinfo/sip=20

    _______________________________________________ =
    SIP mailing list
    SIP@lists.bell-labs.com
    http://lists.bell-labs.com/mailman/listinfo/sip=20

------_=_NextPart_001_01C02F09.D4FD684A-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Oct 5 16:36:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA06483 for ; Thu, 5 Oct 2000 16:36:03 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 996084443D; Thu, 5 Oct 2000 15:31:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 372594443C for ; Thu, 5 Oct 2000 15:30:12 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id QAA05870; Thu, 5 Oct 2000 16:32:07 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Thu, 5 Oct 2000 16:26:34 -0400 Message-ID: From: Jonathan Rosenberg To: "'Joshua_Fox@vocaltec.com'" , "'sip@lists.bell-labs.com'" , "'Cliff.Harris@nokia.com'" Subject: RE: [SIP] centralized vs. decentralized architectures MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 5 Oct 2000 16:26:26 -0400 > -----Original Message----- > From: Joshua_Fox@vocaltec.com [mailto:Joshua_Fox@vocaltec.com] > Sent: Thursday, October 05, 2000 1:36 AM > To: sip@lists.bell-labs.com; Cliff.Harris@nokia.com > Subject: RE: [SIP] centralized vs. decentralized architectures > > > > > >Why doesn't a B2BUA provide true anonymity? By the way, I'm > curious about > >why anonymity is so important: are there legitimate reasons > for people to > >make calls anonymously? > > When I mentioned "anonymity", I wasn't referring to the idea > of keepingyour > human identity secret; I meant that for convenience, the user > should not > have to provide a network identifier before making a call. > There are indeed > legitimate reasons for people to make calls anonymously in this > sense--that's what we do when we call from a pay phone. Of > course, a pay > phone has an E.164 number assigned to it And a sip payphone would have a sip URL assigned to it. >--but what would you > do if anyone > could instantly download and instantiate as many "pay phones" > as they want? How could they? Preumably network elements that provide service to this payphone would authenticate it. If I assume such an identity in my SIP client, I'd still need to authenticate myself, and I wouldn't be able to. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Oct 5 16:47:19 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA06617 for ; Thu, 5 Oct 2000 16:47:18 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 278BF4443C; Thu, 5 Oct 2000 15:47:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 5253144339 for ; Thu, 5 Oct 2000 15:46:47 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id QAA06041; Thu, 5 Oct 2000 16:48:27 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Thu, 5 Oct 2000 16:42:54 -0400 Message-ID: From: Jonathan Rosenberg To: "'Sean Olson'" , "'James Undery'" Cc: "'Henning Schulzrinne'" , "'sip@lists.bell-labs.com'" Subject: RE: [SIP] Registering non-SIP URIs MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 5 Oct 2000 16:42:48 -0400 It is up to the registrar to choose a time. It can pick whatever it wants and return it in the response. The issue is if it doesn't return anything, the default is one hour. It is fairly arbitrary. -Jonathan R. > -----Original Message----- > From: Sean Olson [mailto:sean.olson@ericsson.com] > Sent: Wednesday, October 04, 2000 7:33 AM > To: James Undery > Cc: Henning Schulzrinne; sip@lists.bell-labs.com > Subject: Re: [SIP] Registering non-SIP URIs > > > While we're on the topic, I'm curious about the statement in > this section > "If neither of these mechanisms is used, SIP URIs are assumed > to expire in > one hour" > > Why the arbitrary "one hour"? Shouldn't this be up to the > registrar and > conveyed in the > Expires: header in the 200 OK response? > > -- > Sean Olson > > James Undery wrote: > > > Hi, > > I've just been re-reading the latest draft and have noted an > > important part of registering non-SIP URIs is only > mentioned in passing, > > section 6.14 the paragraph about 'REGISTER requests' says > > > > "Other [non-SIP] URI schemes have no expiration times." > > > > This would be good to mention in section 4.2.6 along with > the rest of the > > REGISTER details. > > > > James Undery > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Oct 5 20:16:09 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA09291 for ; Thu, 5 Oct 2000 20:16:07 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 608EA4441C; Thu, 5 Oct 2000 19:16:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14]) by lists.bell-labs.com (Postfix) with ESMTP id C7B714433B for ; Thu, 5 Oct 2000 19:15:45 -0400 (EDT) Received: from zrchb200.us.nortel.com (actually zrchb200) by smtprch1.nortel.com; Thu, 5 Oct 2000 16:29:37 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Thu, 5 Oct 2000 16:29:13 -0500 Message-ID: <36FA02BD7083D411BC9E0000F8073E43D5FB15@crchy271.us.nortel.com> From: "Brian Stucker" To: mhammer@cisco.com, sip@lists.bell-labs.com MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C02F13.49C2EF50" Subject: [SIP] SIP Mobility Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 5 Oct 2000 16:29:05 -0500 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_01C02F13.49C2EF50 Content-Type: text/plain; charset="iso-8859-1" Email problems necessitates clipping the original response a bit, sorry. Yes, for new sessions, it's not as big of a deal. The race conditions regarding the REGISTER are handled fairly well with the CSeq. My main point of concern isn't with new sessions though. It's with session muting problems associated with re-INVITEs. If it takes a couple of seconds on a network to get a SIP session setup, then you're going to have a mute period of a couple of seconds which is going to be very audible no matter what sort of codec you use. On very high-speed mobile networks (which I believe may have been the primary focus of development thus far), that session latentcy is a lot lower, so it's not as big of a deal. But those levels of bandwidth aren't going to be widely available to the public for a long time. They haven't even started the license allocation yet here in the states. If you had a 1 second mute on your cell phone every time it handed off, you'd quickly stop moving around very much while you were in a conversation. That's why I refer to SIP as a relatively "slow" protocol because everyone involved in the network has to get the change propagated to them, and then acknowledge it in order for it to take affect. What I'm referring to places no burden on the proxy or any SIP entity. I'm suggesting that it would be better to RECOMMEND that at all where possible, that a layer 3 solution that is completely transparent to SIP (and thus the proxy, the UA, and the registrar) be used. Now, you could use an INFO from the affected UA to tell anyone that he's in a session with to switch their endpoint information, and that would cut down the latentcy quite considerably, but it wouldn't eliminate it. Brian --- From: hammer michael: Brian, My main point was that the scope of control of the transport network extends only as far as the end of the transport connection. If that connection bypasses the proxy, then the proxy would not be informed of the subsequent location of the user. If the proxy was one of the end-points, then the flow of messages would probably keep in informed. But it is best left to the transport network to maintain those connections once established, for all the reasons you pointed out, i.e. handoffs every few seconds. But the question still remains in the bypass situation, as in the function of an HLR, if a new person were to want to contact the moving user, how does the proxy know where he is at any given time. (As you know, from the VLR on down to the radio site, the serving network maintains the call path until the call ends. At which point the user re-registers in the new network. The home network has no idea until that time.) If the user gets handed-off to another network operator and uses a new IP address: - Either the user tells the proxy directly by message to/through the proxy, or - the user tells some registration device (which may be at the network layer), or - the network nodes inform the registration device, and the proxy pulls it from there. Else, as far as the proxy is concerned, the user is incommunicado. Mike ------_=_NextPart_001_01C02F13.49C2EF50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable SIP Mobility

Email problems necessitates clipping = the original response a bit, sorry.

Yes, for new sessions, it's not as big = of a deal. The race conditions regarding the REGISTER are handled = fairly well with the CSeq. My main point of concern isn't with new = sessions though. It's with session muting problems associated with = re-INVITEs.

If it takes a couple of seconds on a = network to get a SIP session setup, then you're going to have a mute = period of a couple of seconds which is going to be very audible no = matter what sort of codec you use. On very high-speed mobile networks = (which I believe may have been the primary focus of development thus = far), that session latentcy is a lot lower, so it's not as big of a = deal. But those levels of bandwidth aren't going to be widely available = to the public for a long time. They haven't even started the license = allocation yet here in the states. If you had a 1 second mute on your = cell phone every time it handed off, you'd quickly stop moving around = very much while you were in a conversation.

That's why I refer to SIP as a = relatively "slow" protocol because everyone involved in the = network has to get the change propagated to them, and then acknowledge = it in order for it to take affect. What I'm referring to places no = burden on the proxy or any SIP entity. I'm suggesting that it would be = better to RECOMMEND that at all where possible, that a layer 3 solution = that is completely transparent to SIP (and thus the proxy, the UA, and = the registrar) be used.

Now, you could use an INFO from the = affected UA to tell anyone that he's in a session with to switch their = endpoint information, and that would cut down the latentcy quite = considerably, but it wouldn't eliminate it.

Brian


---
From: hammer michael:
Brian,

My main point was that the scope of control of the transport network = extends only as far as the end of the transport connection. If that = connection bypasses the proxy, then the proxy would not be informed of = the subsequent location of the user. If the proxy was one of the = end-points, then the flow of messages would probably keep in informed. = But it is best left to the transport network to maintain those = connections once established, for all the reasons you pointed out, i.e. = handoffs every few seconds.

But the question still remains in the bypass situation, as in the = function of an HLR, if a new person were to want to contact the moving = user, how does the proxy know where he is at any given time. (As you = know, from the VLR on down to the radio site, the serving network = maintains the call path until the call ends. At which point the user = re-registers in the new network. The home network has no idea until = that time.)

If the user gets handed-off to another network operator and uses a new = IP address:
- Either the user tells the proxy directly by message to/through the = proxy, or
- the user tells some registration device (which may be at the network = layer), or
- the network nodes inform the registration device, and the proxy pulls = it from there.

Else, as far as the proxy is concerned, the user is incommunicado.

Mike

------_=_NextPart_001_01C02F13.49C2EF50-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Oct 6 00:26:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA13086 for ; Fri, 6 Oct 2000 00:26:04 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 62B174440E; Thu, 5 Oct 2000 23:26:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from hd2.dot.net.in (hd2.vsnl.net.in [202.54.30.2]) by lists.bell-labs.com (Postfix) with ESMTP id 1E18A4433B for ; Thu, 5 Oct 2000 23:25:28 -0400 (EDT) Received: from bigboy ([210.212.215.132]) by hd2.dot.net.in (8.8.8/8.8.8) with SMTP id JAA12766; Fri, 6 Oct 2000 09:55:31 +0530 (IST) Message-ID: <001a01c02fae$1fbe15e0$1200a8c0@bigboy> From: "farhan" To: "Pauline Wong" , "sip" References: <20001001102249.10854.qmail@web313.mail.yahoo.com> 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 Subject: [SIP] free sip ids on hotfoon.com Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 5 Oct 2000 10:45:51 -0600 Content-Transfer-Encoding: 7bit a few enquiries on the list show that people want to establish their own sip ids. well, at hotfoon you can have them for free. hotfoon is runnning a free redirect server at hotfoon.com:5060. It is a trivial implementation that returns a 302 for those users who are currently REGISTER-ed. There is no help for the server available on the web site hotfoon.com, it is something that i slinked in while the suits were looking away. write to me for any help. In order to be able to create your own sip userid, you need to send a register message with password specified in both To: as well as Contact: headers. After that each time you update your REGISTERation, you will have to supply the password again within your Contact: header. you sip id should be in hotfoon domain like mailto:sip:farhan@hotfoon.com The server cannot handle folded lines. I had patched it together in a few hours to setup something i could test my own UAs against. May I add that the log of your messages is created on my server. This was done so that I could have a trace of the server's behaviour. hope this helps. - farhan farhan@hotfoon.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Oct 6 01:31:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA16832 for ; Fri, 6 Oct 2000 01:31:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 35E5A4444F; Fri, 6 Oct 2000 00:31:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from web1401.mail.yahoo.com (web1401.mail.yahoo.com [128.11.23.165]) by lists.bell-labs.com (Postfix) with SMTP id E32284433B for ; Fri, 6 Oct 2000 00:30:06 -0400 (EDT) Received: (qmail 13568 invoked by uid 60001); 6 Oct 2000 05:30:03 -0000 Message-ID: <20001006053003.13567.qmail@web1401.mail.yahoo.com> Received: from [206.82.141.26] by web1401.mail.yahoo.com; Thu, 05 Oct 2000 22:30:03 PDT From: zeeshan razzaque To: sip@lists.bell-labs.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [SIP] Gateway question Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 5 Oct 2000 22:30:03 -0700 (PDT) If a SIP Gateway caters to a certain place(city), what number(s) does it register and which registration server does it register with? Does it register with the city code? Does it register with just one Registrar or multicasts the REGISTER Request? Plus does a Gateway act as a collection of multiple User Agents? I guess it has nothing more to do than Requesting and responding to requests...it does not need to act as redirect or proxy server. Am I right on this one? Zeeshan. __________________________________________________ Do You Yahoo!? Yahoo! Photos - 35mm Quality Prints, Now Get 15 Free! http://photos.yahoo.com/ _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Oct 6 06:11:12 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA27208 for ; Fri, 6 Oct 2000 06:11:11 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 70DC94441D; Fri, 6 Oct 2000 05:09:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from zrtps06u.us.nortel.com (unknown [47.140.48.52]) by lists.bell-labs.com (Postfix) with ESMTP id 093CD4433B for ; Fri, 6 Oct 2000 05:08:51 -0400 (EDT) Received: from qhars002.nortel.com (zhars00t.europe.nortel.com [47.101.112.102]) by zrtps06u.us.nortel.com (8.11.0/8.11.0) with ESMTP id e96A8af19280 for ; Fri, 6 Oct 2000 06:08:37 -0400 (EDT) Received: from znsgd00t.europe.nortel.com (actually znsgd00t) by qhars002.nortel.com; Fri, 6 Oct 2000 11:08:24 +0100 Received: by znsgd00t.europe.nortel.com with Internet Mail Service (5.5.2652.35) id <4H9RPVCY>; Fri, 6 Oct 2000 11:08:22 +0100 Message-ID: <61ABD11436FED21192440000F81F3E360304C2F9@nwcwi1a.europe.nortel.com> From: "Mark Watson" To: "'sip@lists.bell-labs.com'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C02F7D.4C40B360" Subject: [SIP] FW: Delaying alerting at UAS Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 6 Oct 2000 11:07:56 +0100 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_01C02F7D.4C40B360 Content-Type: text/plain; charset="iso-8859-1" Hi, Is it possible for a UAC to request that the UAS delays alerting of the user until a subsequent 'go ahead' message is sent from UAC to UAS ?? For example, if the UAC has some action it requires to take before full session commencement, but it only wants to take this action if the required user can be sucessfully located and is available ? The UAC action might be some kind of local resource reservation or an indication to the calling user etc. Can this be done with SIP as it stands ? I looked in draft-manyfolks-sip-resource, but there does not appear to be any way for the UAC to *require* that the UAS delay alerting until receipt of confirmation from the UAC - the behaviour is optional on the part of the UAS. Regards, Mark Watson Nortel Networks ------_=_NextPart_001_01C02F7D.4C40B360 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable FW: Delaying alerting at UAS

Hi,

Is it possible for a UAC to request that the UAS = delays alerting of the user until a subsequent 'go ahead' message is = sent from UAC to UAS ??

For example, if the UAC has some action it requires = to take before full session commencement, but it only wants to take = this action if the required user can be sucessfully located and is = available ?

The UAC action might be some kind of local resource = reservation or an indication to the calling user etc.

Can this be done with SIP as it stands ?

I looked in draft-manyfolks-sip-resource, but there = does not appear to be any way for the UAC to *require* that the UAS = delay alerting until receipt of confirmation from the UAC - the = behaviour is optional on the part of the UAS.

Regards,

Mark Watson
Nortel Networks

------_=_NextPart_001_01C02F7D.4C40B360-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Oct 6 07:43:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA29099 for ; Fri, 6 Oct 2000 07:43:02 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9F47C4435F; Fri, 6 Oct 2000 06:43:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lists.bell-labs.com (Postfix) with ESMTP id 311DB4433B for ; Fri, 6 Oct 2000 06:42:16 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id e96Bg7t13926; Fri, 6 Oct 2000 13:42:07 +0200 (MEST) 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 OAA13566; Fri, 6 Oct 2000 14:42:06 +0300 (EET DST) Received: from localhost (root@localhost) by greymse1.lmf.ericsson.se (8.9.3 (PHNE_18979)/8.8.6) with ESMTP id OAA04351; Fri, 6 Oct 2000 14:42:05 +0300 (EETDST) From: Gonzalo.Camarillo@lmf.ericsson.se X-OpenMail-Hops: 1 Message-Id: In-Reply-To: <61ABD11436FED21192440000F81F3E360304C2F9@nwcwi1a.europe.nortel> Subject: [SIP] FW: Delaying alerting at UAS MIME-Version: 1.0 To: mwatson@nortelnetworks.com Cc: sip@lists.bell-labs.com Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline ;Creation-Date="Fri, 6 Oct 2000 14:32:49 +0300" ;Modification-Date="Fri, 6 Oct 2000 14:41:59 +0300" Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 6 Oct 2000 14:42:02 +0300 Content-Transfer-Encoding: 7bit Hi, This issue was presented in the last IETF meeting. http://www.softarmor.com/sipwg/meets/IETF48/slides/pres-camarillo-3pccprecon-sip -48.ppt I have submitted a draft about it. I sent it to the IETF a couple of days ago, so it will be available very soon. It is called: draft-camarillo-manyfolks-confirm-00.txt It outlines how to ask the UAS to wait until it receives a COMET from the UAC in order to go on with the session establishment. The draft contains an example related to third party call control using SIP, but as you said, it is a general mechanism that can be employed in several situations. Best regards, Gonzalo >Hi, > >Is it possible for a UAC to request that the UAS delays alerting of the user >until a subsequent 'go ahead' message is sent from UAC to UAS ?? > >For example, if the UAC has some action it requires to take before full session >commencement, but it only wants to take this action if the required user can be > >sucessfully located and is available ? > > >The UAC action might be some kind of local resource reservation or an >indication to the calling user etc. > > >Can this be done with SIP as it stands ? > > >I looked in draft-manyfolks-sip-resource, but there does not appear to be any >way for the UAC to *require* that the UAS delay alerting until receipt of >confirmation from the UAC - the behaviour is optional on the part of the UAS. > > >Regards, > > >Mark Watson >Nortel Networks _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Oct 6 08:37:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA00385 for ; Fri, 6 Oct 2000 08:37:02 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id CA7404441C; Fri, 6 Oct 2000 07:37:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from web1401.mail.yahoo.com (web1401.mail.yahoo.com [128.11.23.165]) by lists.bell-labs.com (Postfix) with SMTP id A01324433B for ; Fri, 6 Oct 2000 07:36:14 -0400 (EDT) Received: (qmail 13567 invoked by uid 60001); 6 Oct 2000 12:36:10 -0000 Message-ID: <20001006123610.13566.qmail@web1401.mail.yahoo.com> Received: from [206.82.141.26] by web1401.mail.yahoo.com; Fri, 06 Oct 2000 05:36:10 PDT From: zeeshan razzaque To: sip@lists.bell-labs.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [SIP] SIP gateway and PINT Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 6 Oct 2000 05:36:10 -0700 (PDT) I asked a question earlier on about the SIP gateway. Is it a good idea to use PINT(rfc 2848) to implement the gateway? How does it affect the IP signaling part handled by SIP or does it only deal with the PSTN side? Any suggestions here? Zeeshan. __________________________________________________ Do You Yahoo!? Yahoo! Photos - 35mm Quality Prints, Now Get 15 Free! http://photos.yahoo.com/ _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Oct 6 09:04:48 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA02553 for ; Fri, 6 Oct 2000 09:04:48 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id DA6414440E; Fri, 6 Oct 2000 08:04:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from qnsgs000.nortel.com (qnsgs000.nortelnetworks.com [47.211.0.31]) by lists.bell-labs.com (Postfix) with ESMTP id EF9F64433B for ; Fri, 6 Oct 2000 08:03:24 -0400 (EDT) Received: from zhard00m.europe.nortel.com (actually zhard00m) by qnsgs000.nortel.com; Fri, 6 Oct 2000 13:49:58 +0100 Received: by zhard00m.europe.nortel.com with Internet Mail Service (5.5.2652.35) id <4JRFHGL5>; Fri, 6 Oct 2000 13:49:46 +0100 Message-ID: <61ABD11436FED21192440000F81F3E360304C2FF@nwcwi1a.europe.nortel.com> From: "Mark Watson" To: "'Gonzalo.Camarillo@lmf.ericsson.se'" Cc: sip@lists.bell-labs.com Subject: RE: [SIP] FW: Delaying alerting at UAS MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C02F93.E51301E0" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 6 Oct 2000 13:49:41 +0100 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_01C02F93.E51301E0 Content-Type: text/plain; charset="ISO-8859-1" Thanks, this seems to answer the question - I look forward to reading the draft. If I understand rightly, the idea is one of precoditions of which the UAC is aware, but the UAS is not, so you need to force the UAS to wait for the COMET. I think this would need to be a session layer indication (i.e. in SIP, not in the SDP) - the precondition is not necessarily related to the media stream between UAC and UAS - in fact the UAS is never aware of what the precondition actually is. I had a further questions about the use of PRACKs to carry SDP in the manyfolks draft. (Apologies in advance if this has already been discussed too!). I though that the purpose of PRACKs was to support reliability of provisional responses. If this is their purpose then of course they are not required if running over reliable transport (TCP and SCTP). So, how can they be used for carrying information as well ? Regards, Mark Watson Nortel Networks -----Original Message----- From: Gonzalo.Camarillo@lmf.ericsson.se [mailto:Gonzalo.Camarillo@lmf.ericsson.se] Sent: 06 October 2000 12:42 To: Watson, Mark Cc: sip@lists.bell-labs.com Subject: [SIP] FW: Delaying alerting at UAS Hi, This issue was presented in the last IETF meeting. http://www.softarmor.com/sipwg/meets/IETF48/slides/pres-camarillo-3pccprecon -sip -48.ppt I have submitted a draft about it. I sent it to the IETF a couple of days ago, so it will be available very soon. It is called: draft-camarillo-manyfolks-confirm-00.txt It outlines how to ask the UAS to wait until it receives a COMET from the UAC in order to go on with the session establishment. The draft contains an example related to third party call control using SIP, but as you said, it is a general mechanism that can be employed in several situations. Best regards, Gonzalo >Hi, > >Is it possible for a UAC to request that the UAS delays alerting of the user >until a subsequent 'go ahead' message is sent from UAC to UAS ?? > >For example, if the UAC has some action it requires to take before full session >commencement, but it only wants to take this action if the required user can be > >sucessfully located and is available ? > > >The UAC action might be some kind of local resource reservation or an >indication to the calling user etc. > > >Can this be done with SIP as it stands ? > > >I looked in draft-manyfolks-sip-resource, but there does not appear to be any >way for the UAC to *require* that the UAS delay alerting until receipt of >confirmation from the UAC - the behaviour is optional on the part of the UAS. > > >Regards, > > >Mark Watson >Nortel Networks _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip ------_=_NextPart_001_01C02F93.E51301E0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: [SIP] FW: Delaying alerting at UAS

Thanks, this seems to answer the question - I look = forward to reading the draft. If I understand rightly, the idea is one = of precoditions of which the UAC is aware, but the UAS is not, so you = need to force the UAS to wait for the COMET.

I think this would need to be a session layer = indication (i.e. in SIP, not in the SDP) - the precondition is not = necessarily related to the media stream between UAC and UAS - in fact = the UAS is never aware of what the precondition actually is.

I had a further questions about the use of PRACKs to = carry SDP in the manyfolks draft. (Apologies in advance if this has = already been discussed too!).

I though that the purpose of PRACKs was to support = reliability of provisional responses. If this is their purpose then of = course they are not required if running over reliable transport (TCP = and SCTP). So, how can they be used for carrying information as well = ?

Regards,

Mark Watson
Nortel Networks





-----Original Message-----
From: Gonzalo.Camarillo@lmf.ericsson.se
[mailto:Gonzalo.Camaril= lo@lmf.ericsson.se]
Sent: 06 October 2000 12:42
To: Watson, Mark
Cc: sip@lists.bell-labs.com
Subject: [SIP] FW: Delaying alerting at UAS


Hi,

This issue was presented in the last IETF = meeting.
http://www.softarmor.com/sipwg/meets/IETF48/slides/pre= s-camarillo-3pccprecon-sip
-48.ppt

I have submitted a draft about it. I sent it to the = IETF a
couple of days ago,
so it will be available very soon. It is called: =
draft-camarillo-manyfolks-confirm-00.txt

It outlines how to ask the UAS to wait until it = receives a
COMET from the UAC in
order to go on with the session = establishment.

The draft contains an example related to third party = call
control using SIP, but
as you said, it is a general mechanism that can be = employed in
several
situations.

Best regards,

Gonzalo


>Hi,
>
>Is it possible for a UAC to request that the UAS = delays
alerting of the user
>until a subsequent 'go ahead' message is sent = from UAC to UAS
??
>
>For example, if the UAC has some action it = requires to take
before full session
>commencement, but it only wants to take this = action if the
required user can be
>
>sucessfully located and is available ?
>
>
>The UAC action might be some kind of local = resource
reservation or an
>indication to the calling user etc.
>
>
>Can this be done with SIP as it stands ?
>
>
>I looked in draft-manyfolks-sip-resource, but = there does not
appear to be any
>way for the UAC to *require* that the UAS delay = alerting until
receipt of
>confirmation from the UAC - the behaviour is = optional on the
part of the UAS.
>
>
>Regards,
>
>
>Mark Watson
>Nortel Networks


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip

------_=_NextPart_001_01C02F93.E51301E0-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Oct 6 10:43:09 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA05444 for ; Fri, 6 Oct 2000 10:43:08 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C60EE4433D; Fri, 6 Oct 2000 09:43:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 6B8984433B for ; Fri, 6 Oct 2000 09:42:47 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id KAA10086; Fri, 6 Oct 2000 10:44:31 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Fri, 6 Oct 2000 10:38:57 -0400 Message-ID: From: Jonathan Rosenberg To: "'Mark Watson'" , "'Gonzalo.Camarillo@lmf.ericsson.se'" Cc: "'sip@lists.bell-labs.com'" Subject: RE: [SIP] FW: Delaying alerting at UAS MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 6 Oct 2000 10:38:56 -0400 -----Original Message----- >From: Mark Watson [mailto:mwatson@nortelnetworks.com] >Sent: Friday, October 06, 2000 8:50 AM >To: 'Gonzalo.Camarillo@lmf.ericsson.se' >Cc: sip@lists.bell-labs.com >Subject: RE: [SIP] FW: Delaying alerting at UAS > > >Thanks, this seems to answer the question - I look forward to reading the draft. If I >understand rightly, the idea is one of precoditions of which the UAC is aware, but the UAS >is not, so you need to force the UAS to wait for the COMET. >I think this would need to be a session layer indication (i.e. in SIP, not in the SDP) - >the precondition is not necessarily related to the media stream between UAC and UAS - in >fact the UAS is never aware of what the precondition actually is. >I had a further questions about the use of PRACKs to carry SDP in the manyfolks draft. >(Apologies in advance if this has already been discussed too!). >I though that the purpose of PRACKs was to support reliability of provisional responses. If >this is their purpose then of course they are not required if running over reliable >transport (TCP and SCTP). So, how can they be used for carrying information as well ? No, that is not correct. As there can be many hops along the way, each with different transports, no one entity can know whether end to end tcp is used or not. As a result, PRACK is always used for reliable provisional responses, independent of the transport. -Jonathan R. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Oct 6 11:04:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA05886 for ; Fri, 6 Oct 2000 11:04:02 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 486474433D; Fri, 6 Oct 2000 10:04:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 1A96E4433B for ; Fri, 6 Oct 2000 10:03:16 -0400 (EDT) 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 LAA26450 for ; Fri, 6 Oct 2000 11:03:09 -0400 (EDT) Message-ID: <39DDE9AE.8E5FB901@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] New draft on SIP registration Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 06 Oct 2000 11:03:10 -0400 Content-Transfer-Encoding: 7bit I've written a quick draft on some of the issues related to how to do SIP registration when "visiting" networks. I would appreciate feedback. The draft does not propose new SIP extensions, except for a possible Digest parameter to increase registration security. The draft is http://www.ietf.org/internet-drafts/draft-schulzrinne-sip-register-00.txt -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Oct 6 11:55:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA06978 for ; Fri, 6 Oct 2000 11:55:02 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id BE31A4433D; Fri, 6 Oct 2000 10:55:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from esebh02nok.ntc.nokia.com (esebh02nok.ntc.nokia.com [131.228.118.151]) by lists.bell-labs.com (Postfix) with ESMTP id 947F94433B for ; Fri, 6 Oct 2000 10:54:27 -0400 (EDT) Received: by esebh02nok with Internet Mail Service (5.5.2650.10) id ; Fri, 6 Oct 2000 18:54:22 +0300 Message-ID: From: aki.niemi@nokia.com To: sip@lists.bell-labs.com Cc: schulzrinne@cs.columbia.edu Subject: RE: [SIP] New draft on SIP registration MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.10) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 6 Oct 2000 18:54:21 +0300 Hi, There seems to be a discrepancy between the SIP registration draft and SIP RFC (draft-ietf-sip-rfc2543bis-02.pdf) draft-schulzrinne-sip-register-00.txt says that: "The Authentication-Info header field contains a response digest, but it only protects the response entity body, not header fields." But, draft-ietf-sip-rfc2543bis-02.pdf says in chapter 14.3.: "The Authentication-Info and Proxy-Authentication-Info fields are not used in SIP" So basically Digest as an authentication scheme works even worse with SIP than it does with HTTP? And if I truly want security in my REGISTER, I need to have PGP or send my requests over secure sockets? BR, Aki > -----Original Message----- > From: EXT Henning Schulzrinne [mailto:schulzrinne@cs.columbia.edu] > Sent: 06. October 2000 18:03 > To: sip@lists.bell-labs.com > Subject: [SIP] New draft on SIP registration > > > I've written a quick draft on some of the issues related to how to do > SIP registration when "visiting" networks. I would appreciate > feedback. > The draft does not propose new SIP extensions, except for a possible > Digest parameter to increase registration security. > > The draft is > http://www.ietf.org/internet-drafts/draft-schulzrinne-sip-regi > ster-00.txt > -- > Henning Schulzrinne http://www.cs.columbia.edu/~hgs > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Oct 6 12:22:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA07480 for ; Fri, 6 Oct 2000 12:22:04 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id AF03144346; Fri, 6 Oct 2000 11:22:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 246A84433B for ; Fri, 6 Oct 2000 11:21:34 -0400 (EDT) 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 MAA01912; Fri, 6 Oct 2000 12:21:20 -0400 (EDT) Message-ID: <39DDFC00.7EFBB381@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: aki.niemi@nokia.com Cc: sip@lists.bell-labs.com Subject: Re: [SIP] New draft on SIP registration References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 06 Oct 2000 12:21:20 -0400 Content-Transfer-Encoding: 7bit aki.niemi@nokia.com wrote: > > Hi, > > There seems to be a discrepancy between the SIP registration draft and SIP > RFC (draft-ietf-sip-rfc2543bis-02.pdf) > > draft-schulzrinne-sip-register-00.txt says that: > > "The Authentication-Info header field contains a response digest, but it > only protects the response entity body, not header fields." > > But, draft-ietf-sip-rfc2543bis-02.pdf says in chapter 14.3.: > > "The Authentication-Info and Proxy-Authentication-Info fields are not used > in SIP" > > So basically Digest as an authentication scheme works even worse with SIP > than it does with HTTP? And if I truly want security in my REGISTER, I need > to have PGP or send my requests over secure sockets? You could translate my remark as: - We may want to allow Authentication-Info since it at least protects the integrity of responses, e.g., the retrieval of scripts. (This wasn't really designed when RFC 2543 came around.) - We need an additional mechanism to protect at least some parts of the header via Digest. PGP is an option, but Digest is widely implemented even in small SIP phones (all the ones I have in my office seem to use it...), but nobody implements PGP, partially because setting up PGP secrets and storing them on a small device is somewhat painful. Secure sockets (TLS or IPsec) don't help since in the situations where breaches are likely to occur, you don't have an end-to-end IP or TCP connection. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Oct 6 15:31:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA11425 for ; Fri, 6 Oct 2000 15:31:02 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 59A5E4433D; Fri, 6 Oct 2000 14:31:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mailsrv02.multitude.com (mailsrv02.firetalk.com [204.178.116.251]) by lists.bell-labs.com (Postfix) with ESMTP id CCA194433B for ; Fri, 6 Oct 2000 14:30:48 -0400 (EDT) Received: from sbarber2k (s242.firetalk.com [204.178.116.242]) by mailsrv02.multitude.com (Rockliffe SMTPRA 3.4.2) with SMTP id ; Fri, 6 Oct 2000 12:28:40 -0700 From: "Simon Barber" To: "Henning Schulzrinne" , Subject: RE: [SIP] New draft on SIP registration Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00DA_01C02F91.74CE3B90" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <39DDE9AE.8E5FB901@cs.columbia.edu> Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 6 Oct 2000 12:32:14 -0700 This is a multi-part message in MIME format. ------=_NextPart_000_00DA_01C02F91.74CE3B90 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit HGS> Networks are identified by their domain name, independent of whether HGS> they belong to the same autonomous system, multicast scope or link- HGS> layer local area network. The same physical network may share several HGS> such domains. For example, while cs.columbia.edu and columbia.edu are HGS> part of the same autonomous system and organization, but they are HGS> different domains. hgs@cs.columbia.edu would be visiting the HGS> columbia.edu domain as soon as he obtains a Columbia, rather than HGS> Computer Science, IP address. A user's local domain is defined by the HGS> domain name option configured via DHCP. Some domains do not have a HGS> DHCP server, such as the addresses administered by virtual SIP HGS> domains [TBD: need better terminology - this refers to domains such HGS> as yahoo.com or hotmail.com that offer the equivalent of web-based HGS> email, without any association to a physical network.] Making assumptions about the relationship between network connectivity and domain names is a very tricky and fraught with problems. It is probably very dangerous to make any assumptions in this area. HGS> HGS> We define a traveling user or visitor as a SIP end point that is HGS> visiting a domain other than the domain indicated in its SIP URI. The HGS> outbound proxy and registrar server in the visited network are called HGS> the local proxy and local registrar , respectively. That network is HGS> referred to as the visited network , while the user's domain is HGS> called the home network , which has home proxy and home registrar HGS> HGS> In any network, a SIP end system needs to establish two SIP-related HGS> configuration parameters, namely the local registrar and whether HGS> there is an outbound proxy. There are many possible ways this HGS> information can be configured, but manual configuration is ill- HGS> advised. It is RECOMMENDED that the end system obtain this HGS> information via the SIP server DHCP option [6]. In this approach, HGS> both local registrar and proxy server are assumed to be the same. In Why should these be the same? All requests go to the local outbound proxy, but it can know where the registrar is and forward registrations. HGS> the absence of DHCP or manual configuration, a SIP end system has to HGS> assume that there is no outbound proxy. HGS> HGS> 3 Registration in Visited Network HGS> HGS> In the examples, we let alice@wonderland.com visit the network HGS> visited.net. HGS> HGS> Home registration only: In this model, the visiting user simply HGS> acquires a local IP address in the visited network and HGS> sends a registration with a Contact header indicating that HGS> address. HGS> HGS> HGS> REGISTER sip:wonderland.com SIP/2.0 HGS> To: HGS> From: HGS> Contact: sip:alice@128.59.16.1 Should not the To: and From: addresses be filled in with alice@wonderland.com? Otherwise the registrar does not know for whom the registration is, or who sent it. The alice in the contact could easily be 'visitor_login'. HGS> HGS> HGS> HGS> It makes no difference here whether the visited network HGS> provides SIP services or not. An outbound proxy can be HGS> used, but it simply forwards the REGISTER request based on HGS> its request URI. HGS> HGS> This approach works only if the visited network does not HGS> use a firewall. It also means that every location update HGS> has to go back to the home network. (This is likely to HGS> matter only if IP address changes are frequent.) Also, the HGS> proxy in the visited network cannot provide localized HGS> services such as emergency calling [7]. Perhaps we need a way for outbound proxies to insert location information headers. HGS> HGS> Outbound proxy intercept: Here, the outbound proxy intercepts HGS> the registration request and changes the Contact address to HGS> its own address. It has to create a new temporary user HGS> identifier that allows it to identify incoming requests for HGS> that visiting user. This could be a random identifier or HGS> the concatenation of the visitor's address and the proxy's HGS> domain, such as alice%40wonderland.com@visited.net, where HGS> the %40 is the URL-escaped "@" symbol. We call the latter HGS> the canonical visitor name. HGS> HGS> This approach has the advantage that it forces incoming HGS> requests to use the proxy server. This solves the firewall problem. HGS> HGS> A rogue user can easily override the registration of the HGS> visiting user, although the proxy can provide some security HGS> by discarding any registrations where the registration HGS> fails in the visiting user's home network. Thus, the HGS> visited registrar MUST only act on the registration after a HGS> 200 (OK) response has been returned by the home registrar. HGS> This approach is vulnerable to response spoofing, unless HGS> the response is also authenticated by Digest authentication HGS> or cryptographic signatures. HGS> HGS> The visiting user could also provide a random basic HGS> password when first registering and then be forced to re- HGS> use this secret on subsequent registrations. This would HGS> limit registration spoofing to those intruders that can HGS> snoop the initial registration. A Diffie-Hellman generated HGS> key may also be useful, as long as the intruder cannot HGS> insert itself into the middle of the registration HGS> exchanges. It is probably safest if the local proxy has HGS> access to the local AAA mechanism, as that mechanism has HGS> verified the visiting user and knows which IP address has HGS> been assigned to it. HGS> HGS> As a simple precaution, proxies in visited networks can HGS> simply disallow changes of IP addresses for visiting users; HGS> however, that then only allows a single instance of a HGS> visiting user per visited network. HGS> HGS> User-initiated proxy registration: This is a variation of the HGS> previous approach. The visitor recognizes that it is in a HGS> foreign network by comparing its URI domain to the domain HGS> returned by DHCP in the domain name (Option 15, Section HGS> 3.17 of [8]) or the SIP server option [6]. If they differ, HGS> it uses the address of the SIP server returned by the DHCP HGS> SIP server option as its Contact address. This assumes that HGS> this address is externally reachable, but even if the HGS> domain has it own local DNS and address space, only the HGS> name has to be the same, as it will be resolved by DNS SRV HGS> records. In most cases, this entry will simply be the HGS> domain name. HGS> HGS> The outbound proxy server intercepts the REGISTER request HGS> and updates its internal registration. HGS> HGS> User-initiated proxy registration has the advantage that it HGS> does not interfere with cryptographically signing HGS> registration requests. However, it does require minor HGS> adjustments in SIP UAs and additional functionality in SIP HGS> registrars. HGS> HGS> To avoid adding numerous configuration options, this only HGS> works if all outbound proxy servers can handle such HGS> registrations without prior configuration of the user HGS> identifier. This method has the same spoofing vulnerability HGS> as the previous one. HGS> HGS> Dual registration: In dual registration mode, the visiting UA HGS> sends two REGISTER requests, one to the local registrar and HGS> another to the home registrar. The registration to the HGS> local registrar uses the canonical visitor name to avoid HGS> collisions, while the registration at home follows the same HGS> rules as the "user-initiated proxy registration" case, HGS> except that the proxy server can simply proxy the REGISTER HGS> request not addressed to it, rather than having to also HGS> interpret it. HGS> HGS> This approach has the advantage that error handling is HGS> simplified, as each registration operation can fail HGS> individually. HGS> HGS> However, the visitor generally has no credentials to HGS> authenticate the local registration, unless the registrar HGS> and UA somehow "borrow" credentials from some AAA HGS> mechanism, e.g., a CHAP secret. This is not likely to work HGS> across network types. (For example, it does not work in the HGS> common case where visitors are allowed to plug in laptops HGS> in a local area network while visiting a university or HGS> research lab.) HGS> HGS> This approach has the disadvantage that it requires two HGS> messages between UA and local registrar, which is HGS> undesirable particularly for bandwidth-constrained HGS> environments. It also requires changes in current SIP UAs. The current SIP specification suggests dual registration, but the REGISTER to the local registrar is sent by multicast. What was this originally for? HGS> HGS> Third-party registration: The home registrar registers the HGS> visitor in the visited network, supplying its own HGS> credentials. The home registrar uses the domain name HGS> supplied in the Contact header of the visitor. This can HGS> obviously only work if the UA supplies a domain name rather HGS> than a numeric IP address. HGS> HGS> This approach has the fundamental architectural flaw that HGS> the home registrar is now acting as a UA. HGS> HGS> Note that while the first INVITE in a session uses the outbound HGS> proxies, the regular Route mechanism ([1], Section 6.38) takes over HGS> for subsequent requests. HGS> HGS> 4 Aliases HGS> HGS> Often, SIP UAs have several names, such as a SIP URI derived from the HGS> user's email address (e.g., alice@wonderland.com), a name reflecting HGS> a telephone extension (e.g., 4567@wonderland.com) to ease dialing on HGS> IP phones equipped only with a numeric keypad and possibly an E.164 HGS> address (e.g., 1-212-555-4567@wonderland.com). In addition, UAs may HGS> not always know their domain name, so that configurations derived HGS> from user logins may produce identifiers such as HGS> alice@rathole.wonderland.com. If we want to provide user mobility the user will have to identify their home domain correctly - e.g. by logging in as alice@wonderland.com. alice@rathole could be someone completely different. HGS> HGS> Particularly with telephone extensions, some care needs to be taken, HGS> since extensions have traditionally referred to physical lines, not HGS> users. Thus, the extension may be associated with a particular device HGS> or line. HGS> HGS> Rather than making aliases visible at the protocol level, it may be HGS> preferable to have the SIP UA simply register the same Contact for HGS> each of these aliases. The registrar then uses the user profile or HGS> rewriting rules to associate several different To values with the HGS> same internal registration record. HGS> HGS> Similarly, the location server MAY also, without registration, HGS> translate the request URI in incoming requests from various alias HGS> forms into a canonical user identifier. If the location server can HGS> perform this translation, it removes the need for multiple HGS> registrations. (TBD: are there cases where this is not the case?) HGS> HGS> 5 Home Services while in Visited Network HGS> HGS> For some applications, the user would like to employ services of the HGS> home network while generating outbound requests in the visited HGS> network. The visiting UA needs to detect that it is in a foreign HGS> network and insert a Route header pointing to its home proxy server. HGS> HGS> 6 SIP Naming HGS> HGS> It is RECOMMENDED that a user have a single identifier for email, SIP HGS> and as a network access identifier (NAI) [9]. Thus, every SIP URI HGS> SHOULD also be usable as an email address. Note that this implies HGS> that the algorithm for resolving aliases in proxy servers and SMTP HGS> servers SHOULD be the same. HGS> HGS> 7 Stale Registrations HGS> HGS> It can occur that a device does not have the opportunity to remove a HGS> registration for a particular IP address before being powered down or HGS> otherwise being unable to communicate. Registrations will expire HGS> automatically, but the expiration time can be sufficiently long that HGS> such "orphan" registrations can cause requests to be directed to a HGS> network address that has in the mean time been reassigned to another HGS> user. HGS> HGS> Recipients of misdirected requests SHOULD respond with 404 (Not HGS> Found), which then allows the proxy to remove the registration. HGS> HGS> Also, since registrations are additive, a UA that could not remove a HGS> registration at a previous network, will just add the new HGS> registration, causing requests to be forked to both the new and the HGS> "stale" registration. The UA will obtain all current registrations, HGS> but if a single user has multiple devices, it is not easy for the UA HGS> to detect stale registrations and remove them. HGS> HGS> One possible solution is to add a unique "tag" parameter to the HGS> Contact header of REGISTER requests for those Contact fields where HGS> the UA is the authoritative source. The tag value is selected to be HGS> independent of the UAs current IP address and only depend on its HGS> device identity. Thus, tags are selected such that it never makes HGS> sense to have two registrations with the same tag value. The HGS> registrar keeps track of the tags associated with a registration and HGS> then replaces rather than adds registrations that duplicate existing HGS> Contact header tag values. This is a neat extension. HGS> HGS> HGS> Using the tag parameter in the To header field was HGS> considered, but since a registration may contain many HGS> Contact headers, it is not clear whether it should apply to HGS> all of them. This UAC-initiated use of the tag parameter HGS> also violates the UAS-initiated basic usage in other HGS> requests. HGS> HGS> 8 Security Considerations HGS> HGS> It is RECOMMENDED that the user name in Basic and Digest is the same HGS> as the To header field, rather than a different user name, to HGS> simplify the use of global user databases in multi-domain SIP HGS> servers. HGS> HGS> Digest authentication does not protect the Contact header against HGS> alteration by an adversary. This allows the adversary to redirect HGS> calls to another location if it can alter requests. The HGS> Authentication-Info header field contains a response digest, but it HGS> only protects the response entity body, not header fields. It may be HGS> feasible to create a new qop value, "auth-header", that includes all HGS> headers of the request except those marked with "c", "a" or "m" in HGS> Tables 4 and 5 of [1]. (TBD: this is not particularly easy to HGS> implement since it's not clear what to do with unknown headers. Do HGS> the kludge that only headers before Authorization are included?) HGS> HGS> HGS> HGS> A2 _ Method ":" digest-uri-value ":" H(entity-body) ":" H(e2e-headers) HGS> HGS> HGS> 9 Acknowledgements HGS> HGS> This draft is based on discussions with Jonathan Lennox, Jonathan HGS> Rosenberg and Stinson Mathai. HGS> HGS> 10 Author's Address HGS> HGS> Henning Schulzrinne HGS> Dept. of Computer Science HGS> Columbia University HGS> 1214 Amsterdam Avenue HGS> New York, NY 10027 HGS> USA HGS> electronic mail: schulzrinne@cs.columbia.edu HGS> HGS> 11 Bibliography HGS> HGS> [1] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: HGS> Session initiation protocol," Internet Draft, Internet Engineering HGS> Task Force, Aug. 2000. Work in progress. HGS> HGS> [2] J. Lennox and H. Schulzrinne, "CPL: a language for user control HGS> of internet telephony services," Internet Draft, Internet Engineering HGS> Task Force, Mar. 1999. Work in progress. HGS> HGS> [3] J. Lennox, J. Rosenberg, and H. Schulzrinne, "Common gateway HGS> interface for SIP," Internet Draft, Internet Engineering Task Force, HGS> May 1999. Work in progress. HGS> HGS> [4] J. Lennox and H. Schulzrinne, "Transporting user control HGS> information in SIP REGISTER payloads," Internet Draft, Internet HGS> Engineering Task Force, Mar. 1999. Work in progress. HGS> HGS> [5] A. Gulbrandsen, P. Vixie, and L. Esibov, "A DNS RR for specifying HGS> the location of services (DNS SRV)," Request for Comments 2782, HGS> HGS> HGS> HGS> Schulzrinne [Page 8] HGS> HGS> Internet Draft SIP October 5, 2000 HGS> HGS> HGS> Internet Engineering Task Force, Feb. 2000. HGS> HGS> [6] G. Nair and H. Schulzrinne, "DHCP option for SIP servers," HGS> Internet Draft, Internet Engineering Task Force, Apr. 2000. Work in HGS> progress. HGS> HGS> [7] H. Schulzrinne, "Providing emergency call services for sip-based HGS> internet telephony," Internet Draft, Internet Engineering Task Force, HGS> July 2000. Work in progress. HGS> HGS> [8] S. Alexander and R. Droms, "DHCP options and BOOTP vendor HGS> extensions," Request for Comments 2132, Internet Engineering Task HGS> Force, Mar. 1997. HGS> HGS> [9] B. Aboba and M. Beadles, "The network access identifier," Request HGS> for Comments 2486, Internet Engineering Task Force, Jan. 1999. HGS> HGS> HGS> HGS> HGS> HGS> HGS> HGS> HGS> HGS> HGS> HGS> HGS> HGS> HGS> HGS> HGS> HGS> HGS> HGS> HGS> HGS> HGS> HGS> HGS> HGS> HGS> HGS> HGS> HGS> HGS> HGS> HGS> HGS> HGS> HGS> Schulzrinne [Page 9] HGS> HGS> HGS> HGS> > -----Original Message----- > From: sip-admin@lists.bell-labs.com > [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Henning Schulzrinne > Sent: Friday, October 06, 2000 8:03 AM > To: sip@lists.bell-labs.com > Subject: [SIP] New draft on SIP registration > > > I've written a quick draft on some of the issues related to how to do > SIP registration when "visiting" networks. I would appreciate feedback. > The draft does not propose new SIP extensions, except for a possible > Digest parameter to increase registration security. > > The draft is > http://www.ietf.org/internet-drafts/draft-schulzrinne-sip-register-00.txt > -- > Henning Schulzrinne http://www.cs.columbia.edu/~hgs > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > ------=_NextPart_000_00DA_01C02F91.74CE3B90 Content-Type: text/x-vcard; name="Simon Barber.vcf" Content-Disposition: attachment; filename="Simon Barber.vcf" Content-Transfer-Encoding: quoted-printable BEGIN:VCARD VERSION:2.1 N:Barber;Simon FN:Simon Barber ORG:Firetalk Communications, Inc. TEL;WORK;VOICE:(650) 636-1924 TEL;CELL;VOICE:(650) 743-1919 ADR;WORK:;;5000 Shoreline Court, Suite 200;South San = Francisco;CA;94080;United States of America LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:5000 Shoreline Court, Suite = 200=3D0D=3D0ASouth San Francisco, CA 94080=3D0D=3D0AUnit=3D ed States of America URL:http://www.firetalk.com URL:http://www.firetalk.com EMAIL;PREF;INTERNET:simon@firetalk.com REV:20000914T193921Z END:VCARD ------=_NextPart_000_00DA_01C02F91.74CE3B90-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Oct 6 15:42:06 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA11567 for ; Fri, 6 Oct 2000 15:42:04 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id AEA3C4436A; Fri, 6 Oct 2000 14:42:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by lists.bell-labs.com (Postfix) with ESMTP id 9749C4433B for ; Fri, 6 Oct 2000 14:08:34 -0400 (EDT) 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 MAA25911; Fri, 6 Oct 2000 12:08:49 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA07979; Fri, 6 Oct 2000 12:08:22 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14814.8998.800994.263114@thomasm-u1.cisco.com> To: Henning Schulzrinne Cc: "Roy, Radhika R, ALCOO" , Billy Biggs , "Arnoud van Wijk (ELN)" , "'hammer michael'" , Brian Stucker , Rohan Mahy , sip@lists.bell-labs.com Subject: Re: [SIP] Attempt at summarizing current SIP drafts (SIP Mobility) In-Reply-To: <39DCA123.57DBBE3E@cs.columbia.edu> References: <39DCA123.57DBBE3E@cs.columbia.edu> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 6 Oct 2000 12:08:22 -0700 (PDT) Content-Transfer-Encoding: 7bit This seems eminently reasonable to me. Mike Henning Schulzrinne writes: > I don't want to wade too deeply into this discussion, but just note that > in many of today's networks, we don't have inter-network mobility > between calls. Try asking your local ISP to give you a permanent IP > address and run a HA for you... Permanent device IPv6 addresses will > presumably be used in 3GPP, so that's not a real deep concern there. > > In general, from an efficiency perspective, mobile IP, as available > today (as opposed to the micro-mobility proposals, which are > significantly better), has equivalent or worse update latencies, as any > binding updates go to from the MH to the HA and then to the CH, even > ssuming that the correspondent host supports binding updates (no common > OS do, as far as I know). > > Thus, I believe that for low-latency audio, mobile IPv4, as currently > (barely) available, is not good enough and application-layer mobility > can do better. That is likely to be a transient situation, however. > > Even in the longer-run, if we want hand-offs between two non-cooperating > networks (e.g., a UMTS network and my university network), there may > well be a role, by necessity and as a fallback solution, for > application-layer mobility. > > As long as you can keep your same IP address (modulo the current > practical IPv4 mobility problems), I would use IP mobility, for > generality. If that's not an option, it's nice to know that SIP can help > out to at least keep your voice or video call up, even if you need to > restart your web browser and if your telnet connection goes dead. > -- > Henning Schulzrinne http://www.cs.columbia.edu/~hgs > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Oct 6 17:22:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA13131 for ; Fri, 6 Oct 2000 17:22:04 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C9B984433D; Fri, 6 Oct 2000 16:22:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 08B374433B for ; Fri, 6 Oct 2000 16:21:57 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id RAA13864; Fri, 6 Oct 2000 17:23:50 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Fri, 6 Oct 2000 17:18:15 -0400 Message-ID: From: Jonathan Rosenberg To: "'zeeshan razzaque'" , "'sip@lists.bell-labs.com'" Subject: RE: [SIP] SIP gateway and PINT MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 6 Oct 2000 17:18:15 -0400 They are different applications. If you want third-party controls, like click to dial, use pint. If you want first party calls (traditional PC to phone, phone to phone, etc.) use regular sip. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com > -----Original Message----- > From: zeeshan razzaque [mailto:zrazzaque@yahoo.com] > Sent: Friday, October 06, 2000 8:36 AM > To: sip@lists.bell-labs.com > Subject: [SIP] SIP gateway and PINT > > > I asked a question earlier on about the SIP gateway. > Is it a good idea to use PINT(rfc 2848) to implement > the gateway? How does it affect the IP signaling part > handled by SIP or does it only deal with the PSTN > side? > Any suggestions here? > Zeeshan. > > > __________________________________________________ > Do You Yahoo!? > Yahoo! Photos - 35mm Quality Prints, Now Get 15 Free! > http://photos.yahoo.com/ > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Oct 6 17:26:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA13246 for ; Fri, 6 Oct 2000 17:26:03 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 615294433D; Fri, 6 Oct 2000 16:26:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 442F44433B for ; Fri, 6 Oct 2000 16:25:28 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id RAA13892; Fri, 6 Oct 2000 17:27:27 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Fri, 6 Oct 2000 17:21:52 -0400 Message-ID: From: Jonathan Rosenberg To: "'zeeshan razzaque'" , "'sip@lists.bell-labs.com'" Subject: RE: [SIP] Gateway question MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 6 Oct 2000 17:21:51 -0400 http://search.ietf.org/internet-drafts/draft-rs-trip-gw-01.txt --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com > -----Original Message----- > From: zeeshan razzaque [mailto:zrazzaque@yahoo.com] > Sent: Friday, October 06, 2000 1:30 AM > To: sip@lists.bell-labs.com > Subject: [SIP] Gateway question > > > If a SIP Gateway caters to a certain place(city), what > number(s) does it register and which registration > server does it register with? Does it register with > the city code? Does it register with just one > Registrar or multicasts the REGISTER Request? Plus > does a Gateway act as a collection of multiple User > Agents? I guess it has nothing more to do than > Requesting and responding to requests...it does not > need to act as redirect or proxy server. > Am I right on this one? > > Zeeshan. > > __________________________________________________ > Do You Yahoo!? > Yahoo! Photos - 35mm Quality Prints, Now Get 15 Free! > http://photos.yahoo.com/ > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Oct 6 17:56:59 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA13658 for ; Fri, 6 Oct 2000 17:56:59 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 460014433D; Fri, 6 Oct 2000 16:57:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id A572C4433B for ; Fri, 6 Oct 2000 16:55:59 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id RAA14121; Fri, 6 Oct 2000 17:57:59 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Fri, 6 Oct 2000 17:52:24 -0400 Message-ID: From: Jonathan Rosenberg To: "'rahul pande'" , "'sip@lists.bell-labs.com'" Subject: RE: [SIP] SIP/SDP attribute under...... MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 6 Oct 2000 17:52:23 -0400 The original usage of SDP was in mbone tools where you had a directory tool (namely, SDR), which would receive SAP advertisements of sessions encoded in SDP. If you clicked on a session, it would start tools (like vat, nevot, nevit, vic, rat) which could handle the media streams described in the session. So, what this text means is that in this application, the session directory tool would not parse the fmtp parameter, since it is ignorant of media details. In applications where there is no distinction between the tool parsing the SDP and the tool using the SDP for media streams, of course the code using the SDP would need to parse it fully. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com > -----Original Message----- > From: rahul pande [mailto:panderahul@hotmail.com] > Sent: Thursday, October 05, 2000 5:06 AM > To: sip@lists.bell-labs.com > Subject: [SIP] SIP/SDP attribute under...... > > > Hello All, > I am having problem in understanding the "a=fmtp:" > attribute, i haave > tried to contact the confctrl@isi.edu, but no one responds. > The problem is > somewhat related to SIP and other tools also which will be using SDP. > SDP rfc2327 says :: > > "a=fmtp: > This attribute allows parameters that are specific to a > particular format to be conveyed in a way that SDP doesn't have > to understand them. The format must be one of the formats > specified for the media. Format-specific parameters may be any > set of parameters required to be conveyed by SDP and given > unchanged to the media tool that will use this format. " > > Sir, above whom is the rfc refering to as a "media tool" > Secondly sir, > Its clear that the SDP parsers don't have to > worry about the > , but who is going to handle the > parseing of > this parameter, since PINT, RTP payload types and others are having > different grammar for . > > Can someone please give me some details reguerding this or > please do refer > me a URL. > Thanking you, > rahul > > ______________________________________________________________ > ___________ > Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. Share information about yourself, create your own public profile at http://profiles.msn.com. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Oct 6 19:18:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA14620 for ; Fri, 6 Oct 2000 19:18:02 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A3FB14433D; Fri, 6 Oct 2000 18:18:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 6658B4433B for ; Fri, 6 Oct 2000 18:17:32 -0400 (EDT) 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 TAA29122; Fri, 6 Oct 2000 19:17:17 -0400 (EDT) Message-ID: <39DE5D7E.89CCF8A6@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Simon Barber Cc: sip@lists.bell-labs.com Subject: Re: [SIP] New draft on SIP registration References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 06 Oct 2000 19:17:18 -0400 Content-Transfer-Encoding: 7bit Simon Barber wrote: > > Making assumptions about the relationship between network connectivity and domain > names is a very tricky and fraught with problems. It is probably very dangerous to > make any assumptions in this area. Indeed, one of the goals of this draft is to more clearly identify these assumptions and find out where they break down. We have: - the domain of the DHCP server, generally equally to a broadcast domain (LAN), which determines the outbound proxy server; - the multicast scope, for multicast registrations, also equal to the LAN in most practical cases (but it gets a little fuzzier); - the domain name, which may not have any relationship to a broadcast domain or LAN or multicast scope. Could you elaborate on where you see the problem in the registration context? A visitor uses the local DHCP to find the local domain name and outbound proxy (if present); it knows, by configuration, its home domain. There is one potential problem if the multicast scope does not agree with the DHCP broadcast scope, but that would be a violation of, at least, IPv6 "there is no broadcast" principles and likely cause other difficulties (e.g., with IGMP). > > Why should these be the same? All requests go to the local outbound proxy, but it can > know where the registrar is and forward registrations. Good point, although in practice, things are going to get messy if the proxy and the registrar are not co-located, at least for the cases where you want to intercept and modify the registration ("outbound proxy intercept"). The proxy would have to create a copy of the REGISTER, with the local address, and forward it to the registrar. > HGS> REGISTER sip:wonderland.com SIP/2.0 > HGS> To: > HGS> From: > HGS> Contact: sip:alice@128.59.16.1 > > Should not the To: and From: addresses be filled in with alice@wonderland.com? I don't know what copy you have, but mine has this filled in... I checked the internet-drafts directory and it's correct there, too. > Otherwise the registrar does not know for whom the registration is, or who sent it. > The alice in the contact could easily be 'visitor_login'. > > HGS> proxy in the visited network cannot provide localized > HGS> services such as emergency calling [7]. > > Perhaps we need a way for outbound proxies to insert location information headers. Actually, I believe my statement is not quite true. The outbound proxy can still provide mapping from, say, INVITE sip:911 to a locally valid address, even if there's no registration. > HGS> This approach has the disadvantage that it requires two > HGS> messages between UA and local registrar, which is > HGS> undesirable particularly for bandwidth-constrained > HGS> environments. It also requires changes in current SIP UAs. > > The current SIP specification suggests dual registration, but the REGISTER to the > local registrar is sent by multicast. What was this originally for? This hasn't been updated to reflect DHCP configuration (plus, we probably don't want to make the main spec rely on DHCP). I'd be curious if existing implementations do send two REGISTER when visiting. > In addition, UAs may > HGS> not always know their domain name, so that configurations derived > HGS> from user logins may produce identifiers such as > HGS> alice@rathole.wonderland.com. > > If we want to provide user mobility the user will have to identify their home domain > correctly - e.g. by logging in as alice@wonderland.com. alice@rathole could be > someone completely different. Yes, to allow remote registration, that's pretty much unavoidable. However, the home registrar knows that alice@wonderland and alice@rathole.wonderland are really the same person and can thus act accordingly. For the visited network, it treats these as two different identifiers. In any event, end systems should know their identity, but there are vice-presidential candidates that don't know who they are... -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Oct 6 20:27:06 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA15492 for ; Fri, 6 Oct 2000 20:27:05 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E25464433D; Fri, 6 Oct 2000 19:27:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from rwcxch02.clarent.com (unknown [208.205.112.31]) by lists.bell-labs.com (Postfix) with ESMTP id 9E05E4433B for ; Fri, 6 Oct 2000 19:26:29 -0400 (EDT) Received: by rwcxch02.clarent.com with Internet Mail Service (5.5.2650.21) id <4KQLWT0A>; Fri, 6 Oct 2000 17:24:38 -0700 Message-ID: <6374EFC78443D41197DD00508B5C35DD013D9288@rwcxch02.clarent.com> From: Jean-Francois Mule To: Henning Schulzrinne , sip@lists.bell-labs.com Subject: [SIP] quick comment on draft-ietf-sip-rfc2543bis-02 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 6 Oct 2000 17:24:33 -0700 Henning, In section 1.4.3 of draft-ietf-sip-rfc2543bis-02: "If the client sent the request via unicast UDP, the response is sent to the address contained in the next Via header field (Section 6.46) of the *response*." Shouldn't it be: "If the client sent the request via unicast UDP, the response is sent to the address contained in the next Via header field (Section 6.46) of the *request*." Cheers, Jean-Francois _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Oct 6 20:38:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA15647 for ; Fri, 6 Oct 2000 20:38:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C3E1C44424; Fri, 6 Oct 2000 19:38:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id EC1E04433B for ; Fri, 6 Oct 2000 19:37:03 -0400 (EDT) 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 UAA03575; Fri, 6 Oct 2000 20:36:47 -0400 (EDT) Message-ID: <39DE7020.36818AB@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Jean-Francois Mule Cc: sip@lists.bell-labs.com Subject: Re: [SIP] quick comment on draft-ietf-sip-rfc2543bis-02 References: <6374EFC78443D41197DD00508B5C35DD013D9288@rwcxch02.clarent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 06 Oct 2000 20:36:48 -0400 Content-Transfer-Encoding: 7bit Jean-Francois Mule wrote: > > Henning, > In section 1.4.3 of draft-ietf-sip-rfc2543bis-02: > "If the client sent the request via unicast UDP, the response is sent to the > address contained in the next Via > header field (Section 6.46) of the *response*." > > Shouldn't it be: > "If the client sent the request via unicast UDP, the response is sent to the > address contained in the next Via > header field (Section 6.46) of the *request*." No, although the wording is less than clear. If a proxy gets a response, it forwards it to the address in the next Via header. I'll reword, but want to avoid repeating the discussion later in the spec. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Oct 6 20:53:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA15847 for ; Fri, 6 Oct 2000 20:53:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id AF4A044421; Fri, 6 Oct 2000 19:53:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from pigeon.vovida.com (a98.vovida.com [209.237.8.98]) by lists.bell-labs.com (Postfix) with ESMTP id 80BE24433B for ; Fri, 6 Oct 2000 19:52:04 -0400 (EDT) Received: from vovida.com ([209.237.8.113]) by pigeon.vovida.com (Netscape Messaging Server 4.15) with ESMTP id G21BFR00.QBL for ; Fri, 6 Oct 2000 17:45:27 -0700 Message-ID: <39DE73A6.6B178B28@vovida.com> From: Amit Choksi Organization: Vovida Networks X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14 i686) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] SIP ISUP MIME draft Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 06 Oct 2000 17:51:50 -0700 Content-Transfer-Encoding: 7bit Hi, I am having a doubt concerning a message containing multiple content types like SDP, ISUP, OSP. In a message containing multiple content types 1. Content-Length = 333 (example) Does this specify the length of the total all the Content-Types and corresponding data can we have individual content lengths for all content types ? 2. When there are multiple Content-Types is it compulsory to have the first one as Content-Type: multipart/....; boundary = unique-boundary1 so that we can use the boundary all over , What if this is not there then can we just use CRLF as boundary or if it is not specified then can i just use CRLF as the delimiter Content-Type:application/OSP CRLF CRLF ....data..... unique-boundary1 Content-Type:application/ISUP;version-nxv3 CRLF CRLF .....data..... unique-boundary1 Please point out, if i have wrongly interpreted it. I greatly appreciate any help on this. Thanks Amit Choksi _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Oct 6 20:53:54 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA15859 for ; Fri, 6 Oct 2000 20:53:54 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C375D4444F; Fri, 6 Oct 2000 19:53:10 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from rwcxch02.clarent.com (unknown [208.205.112.31]) by lists.bell-labs.com (Postfix) with ESMTP id 774064433B for ; Fri, 6 Oct 2000 19:52:59 -0400 (EDT) Received: by rwcxch02.clarent.com with Internet Mail Service (5.5.2650.21) id <4KQLW4CW>; Fri, 6 Oct 2000 17:51:09 -0700 Message-ID: <6374EFC78443D41197DD00508B5C35DD013D92BD@rwcxch02.clarent.com> From: Jean-Francois Mule To: Henning Schulzrinne Cc: sip@lists.bell-labs.com Subject: RE: [SIP] quick comment on draft-ietf-sip-rfc2543bis-02 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 6 Oct 2000 17:51:07 -0700 Ok I get the picture in the case of a proxy between 2 UA. But in this section, the sentence is supposed to be general and in the simple case of UA1 -> UA2, I am still unclear. ...If the UA1 client sent the request via unicast UDP to UA2, the response is sent by UA2 server to the address contained in the next Via header field (Section 6.46) of . Jean-Francois. Henning wrote: > No, although the wording is less than clear. If a proxy gets > a response, > it forwards it to the address in the next Via header. I'll reword, but > want to avoid repeating the discussion later in the spec. > > > -- > Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Oct 6 22:30:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA17527 for ; Fri, 6 Oct 2000 22:30:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4FA4744424; Fri, 6 Oct 2000 21:30:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from wusr3.mobilerain.com (sdsl-208-185-234-252.dsl.sjc.megapath.net [208.185.234.252]) by lists.bell-labs.com (Postfix) with ESMTP id C66364433D for ; Fri, 6 Oct 2000 21:29:31 -0400 (EDT) Received: from mobilerain.com (IDENT:dsardana@localhost [127.0.0.1]) by wusr3.mobilerain.com (8.9.3/8.9.3) with ESMTP id TAA08474; Fri, 6 Oct 2000 19:27:59 -0700 Message-ID: <39DE8A2F.2A948F2D@mobilerain.com> From: Bobby Sardana Organization: MobileRain Technologies, Inc. X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: Amit Choksi Cc: sip@lists.bell-labs.com Subject: Re: [SIP] SIP ISUP MIME draft References: <39DE73A6.6B178B28@vovida.com> Content-Type: multipart/mixed; boundary="------------C2A1477E428FE204852E50FB" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 06 Oct 2000 19:27:59 -0700 This is a multi-part message in MIME format. --------------C2A1477E428FE204852E50FB Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello Amit: Amit Choksi wrote: > Hi, > I am having a doubt concerning a message containing multiple content > types like SDP, ISUP, OSP. > In a message containing multiple content types > > 1. Content-Length = 333 (example) > Does this specify the length of the total all the Content-Types and > corresponding data Yes. Total Length = (Header Length Count) + (Unique Boundary Count) + (Message Count) > > > can we have individual content lengths for all content types ? No. From HTTP 1.1 Section 4.4 Message Length. > > > 2. When there are multiple Content-Types is it compulsory to have the > first one as > > Content-Type: multipart/....; boundary = unique-boundary1 > so that we can use the boundary all over , What if this is not > there then can we just use CRLF as boundary Can conflict with message content that has CRLF in it. So to distinguish between the two a boundary is needed. Hope this helps. Regards, Bobby.Sardana@mobilerain.com > > > or if it is not specified then can i just use CRLF as the delimiter > > Content-Type:application/OSP CRLF > CRLF > > ....data..... > > unique-boundary1 > Content-Type:application/ISUP;version-nxv3 CRLF > CRLF > > .....data..... > unique-boundary1 > > Please point out, if i have wrongly interpreted it. > I greatly appreciate any help on this. > > Thanks > Amit Choksi > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip --------------C2A1477E428FE204852E50FB Content-Type: text/x-vcard; charset=us-ascii; name="bobby.sardana.vcf" Content-Description: Card for Bobby Sardana Content-Disposition: attachment; filename="bobby.sardana.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Sardana;Bobby x-mozilla-html:FALSE org:MobileRain Technologies, Inc.;Telecommunications adr:;;;;;; version:2.1 email;internet:bobby.sardana@mobilerain.com title:Engineer x-mozilla-cpt:;0 fn:Bobby Sardana end:vcard --------------C2A1477E428FE204852E50FB-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sat Oct 7 04:38:59 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA03839 for ; Sat, 7 Oct 2000 04:38:59 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 181D544337; Sat, 7 Oct 2000 03:39:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from web5301.mail.yahoo.com (web5301.mail.yahoo.com [216.115.106.110]) by lists.bell-labs.com (Postfix) with SMTP id D697244336 for ; Sat, 7 Oct 2000 03:38:01 -0400 (EDT) Message-ID: <20001007083758.13749.qmail@web5301.mail.yahoo.com> Received: from [12.10.198.194] by web5301.mail.yahoo.com; Sat, 07 Oct 2000 01:37:58 PDT From: Anubhav Srivastav Subject: RE: [SIP] SIP Mobility To: Rohan Mahy , "Roy, Radhika R, ALCOO" Cc: Brian Stucker , sip@lists.bell-labs.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sat, 7 Oct 2000 01:37:58 -0700 (PDT) Hi all, In the current context, I have a query. Can somebody point out the details of what exactly happens at L3 while point of attachments change? I am talking about intra-session (mid-call) handoff here i.e. suppose my current IP address is A and due to my movement into another domain my new IP address will become B. My question is whether this change of address is abrupt or continuous i.e. if at any time (however brief) I have both addresses A as well as B as active. Further, do I know the address B being asigned to me *before* my original address A becomes inactive? Any pointers relating to details of such handoff would be appreciated. Thanks Anubhav __________________________________________________ Do You Yahoo!? Yahoo! Photos - 35mm Quality Prints, Now Get 15 Free! http://photos.yahoo.com/ _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sat Oct 7 07:20:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA04400 for ; Sat, 7 Oct 2000 07:20:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id BB04744337; Sat, 7 Oct 2000 06:20:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from hd2.dot.net.in (hd2.vsnl.net.in [202.54.30.2]) by lists.bell-labs.com (Postfix) with ESMTP id B858D44336 for ; Sat, 7 Oct 2000 06:19:13 -0400 (EDT) Received: from bigboy ([203.197.20.56]) by hd2.dot.net.in (8.8.8/8.8.8) with SMTP id QAA19325; Sat, 7 Oct 2000 16:49:54 +0530 (IST) Message-ID: <006701c030b1$2677e470$1200a8c0@bigboy> From: "farhan" To: "Anubhav Srivastav" Cc: "sip" References: <20001007083758.13749.qmail@web5301.mail.yahoo.com> Subject: Re: [SIP] SIP Mobility 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: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sat, 7 Oct 2000 16:51:33 -0600 Content-Transfer-Encoding: 7bit srivastav - a wireless network has a few more design issues as compared to wire network. 1. minimise the air time. there is only ether for the whole of universe. therefore, each node should only use as much as is absolutely essential. this is another way of saying, dont use excessive handshake and bandwidth. 2. minmise the erp (effective radiated power). this is required to keep the handsets of Alpine mountaineers from gettng jammed by teenagers at a Munich disco. 3. keep things private. anyone with a ham set can snoop on you.keep your data payload encrypted. 4. co-operate. give right of way to other packets. take your chance when given. behave. okay, now what happens at L3 is something like this: 1. when a node comes up, it searches for a controller node (equivalent of a base station in cell phones) on particular channels (note that i dont say frequencies. channels can be made by round-robining access among various channels on the same frequency or moving various channels out into a band of individual frequencies or spatter all the signals of a channel across the band in a pseudo random pattern that the channel member nodes can correlate to and others can avoid). 2. once a controller node is found, the controller will allocate a slot to the newly inducted node. This is optional, the pure aloha implementations dont do this. anyway, once a node in in the 'ring'. the power levels required to sustain communications with the remote peer are continuously varied in a negative feedback loop with fair amount of damping. This is done to conserve battery as well as RFI (radio frequency interference) with other services. 3. when a node starts loosing signal strength with another peer. the QoS monitor through protocols like RTCP on app layer or L3 notices the fading (QSB) and another better path is negotiated. the new path is selected on the basis of best signal to noise ratio and least cost routing. The algorithms are extremely deployment critical. A space application (like satellite telemetry) may have a totally different approach from a cell phone handoff. 4. It is a possiblity that in such a case, isomorphic requests may arrive through multiple routes. protocols like SIP or TCP discard the identical packets in anycase. So should the RTP handlers. During the process of handoff from one coverage area to another, it is expected and always a good idea to have an overlap of coverage from two different 'cells' until the new cell's path is completely ascertained. This has to be done at L3 or maybe even L2 as it involves measurements of movement of the mobile units, resolving the access path between competing routings, etc based on signal strengths, network loading among the various cells as well as the power budget of the UA. a. The key issue from a SIP implementor's point of view is that a set of messages with a completely different via headers may arrive within a session (under the same callid, to and from). these have to be handled without distinction. b. there CAN be an overlap the when your point of attachment maybe multihomed. This should not upset your UA. c. there is no guarenttee that there will always be an overlap. in such cases, the rtp should continue with comfort noise. The actual handoff procedure can be extremely simple to extremely complex. You can refer to the documents at www.etsi.org on GSM algorithms, bluetooth.org for bluetooth approach. However, the most elaborate discussions with rich field data is more easily available from the logs of amateurs who pioneered wireless digital communications in the first place. i am hunting up these resources on the net and i will soon post the urls here. - farhan ----- Original Message ----- From: Anubhav Srivastav To: Rohan Mahy ; Roy, Radhika R, ALCOO Cc: Brian Stucker ; Sent: Saturday, October 07, 2000 2:37 AM Subject: RE: [SIP] SIP Mobility > Hi all, > In the current context, I have a query. Can somebody > point out the details of what exactly happens at L3 > while point of attachments change? I am talking about > intra-session (mid-call) handoff here i.e. suppose my > current IP address is A and due to my movement into > another domain my new IP address will become B. My > question is whether this change of address is abrupt > or continuous i.e. if at any time (however brief) I > have both addresses A as well as B as active. Further, > do I know the address B being asigned to me *before* > my original address A becomes inactive? > > Any pointers relating to details of such handoff would > be appreciated. > > Thanks > Anubhav > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sat Oct 7 08:51:59 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA04943 for ; Sat, 7 Oct 2000 08:51:59 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 264BC44337; Sat, 7 Oct 2000 07:52:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mail.in.huawei.com (unknown [203.197.168.166]) by lists.bell-labs.com (Postfix) with ESMTP id 7426844336 for ; Sat, 7 Oct 2000 07:51:30 -0400 (EDT) Received: from armorse (PPP-179-77.bng.vsnl.net.in [203.197.179.77]) by mail.in.huawei.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 4JW7QWHV; Sat, 7 Oct 2000 18:23:32 +0530 Reply-To: From: "Bodgey" To: Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0042_01C0308B.809B1B50" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal Subject: [SIP] The Option-tag of supported: Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sat, 7 Oct 2000 18:22:08 +0530 This is a multi-part message in MIME format. ------=_NextPart_000_0042_01C0308B.809B1B50 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, I have some questions of Option-tag. Now there are many extesions of SIP, a sip entity must use "Supported" header to indicate what extension the it support so that it can communicate with other entitys with the same function. Is there some option-tags to indicate extensions of all the extension such as PRACK, INFO, MIME for ISUP etc? On other hand, the SIP-T contain many extensions such as PRACK, INFO. Perhaps, we can use one Option-tag to indicate it, isn't it? Would someone give a answer? Thanks! Bodgey ------=_NextPart_000_0042_01C0308B.809B1B50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,=20
I have = some=20 questions of Option-tag. Now there are many extesions of = SIP, a sip=20 entity must use "Supported" header to indicate what extension = the it=20 support so that it can communicate with other entitys with the = same=20 function. Is there some option-tags to indicate extensions of all = the=20 extension such as PRACK, INFO, MIME for ISUP etc?
On = other hand, the=20 SIP-T contain many extensions such as PRACK, INFO. Perhaps, we can use = one=20 Option-tag to indicate it, isn't it?
Would = someone give a=20 answer? Thanks!
 
Bodgey
 
 
 
------=_NextPart_000_0042_01C0308B.809B1B50-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sat Oct 7 11:14:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA06153 for ; Sat, 7 Oct 2000 11:14:00 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E0E9A44337; Sat, 7 Oct 2000 10:14:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from dnsmx1pya.telcordia.com (dnsmx1pya.telcordia.com [128.96.20.31]) by lists.bell-labs.com (Postfix) with ESMTP id 7623844336 for ; Sat, 7 Oct 2000 10:13:42 -0400 (EDT) Received: from notes949.cc.telcordia.com (notes949a.cc.telcordia.com [128.96.246.8]) by dnsmx1pya.telcordia.com (8.9.3/8.9.3) with SMTP id LAA10633; Sat, 7 Oct 2000 11:10:24 -0400 (EDT) Received: by notes949.cc.telcordia.com(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id 85256971.005355A3 ; Sat, 7 Oct 2000 11:10:14 -0400 X-Lotus-FromDomain: TELCORDIA From: "Ashutosh Dutta" To: "farhan" Cc: "Anubhav Srivastav" , "sip" Message-ID: <85256971.005351C2.00@notes949.cc.telcordia.com> Subject: Re: [SIP] SIP Mobility Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sat, 7 Oct 2000 11:09:34 -0400 Few months back there was a big discussion about this particular issue often known as "soft handoff" in the SIP list, you can take a look at the mailing list archive, there is one relevant draft applicable to CDMA e.g., draft-kempf-cdma-appl-01.txt. Thanks Ashutosh _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sat Oct 7 15:04:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA07190 for ; Sat, 7 Oct 2000 15:04:02 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 918AC44337; Sat, 7 Oct 2000 14:04:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from june.Broomfield1.level3.net (june.Broomfield1.Level3.net [209.245.18.7]) by lists.bell-labs.com (Postfix) with ESMTP id A9E3E44336 for ; Sat, 7 Oct 2000 14:03:29 -0400 (EDT) Received: from f1ee40-19.idc1.level3.com (hme0.f1ee40-19.idc1.oss.level3.com [10.1.144.204]) by june.Broomfield1.level3.net (8.9.3/8.9.3) with ESMTP id TAA20340; Sat, 7 Oct 2000 19:03:14 GMT From: Jon.Peterson@Level3.com Received: from n0195idc1.oss.level3.com (localhost [127.0.0.1]) by f1ee40-19.idc1.level3.com (8.8.8+Sun/8.8.8) with ESMTP id NAA16355; Sat, 7 Oct 2000 13:03:08 -0600 (MDT) Received: by n0195idc1.oss.level3.com with Internet Mail Service (5.5.2650.21) id ; Sat, 7 Oct 2000 13:04:59 -0600 Message-ID: <87A245E94948D3118DE30008C716B01301523BB5@c0005v1idc1.oss.level3.com> To: bodgey@in.huawei.com Cc: sip@lists.bell-labs.com Subject: RE: [SIP] The Option-tag of supported: MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sat, 7 Oct 2000 13:02:45 -0600 The process of encapsulating ISUP in and of itself does not currently require any kind of option-tag. It is generally desirable in SIP-T that an endpoint should process ISUP if possible (if it's a gateway), but ignore it if not. The Content-Disposition header can therefore specify whether or not the handling of any particular MIME body is required for the session to continue. So, essentially, the Content-Disposition header can be used to communicate whether or not ISUP needs to be used. Supplying additional MIME bodies is a function of the multipart/mixed MIME type, not an extension to SIP. INFO and, if necessary, PRACK for SIP-T can be marked as Required/Supported. I don't really have any feelings one way or another about grouping multiple option-tags under umbrella tags, except in so far as it seems like there will be more symbols that an endpoint will have to be able to recognize, even if there are less tags transmitted in any particular signal. Jon Peterson Level(3) Communications -----Original Message----- From: Bodgey [mailto:bodgey@in.huawei.com] Sent: Saturday, October 07, 2000 6:52 AM To: sip@lists.bell-labs.com Subject: [SIP] The Option-tag of supported: Hi, I have some questions of Option-tag. Now there are many extesions of SIP, a sip entity must use "Supported" header to indicate what extension the it support so that it can communicate with other entitys with the same function. Is there some option-tags to indicate extensions of all the extension such as PRACK, INFO, MIME for ISUP etc? On other hand, the SIP-T contain many extensions such as PRACK, INFO. Perhaps, we can use one Option-tag to indicate it, isn't it? Would someone give a answer? Thanks! Bodgey _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 9 00:24:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA16005 for ; Mon, 9 Oct 2000 00:24:00 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9729D44338; Sun, 8 Oct 2000 23:24:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from savannah.cis.gsu.edu (savannah.cis.gsu.edu [131.96.142.178]) by lists.bell-labs.com (Postfix) with ESMTP id 682FA44336 for ; Sun, 8 Oct 2000 19:59:31 -0400 (EDT) Received: from gsu.edu ([131.96.142.152]) by savannah.cis.gsu.edu (Switch-2.0.1/Switch-2.0.1) with ESMTP id e990wpP25938; Sun, 8 Oct 2000 20:58:51 -0400 (EDT) Message-ID: <39E11B24.3C1B7324@gsu.edu> From: Samir Chatterjee X-Sender: "Samir Chatterjee" (Unverified) X-Mailer: Mozilla 4.06 [en]C-gatewaynet (Win98; I) MIME-Version: 1.0 To: farhan Cc: Anubhav Srivastav , sip Subject: Re: [SIP] SIP Mobility References: <20001007083758.13749.qmail@web5301.mail.yahoo.com> <006701c030b1$2677e470$1200a8c0@bigboy> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sun, 08 Oct 2000 21:11:00 -0400 Content-Transfer-Encoding: 7bit We may be unnecessarily complicating things here. Most of what you mention below is happening at link layer (L2) and below and even L3 may be oblivious. Keep in mind that SIP is an application layer signaling protocol that works over IP (L3). IP addresses has 2 parts (NetID, hostID). A host attached to a network will get the same netID prefix. In case of mobility, there are 2 cases. First, the host may be hopping between networks (discrete mobility) and gets a dynamic IP address each time it connects. Mobile IP takes care of most things in this case. The other difficult case is continuous mobility in which the host computer is using some kind of wireless interface and is moving around. Again typically you may be inside a wireless LAN domain in which even though you are roaming around a BS connected to a wired network, you are still assigned the same netID prefix, that of the wireless LAN. In another case, you may be roaming within a city and then you are most probably using cellular IP or CDPD in which case even though you may move between cells (L2 connectivity is preserved by handoff), I believe you still retain one IP address. In a continuous mobility case, if your host IP address changes, there could be lots of problems to handle. I think that there are still open challenges in the case when you have switched from a wireless LAN domain to a WAN domain inside a city. Can your networking software automatically switch to the necessary wireless technology? See some interesting work in this regard being done at CMU (Wirelss Andrew Project). If L3 and below takes care of most mobility issues, then anything running higher up should remain oblivious and should run smoothly without change. (This was the basic design principle of TCP/IP BTW, and the designers chose not to provide application layer connectivity.) However, since SIP also addresses the case of user mobility (not necessarily terminal mobility) there could be some issues about registration etc that may need some extra research and digging. I believe Radhika's attempt in this thread is just to come up with such issues, if at all they exist. Samir Chatterjee Georgia State University farhan wrote: > > srivastav - > > a wireless network has a few more design issues as compared to wire network. > > 1. minimise the air time. there is only ether for the whole of universe. > therefore, each node should only use as much as is absolutely essential. > this is another way of saying, dont use excessive handshake and bandwidth. > 2. minmise the erp (effective radiated power). this is required to keep the > handsets of Alpine mountaineers from gettng jammed by teenagers at a Munich > disco. > 3. keep things private. anyone with a ham set can snoop on you.keep your > data payload encrypted. > 4. co-operate. give right of way to other packets. take your chance when > given. behave. > > okay, now what happens at L3 is something like this: > 1. when a node comes up, it searches for a controller node (equivalent of a > base station in cell phones) on particular channels (note that i dont say > frequencies. channels can be made by round-robining access among various > channels on the same frequency or moving various channels out into a band of > individual frequencies or spatter all the signals of a channel across the > band in a pseudo random pattern that the channel member nodes can correlate > to and others can avoid). > 2. once a controller node is found, the controller will allocate a slot to > the newly inducted node. This is optional, the pure aloha implementations > dont do this. anyway, once a node in in the 'ring'. the power levels > required to sustain communications with the remote peer are continuously > varied in a negative feedback loop with fair amount of damping. This is done > to conserve battery as well as RFI (radio frequency interference) with other > services. > 3. when a node starts loosing signal strength with another peer. the QoS > monitor through protocols like RTCP on app layer or L3 notices the fading > (QSB) and another better path is negotiated. the new path is selected on the > basis of best signal to noise ratio and least cost routing. The algorithms > are extremely deployment critical. A space application (like satellite > telemetry) may have a totally different approach from a cell phone handoff. > 4. It is a possiblity that in such a case, isomorphic requests may arrive > through multiple routes. protocols like SIP or TCP discard the identical > packets in anycase. So should the RTP handlers. During the process of > handoff from one coverage area to another, it is expected and always a good > idea to have an overlap of coverage from two different 'cells' until the new > cell's path is completely ascertained. This has to be done at L3 or maybe > even L2 as it involves measurements of movement of the mobile units, > resolving the access path between competing routings, etc based on signal > strengths, network loading among the various cells as well as the power > budget of the UA. > > a. The key issue from a SIP implementor's point of view is that a set of > messages with a completely different via headers may arrive within a session > (under the same callid, to and from). these have to be handled without > distinction. > b. there CAN be an overlap the when your point of attachment maybe > multihomed. This should not upset your UA. > c. there is no guarenttee that there will always be an overlap. in such > cases, the rtp should continue with comfort noise. > > The actual handoff procedure can be extremely simple to extremely complex. > You can refer to the documents at www.etsi.org on GSM algorithms, > bluetooth.org for bluetooth approach. However, the most elaborate > discussions with rich field data is more easily available from the logs of > amateurs who pioneered wireless digital communications in the first place. i > am hunting up these resources on the net and i will soon post the urls here. > > - farhan > > ----- Original Message ----- > From: Anubhav Srivastav > To: Rohan Mahy ; Roy, Radhika R, ALCOO > Cc: Brian Stucker ; > Sent: Saturday, October 07, 2000 2:37 AM > Subject: RE: [SIP] SIP Mobility > > > Hi all, > > In the current context, I have a query. Can somebody > > point out the details of what exactly happens at L3 > > while point of attachments change? I am talking about > > intra-session (mid-call) handoff here i.e. suppose my > > current IP address is A and due to my movement into > > another domain my new IP address will become B. My > > question is whether this change of address is abrupt > > or continuous i.e. if at any time (however brief) I > > have both addresses A as well as B as active. Further, > > do I know the address B being asigned to me *before* > > my original address A becomes inactive? > > > > Any pointers relating to details of such handoff would > > be appreciated. > > > > Thanks > > Anubhav > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 9 00:25:24 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA16018 for ; Mon, 9 Oct 2000 00:25:24 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6E1234434F; Sun, 8 Oct 2000 23:24:08 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mail.Sophia.8x8.COM (unknown [195.154.106.54]) by lists.bell-labs.com (Postfix) with ESMTP id CB0E244336 for ; Sun, 8 Oct 2000 22:14:54 -0400 (EDT) Received: from toshjhr.sophia.8x8.com (dhcp_48_197.sophia.8x8.com [192.168.48.197]) by mail.Sophia.8x8.COM (8.9.1b+Sun/8.9.1) with ESMTP id FAA09240 for ; Mon, 9 Oct 2000 05:14:49 +0200 (MET DST) Message-Id: <5.0.0.25.0.20001009003357.02c37d20@mail.sophia.8x8.com> X-Sender: jhr@mail.sophia.8x8.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 To: sip From: Jean-Hugues ROBERT Subject: Re: [SIP] Re-direct of Media During Ringing In-Reply-To: <28560036253BD41191A10000F8BCBD11480DE0@zcard00g.ca.nortel. com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 09 Oct 2000 00:44:32 +0200 Hi, "During call setup, caller cannot change its SDP to receive early media". I signaled a similar issue a few weeks ago, see the thread on: "[SIP] Media & Signaling inter-dependencies, issue with 183" IMO, 183 and PRACK is a lot of complexity for a feature that is needed for PSTN legacy reasons. A simpler solution would be to 200 OK the session early on and provide PSTN call progress info using re-INVITE. This probably requires some new header to explain the progress cause (in-band-ringback, queued, connected, failed, number disconnected, charging starting...). Jean-Hugues Robert At 03:01 PM 9/25/00 -0500, Tom-PT Taylor wrote: >The consensus expressed in Pittsburgh was that additional transactions could >be opened before the final response to the initial INVITE has come back. >Section 4.2.1 forbids the issuance of re-INVITEs under these circumstances. >I have a case (blind call transfer) where I don't want to interrupt the >alerting being provided to the called subscriber, but I do need to change >the media path. Do we really need the restriction on re-INVITE? > >Tom Taylor > >_______________________________________________ >SIP mailing list >SIP@lists.bell-labs.com >http://lists.bell-labs.com/mailman/listinfo/sip --------------------------------------------------------------------------- "Don't kill the messenger!" - Sophocles 442 BC. Shakespeare 1598. Sophia General Manager. tel: (7)263 mailto:jhr@netergynet.com - We serve providers - "Think globally. http://www.netergynet.com - Hosted PBX solutions - Act locally." _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 9 02:30:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA29034 for ; Mon, 9 Oct 2000 02:30:00 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 09C3044338; Mon, 9 Oct 2000 01:30:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lists.bell-labs.com (Postfix) with ESMTP id 14A7944336 for ; Mon, 9 Oct 2000 01:29:53 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id e996TlZ00701; Mon, 9 Oct 2000 08:29:48 +0200 (MEST) Received: from lmf.ericsson.se (E005004B57CE1.lmf.ericsson.se [131.160.30.148]) by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id JAA25264; Mon, 9 Oct 2000 09:29:46 +0300 (EET DST) Message-ID: <39E165D9.F0C9BF2A@lmf.ericsson.se> 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: Mark Watson Cc: sip@lists.bell-labs.com Subject: Re: [SIP] FW: Delaying alerting at UAS References: <61ABD11436FED21192440000F81F3E360304C2FF@nwcwi1a.europe.nortel> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 09 Oct 2000 09:29:45 +0300 Content-Transfer-Encoding: 7bit Hi, > Mark Watson wrote: > > Thanks, this seems to answer the question - I look forward to reading > the draft. http://search.ietf.org/internet-drafts/draft-camarillo-manyfolks-confirm-00.txt > I think this would need to be a session layer indication (i.e. in SIP, > not in the SDP) - the precondition is not necessarily related to the > media stream between UAC and UAS - in fact the UAS is never aware of > what the precondition actually is. Well, this might be an interesting discussion. The thing is that the preconditions are very well described in the SDP part, but then SIP signalling in used to confirm that the preconditions have been met. Regards, Gonzalo > > I had a further questions about the use of PRACKs to carry SDP in the > manyfolks draft. (Apologies in advance if this has already been > discussed too!). > > I though that the purpose of PRACKs was to support reliability of > provisional responses. If this is their purpose then of course they > are not required if running over reliable transport (TCP and SCTP). > So, how can they be used for carrying information as well ? > > Regards, > > Mark Watson > Nortel Networks > > -----Original Message----- > From: Gonzalo.Camarillo@lmf.ericsson.se > [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > Sent: 06 October 2000 12:42 > To: Watson, Mark > Cc: sip@lists.bell-labs.com > Subject: [SIP] FW: Delaying alerting at UAS > > Hi, > > This issue was presented in the last IETF meeting. > http://www.softarmor.com/sipwg/meets/IETF48/slides/pres-camarillo-3pccprecon-sip > > -48.ppt > > I have submitted a draft about it. I sent it to the IETF a > couple of days ago, > so it will be available very soon. It is called: > draft-camarillo-manyfolks-confirm-00.txt > > It outlines how to ask the UAS to wait until it receives a > COMET from the UAC in > order to go on with the session establishment. > > The draft contains an example related to third party call > control using SIP, but > as you said, it is a general mechanism that can be employed in > several > situations. > > Best regards, > > Gonzalo > > >Hi, > > > >Is it possible for a UAC to request that the UAS delays > alerting of the user > >until a subsequent 'go ahead' message is sent from UAC to UAS > ?? > > > >For example, if the UAC has some action it requires to take > before full session > >commencement, but it only wants to take this action if the > required user can be > > > >sucessfully located and is available ? > > > > > >The UAC action might be some kind of local resource > reservation or an > >indication to the calling user etc. > > > > > >Can this be done with SIP as it stands ? > > > > > >I looked in draft-manyfolks-sip-resource, but there does not > appear to be any > >way for the UAC to *require* that the UAS delay alerting until > receipt of > >confirmation from the UAC - the behaviour is optional on the > part of the UAS. > > > > > >Regards, > > > > > >Mark Watson > >Nortel Networks > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland http://www.hut.fi/~gonzalo _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 9 02:33:00 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA29064 for ; Mon, 9 Oct 2000 02:32:59 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id DAE7A44359; Mon, 9 Oct 2000 01:33:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lists.bell-labs.com (Postfix) with ESMTP id 8471044338 for ; Mon, 9 Oct 2000 01:32:37 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id e996WXZ01852 for ; Mon, 9 Oct 2000 08:32:33 +0200 (MEST) Received: from lmf.ericsson.se (E005004B57CE1.lmf.ericsson.se [131.160.30.148]) by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id JAA25519 for ; Mon, 9 Oct 2000 09:32:32 +0300 (EET DST) Message-ID: <39E1667F.E526E5C8@lmf.ericsson.se> 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 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] Feedback on manyfolks Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 09 Oct 2000 09:32:31 +0300 Content-Transfer-Encoding: 7bit Hi, Here you have a new I-D that contains feedback on the manyfolks draft. http://search.ietf.org/internet-drafts/draft-camarillo-manyfolks-confirm-00.txt " Abstract This document describes certain functionality that is missing in the current "Integration of Resource Management and SIP" [1] (a.k.a. manyfolks draft). An extension to add this functionality is outlined. This functionality is needed in general to provide richer signalling capabilities and can be employed in several scenarios. This draft describes its use in third party call control applications. If this extension is accepted it is foreseen that this draft would be merged with [1]. " Best regards, Gonzalo -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland http://www.hut.fi/~gonzalo _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 9 04:06:43 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA29645 for ; Mon, 9 Oct 2000 04:06:43 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7F84F44338; Mon, 9 Oct 2000 03:06:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lists.bell-labs.com (Postfix) with ESMTP id 2720644336 for ; Mon, 9 Oct 2000 03:05:59 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id e9985jZ21714; Mon, 9 Oct 2000 10:05:45 +0200 (MEST) Received: from lmf.ericsson.se (E005004B57CE1.lmf.ericsson.se [131.160.30.148]) by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id LAA04605; Mon, 9 Oct 2000 11:05:44 +0300 (EET DST) Message-ID: <39E17C56.35D50F99@lmf.ericsson.se> 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: "Culpepper, Bert" Cc: Rohan Mahy , Jonathan Rosenberg , sip@lists.bell-labs.com, Henning Schulzrinne , mmusic Subject: Re: [SIP] draft-camarillo-sip-sdp-00.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 09 Oct 2000 11:05:42 +0300 Content-Transfer-Encoding: 7bit Hi, I have gathered some feedback on the draft draft-camarillo-sip-sdp-00.txt The general feeling in the SIP and MMUSIC WGs is that this is certainly a useful mechanism. However, there are some concerns about the actual format to be used and the problems that some RTP implementation might have if an RTP flow is sent to different port numbers. A possible solution to the format to be used is already outlined in the draft in section 7. "Backward compatibility". I will check what people in the Audio/Video Transport (avt) WG think about this. Regards, Gonzalo "Culpepper, Bert" wrote: > > Hi, > > I'm not writing to present a problem with this proposal but to state a need > for it? > > For a specific case not mentioned in the draft. A "3rd-party call agent" > may need to be able to receive tones and also have them be presented to the > 2nd party. Tone transport is defined by RFC2833, it recommends that > gateways remove the tones from the audio media. > > So..., I'd like an endpoint to understand the following media description in > a session description. > > m=audio 10010 RTP/AVP 4 > c=IN IP4 111.2.30.4 > a=rtpmap:4 G723/8000 > m=audio 10020 RTP/AVP 97 > c=IN IP4 111.2.30.4 > a=rtpmap:97 telephone-event > a=fmtp:97 0-15 > m=audio 20000 RTP/AVP 97 > c=IN IP4 111.2.31.10 > a=rtpmap:97 telephone-event > a=fmtp:97 0-15,16 > > (In this case one "c" line can be used in the session description instead of > how it's shown.) > > Nothing I read in RFC 2543 (SIP) and RFC 2327 (SDP) indicates the above is > not allowed. This is not a standards issue but I wonder how many endpoints > (gateways included) will support sending the two media types to the > different destinations as indicated above. If in SIP the above session > description doesn't result in three "media streams" being sent to the > indicated host/port, media replication (which may not be present in an > endpoint) will require a specific resource in the network. > > Is the use of the flow ID attribute required to achieve the above? Am I > incorrect in what I think should result from the above session description > in SIP? > > The ID does seem to encourage endpoint support for media replication to > different hosts and ports which I'd like to see as standard functionality in > some endpoints & environments. > > Regards, > Bert > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland http://www.hut.fi/~gonzalo _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 9 06:05:45 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA00255 for ; Mon, 9 Oct 2000 06:05:45 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C43C544338; Mon, 9 Oct 2000 05:04:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from qhars002.nortel.com (qhars002.NortelNetworks.com [192.100.101.19]) by lists.bell-labs.com (Postfix) with ESMTP id F104144336 for ; Mon, 9 Oct 2000 05:03:13 -0400 (EDT) Received: from znsgd00t.europe.nortel.com (actually znsgd00t) by qhars002.nortel.com; Mon, 9 Oct 2000 11:01:47 +0100 Received: by znsgd00t.europe.nortel.com with Internet Mail Service (5.5.2652.35) id <4M0H6F9Y>; Mon, 9 Oct 2000 11:01:46 +0100 Message-ID: <61ABD11436FED21192440000F81F3E360304C30D@nwcwi1a.europe.nortel.com> From: "Mark Watson" To: "'Gonzalo Camarillo'" , sip Subject: RE: [SIP] Feedback on manyfolks MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C031D7.ED7A0360" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 9 Oct 2000 11:01:43 +0100 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_01C031D7.ED7A0360 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Gonzalo, A small comment: in section 1 your write: "As soon as the callee=C6s UA has finished the resource reservation in the callee-caller direction (using RSVP for instance) and a COMET arrives from the caller (confirming that resources are also available in the caller-callee direction) the callee will be alerted." Reading the manyfolks draft 'cold', without having been involved in the original discussions, I did not get the impression that there was any asumption that the callee was responsible for 'callee->caller' = reservation and the caller for the reverse direction. This assumption seems to be specific to certain reservation technologies. Rather, I read the draft as implying that the COMET from caller to = callee was sent when the caller had done 'whatever is necessary' to provide = the QoS/Security preconditions which were negotiated in the SDP. Does there need to be an assumption about what 'whenever is necessary' = is ? Surely this, and whether or not the caller/callee needs the other to = confirm it, is dependent on the particular QoS technology being used ? Regards, Mark Watson Nortel Networks -----Original Message----- From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] Sent: 09 October 2000 07:33 To: sip Subject: [SIP] Feedback on manyfolks Hi, Here you have a new I-D that contains feedback on the manyfolks draft. http://search.ietf.org/internet-drafts/draft-camarillo-manyfolks-confirm= -00. txt " Abstract This document describes certain functionality that is missing in the current "Integration of Resource Management and SIP" [1] (a.k.a. manyfolks draft). An extension to add this functionality is outlined. This functionality is needed in general to provide richer signalling capabilities and can be employed in several scenarios. This draft describes its use in third party call control applications. If this extension is accepted it is foreseen that this draft would be merged with [1]. " Best regards, Gonzalo --=20 Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland http://www.hut.fi/~gonzalo _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip ------_=_NextPart_001_01C031D7.ED7A0360 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [SIP] Feedback on manyfolks

Gonzalo,

A small comment: in section 1 your write:

"As soon as the callee=C6s UA
   has finished the resource reservation = in the callee-caller direction
   (using RSVP for instance) and a COMET = arrives from the caller
   (confirming that resources are also = available in the caller-callee
   direction) the callee will be = alerted."

Reading the manyfolks draft 'cold', without having = been involved in the original discussions, I did not get the impression = that there was any asumption that the callee was responsible for = 'callee->caller' reservation and the caller for the reverse = direction. This assumption seems to be specific to certain reservation = technologies.

Rather, I read the draft as implying that the COMET = from caller to callee was sent when the caller had done 'whatever is = necessary' to provide the QoS/Security preconditions which were = negotiated in the SDP.

Does there need to be an assumption about what = 'whenever is necessary' is ? Surely this, and whether or not the = caller/callee needs the other to confirm it, is dependent on the = particular QoS technology being used ?

Regards,

Mark Watson
Nortel Networks


-----Original Message-----
From: Gonzalo Camarillo [mailto:Gonzalo.Camaril= lo@lmf.ericsson.se]
Sent: 09 October 2000 07:33
To: sip
Subject: [SIP] Feedback on manyfolks


Hi,

Here you have a new I-D that contains feedback on the = manyfolks draft.

http://search.ietf.org/internet-drafts/draft-camarillo= -manyfolks-confirm-00.txt

"
Abstract

   This document describes certain = functionality that is missing in the
   current "Integration of Resource = Management and SIP" [1] (a.k.a.
   manyfolks draft). An extension to add = this functionality is
   outlined.

   This functionality is needed in general = to provide richer signalling
   capabilities and can be employed in = several scenarios. This draft
   describes its use in third party call = control applications.

   If this extension is accepted it is = foreseen that this draft would
   be merged with [1].
"

Best regards,

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         &n= bsp;         http://www.hut.fi/~gonzalo

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip

------_=_NextPart_001_01C031D7.ED7A0360-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 9 06:10:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA00292 for ; Mon, 9 Oct 2000 06:10:02 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 04C5F44338; Mon, 9 Oct 2000 05:10:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from qnsgs000.nortel.com (qnsgs000.nortelnetworks.com [47.211.0.31]) by lists.bell-labs.com (Postfix) with ESMTP id 5C10F44336 for ; Mon, 9 Oct 2000 05:09:13 -0400 (EDT) Received: from znsgd00t.europe.nortel.com (actually znsgd00t) by qnsgs000.nortel.com; Mon, 9 Oct 2000 11:07:00 +0100 Received: by znsgd00t.europe.nortel.com with Internet Mail Service (5.5.2652.35) id <4M0H6G1X>; Mon, 9 Oct 2000 11:06:59 +0100 Message-ID: <61ABD11436FED21192440000F81F3E360304C30E@nwcwi1a.europe.nortel.com> From: "Mark Watson" To: "'Gonzalo Camarillo'" Cc: sip@lists.bell-labs.com Subject: RE: [SIP] FW: Delaying alerting at UAS MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C031D8.A6DEF360" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 9 Oct 2000 11:06:54 +0100 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_01C031D8.A6DEF360 Content-Type: text/plain; charset="iso-8859-1" Gonzalo, This provides an excellent solution for preconditions related to the media path between caller and callee, and using SDP obviously allows you to negotiate different preconditions for different media streams. However, what about preconditions which aren't related to the media path between caller and callee ? Preconditions which the other party does not know, or need to know about. I think there is a requirement for a generic mechanism for the caller to specify that the callee should wait for a COMET (or vice versa) without this needing to be related to a particular media stream. To my mind this should be a session level indication and would force the other UA to wait for the COMET independent of whatever is agreed about QoS/Security. Regards, Mark Watson Nortel Networks -----Original Message----- From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] Sent: 09 October 2000 07:30 To: Watson, Mark Cc: sip@lists.bell-labs.com Subject: Re: [SIP] FW: Delaying alerting at UAS Hi, > Mark Watson wrote: > > Thanks, this seems to answer the question - I look forward to reading > the draft. http://search.ietf.org/internet-drafts/draft-camarillo-manyfolks-confirm-00. txt > I think this would need to be a session layer indication (i.e. in SIP, > not in the SDP) - the precondition is not necessarily related to the > media stream between UAC and UAS - in fact the UAS is never aware of > what the precondition actually is. Well, this might be an interesting discussion. The thing is that the preconditions are very well described in the SDP part, but then SIP signalling in used to confirm that the preconditions have been met. Regards, Gonzalo > > I had a further questions about the use of PRACKs to carry SDP in the > manyfolks draft. (Apologies in advance if this has already been > discussed too!). > > I though that the purpose of PRACKs was to support reliability of > provisional responses. If this is their purpose then of course they > are not required if running over reliable transport (TCP and SCTP). > So, how can they be used for carrying information as well ? > > Regards, > > Mark Watson > Nortel Networks > > -----Original Message----- > From: Gonzalo.Camarillo@lmf.ericsson.se > [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > Sent: 06 October 2000 12:42 > To: Watson, Mark > Cc: sip@lists.bell-labs.com > Subject: [SIP] FW: Delaying alerting at UAS > > Hi, > > This issue was presented in the last IETF meeting. > http://www.softarmor.com/sipwg/meets/IETF48/slides/pres-camarillo-3pccprecon -sip > > -48.ppt > > I have submitted a draft about it. I sent it to the IETF a > couple of days ago, > so it will be available very soon. It is called: > draft-camarillo-manyfolks-confirm-00.txt > > It outlines how to ask the UAS to wait until it receives a > COMET from the UAC in > order to go on with the session establishment. > > The draft contains an example related to third party call > control using SIP, but > as you said, it is a general mechanism that can be employed in > several > situations. > > Best regards, > > Gonzalo > > >Hi, > > > >Is it possible for a UAC to request that the UAS delays > alerting of the user > >until a subsequent 'go ahead' message is sent from UAC to UAS > ?? > > > >For example, if the UAC has some action it requires to take > before full session > >commencement, but it only wants to take this action if the > required user can be > > > >sucessfully located and is available ? > > > > > >The UAC action might be some kind of local resource > reservation or an > >indication to the calling user etc. > > > > > >Can this be done with SIP as it stands ? > > > > > >I looked in draft-manyfolks-sip-resource, but there does not > appear to be any > >way for the UAC to *require* that the UAS delay alerting until > receipt of > >confirmation from the UAC - the behaviour is optional on the > part of the UAS. > > > > > >Regards, > > > > > >Mark Watson > >Nortel Networks > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland http://www.hut.fi/~gonzalo _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip ------_=_NextPart_001_01C031D8.A6DEF360 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [SIP] FW: Delaying alerting at UAS

Gonzalo,

This provides an excellent solution for preconditions = related to the media path between caller and callee, and using SDP = obviously allows you to negotiate different preconditions for different = media streams.

However, what about preconditions which aren't = related to the media path between caller and callee ? Preconditions = which the other party does not know, or need to know about.

I think there is a requirement for a generic = mechanism for the caller to specify that the callee should wait for a = COMET (or vice versa) without this needing to be related to a = particular media stream. To my mind this should be a session level = indication and would force the other UA to wait for the COMET = independent of whatever is agreed about QoS/Security.

Regards,

Mark Watson
Nortel Networks

-----Original Message-----
From: Gonzalo Camarillo [mailto:Gonzalo.Camaril= lo@lmf.ericsson.se]
Sent: 09 October 2000 07:30
To: Watson, Mark
Cc: sip@lists.bell-labs.com
Subject: Re: [SIP] FW: Delaying alerting at = UAS


Hi,

> Mark Watson wrote:
>
> Thanks, this seems to answer the question - I = look forward to reading
> the draft.

http://search.ietf.org/internet-drafts/draft-camarillo= -manyfolks-confirm-00.txt
 
> I think this would need to be a session layer = indication (i.e. in SIP,
> not in the SDP) - the precondition is not = necessarily related to the
> media stream between UAC and UAS - in fact the = UAS is never aware of
> what the precondition actually is.

Well, this might be an interesting discussion. The = thing is that the
preconditions are very well described in the SDP = part, but then SIP
signalling in used to confirm that the preconditions = have been met.

Regards,

Gonzalo


>
> I had a further questions about the use of = PRACKs to carry SDP in the
> manyfolks draft. (Apologies in advance if this = has already been
> discussed too!).
>
> I though that the purpose of PRACKs was to = support reliability of
> provisional responses. If this is their purpose = then of course they
> are not required if running over reliable = transport (TCP and SCTP).
> So, how can they be used for carrying = information as well ?
>
> Regards,
>
> Mark Watson
> Nortel Networks
>
> -----Original Message-----
> From: Gonzalo.Camarillo@lmf.ericsson.se
> [mailto:Gonzalo.Camaril= lo@lmf.ericsson.se]
> Sent: 06 October 2000 12:42
> To: Watson, Mark
> Cc: sip@lists.bell-labs.com
> Subject: [SIP] FW: Delaying alerting at = UAS
>
> Hi,
>
> This issue was presented in the last IETF = meeting.
> http://www.softarmor.com/sipwg/meets/IETF48/slides/pre= s-camarillo-3pccprecon-sip
>
> -48.ppt
>
> I have submitted a draft about it. I sent it to = the IETF a
> couple of days ago,
> so it will be available very soon. It is = called:
> draft-camarillo-manyfolks-confirm-00.txt
>
> It outlines how to ask the UAS to wait until it = receives a
> COMET from the UAC in
> order to go on with the session = establishment.
>
> The draft contains an example related to third = party call
> control using SIP, but
> as you said, it is a general mechanism that can = be employed in
> several
> situations.
>
> Best regards,
>
> Gonzalo
>
> >Hi,
> >
> >Is it possible for a UAC to request that = the UAS delays
> alerting of the user
> >until a subsequent 'go ahead' message is = sent from UAC to UAS
> ??
> >
> >For example, if the UAC has some action it = requires to take
> before full session
> >commencement, but it only wants to take = this action if the
> required user can be
> >
> >sucessfully located and is available = ?
> >
> >
> >The UAC action might be some kind of local = resource
> reservation or an
> >indication to the calling user etc.
> >
> >
> >Can this be done with SIP as it stands = ?
> >
> >
> >I looked in draft-manyfolks-sip-resource, = but there does not
> appear to be any
> >way for the UAC to *require* that the UAS = delay alerting until
> receipt of
> >confirmation from the UAC - the behaviour = is optional on the
> part of the UAS.
> >
> >
> >Regards,
> >
> >
> >Mark Watson
> >Nortel Networks
>
> = _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip

--
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         &n= bsp;         http://www.hut.fi/~gonzalo

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip

------_=_NextPart_001_01C031D8.A6DEF360-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 9 06:11:47 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA00310 for ; Mon, 9 Oct 2000 06:11:47 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D448444368; Mon, 9 Oct 2000 05:10:09 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from qnsgs000.nortel.com (qnsgs000.nortelnetworks.com [47.211.0.31]) by lists.bell-labs.com (Postfix) with ESMTP id CFCDE44336 for ; Mon, 9 Oct 2000 05:09:26 -0400 (EDT) Received: from znsgd00t.europe.nortel.com (actually znsgd00t) by qnsgs000.nortel.com; Mon, 9 Oct 2000 10:49:50 +0100 Received: by znsgd00t.europe.nortel.com with Internet Mail Service (5.5.2652.35) id <4M0H6F3F>; Mon, 9 Oct 2000 10:49:49 +0100 Message-ID: <61ABD11436FED21192440000F81F3E360304C30C@nwcwi1a.europe.nortel.com> From: "Mark Watson" To: "'Jonathan Rosenberg'" , "Mark Watson" , "'Gonzalo.Camarillo@lmf.ericsson.se'" Cc: "'sip@lists.bell-labs.com'" Subject: RE: [SIP] FW: Delaying alerting at UAS MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C031D6.42706B40" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 9 Oct 2000 10:49:47 +0100 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_01C031D6.42706B40 Content-Type: text/plain; charset="iso-8859-1" Jonathan, Mayby I am missing something, but if there are multiple hops, with different transports, then there is always a stateful proxy on the boundry between the reliable transport hops and the unreliable transport hops (I understand that proxies supporting reliable transport must be stateful - perhaps that it where I am wrong ?) This proxy on the boundry could provide the PRACKs on the unreliable transport hops. Regards...Mark -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: 06 October 2000 15:39 To: Watson, Mark ; 'Gonzalo.Camarillo@lmf.ericsson.se' Cc: 'sip@lists.bell-labs.com' Subject: RE: [SIP] FW: Delaying alerting at UAS -----Original Message----- >From: Mark Watson [mailto:mwatson@nortelnetworks.com] >Sent: Friday, October 06, 2000 8:50 AM >To: 'Gonzalo.Camarillo@lmf.ericsson.se' >Cc: sip@lists.bell-labs.com >Subject: RE: [SIP] FW: Delaying alerting at UAS > >I though that the purpose of PRACKs was to support reliability of provisional responses. If >this is their purpose then of course they are not required if running over reliable >transport (TCP and SCTP). So, how can they be used for carrying information as well ? No, that is not correct. As there can be many hops along the way, each with different transports, no one entity can know whether end to end tcp is used or not. As a result, PRACK is always used for reliable provisional responses, independent of the transport. -Jonathan R. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip ------_=_NextPart_001_01C031D6.42706B40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [SIP] FW: Delaying alerting at UAS

Jonathan,

Mayby I am missing something, but if there are = multiple hops, with different transports, then there is always a = stateful proxy on the boundry between the reliable transport hops and = the unreliable transport hops (I understand that proxies supporting = reliable transport must be stateful - perhaps that it where I am wrong = ?)

This proxy on the boundry could provide the PRACKs on = the unreliable transport hops.

Regards...Mark

-----Original Message-----
From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
Sent: 06 October 2000 15:39
To: Watson, Mark ; = 'Gonzalo.Camarillo@lmf.ericsson.se'
Cc: 'sip@lists.bell-labs.com'
Subject: RE: [SIP] FW: Delaying alerting at = UAS




-----Original Message-----
>From: Mark Watson [mailto:mwatson@nortelnetworks= .com]
>Sent: Friday, October 06, 2000 8:50 AM
>To: 'Gonzalo.Camarillo@lmf.ericsson.se'
>Cc: sip@lists.bell-labs.com
>Subject: RE: [SIP] FW: Delaying alerting at = UAS
>

<snip>

>I though that the purpose of PRACKs was to = support reliability of
provisional responses. If
>this is their purpose then of course they are = not required if running over
reliable
>transport (TCP and SCTP). So, how can they be = used for carrying information
as well ?

No, that is not correct. As there can be many hops = along the way, each with
different transports, no one entity can know whether = end to end tcp is used
or not. As a result, PRACK is always used for = reliable provisional
responses, independent of the transport.

-Jonathan R.


_______________________________________________ =
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip =

------_=_NextPart_001_01C031D6.42706B40-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 9 06:14:43 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA00328 for ; Mon, 9 Oct 2000 06:14:42 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0036F44374; Mon, 9 Oct 2000 05:14:01 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lists.bell-labs.com (Postfix) with ESMTP id BE70A44338 for ; Mon, 9 Oct 2000 05:13:15 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id e99ADAZ24710; Mon, 9 Oct 2000 12:13:11 +0200 (MEST) Received: from lmf.ericsson.se (E005004B57CE1.lmf.ericsson.se [131.160.30.148]) by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id NAA16660; Mon, 9 Oct 2000 13:13:07 +0300 (EET DST) Message-ID: <39E19A31.38DD1DF2@lmf.ericsson.se> 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: Mark Watson Cc: "'Jonathan Rosenberg'" , "'sip@lists.bell-labs.com'" Subject: Re: [SIP] FW: Delaying alerting at UAS References: <61ABD11436FED21192440000F81F3E360304C30C@nwcwi1a.europe.nortel> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 09 Oct 2000 13:13:05 +0300 Content-Transfer-Encoding: 7bit When reliability is provided end to end there is no need of storing state in the network (proxies). Gonzalo > Mark Watson wrote: > > Jonathan, > > Mayby I am missing something, but if there are multiple hops, with > different transports, then there is always a stateful proxy on the > boundry between the reliable transport hops and the unreliable > transport hops (I understand that proxies supporting reliable > transport must be stateful - perhaps that it where I am wrong ?) > > This proxy on the boundry could provide the PRACKs on the unreliable > transport hops. > > Regards...Mark > > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: 06 October 2000 15:39 > To: Watson, Mark ; 'Gonzalo.Camarillo@lmf.ericsson.se' > Cc: 'sip@lists.bell-labs.com' > Subject: RE: [SIP] FW: Delaying alerting at UAS > > -----Original Message----- > >From: Mark Watson [mailto:mwatson@nortelnetworks.com] > >Sent: Friday, October 06, 2000 8:50 AM > >To: 'Gonzalo.Camarillo@lmf.ericsson.se' > >Cc: sip@lists.bell-labs.com > >Subject: RE: [SIP] FW: Delaying alerting at UAS > > > > > > >I though that the purpose of PRACKs was to support reliability of > provisional responses. If > >this is their purpose then of course they are not required if running > over > reliable > >transport (TCP and SCTP). So, how can they be used for carrying > information > as well ? > > No, that is not correct. As there can be many hops along the way, each > with > different transports, no one entity can know whether end to end tcp is > used > or not. As a result, PRACK is always used for reliable provisional > responses, independent of the transport. > > -Jonathan R. > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland http://www.hut.fi/~gonzalo _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 9 06:22:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA00390 for ; Mon, 9 Oct 2000 06:22:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A937444370; Mon, 9 Oct 2000 05:22:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lists.bell-labs.com (Postfix) with ESMTP id 53FA04436F for ; Mon, 9 Oct 2000 05:21:51 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id e99ALiZ01692; Mon, 9 Oct 2000 12:21:44 +0200 (MEST) Received: from lmf.ericsson.se (E005004B57CE1.lmf.ericsson.se [131.160.30.148]) by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id NAA17413; Mon, 9 Oct 2000 13:21:42 +0300 (EET DST) Message-ID: <39E19C34.E6956BA3@lmf.ericsson.se> 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: Mark Watson Cc: sip Subject: Re: [SIP] Feedback on manyfolks References: <61ABD11436FED21192440000F81F3E360304C30D@nwcwi1a.europe.nortel> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 09 Oct 2000 13:21:40 +0300 Content-Transfer-Encoding: 8bit Hi, The example tries to show an scenario where RSVP is used. Actually what you say is exactly the goal of this draft. The UAS has to wait until it receives the COMET, rather than relying on other mechanisms (such as the ResvConf in RSVP). Probably the example can be reworded, but I believe the meaning is clear enough. The draft basically outlines a mechanism that allows the UAC to ask the UAS to wait until a COMET from UAC to UAS arrives. The rest are just examples (such as the 3pcc) that help understand the need for the mechanism. Thanks for the feedback, Gonzalo > Mark Watson wrote: > > Gonzalo, > > A small comment: in section 1 your write: > > "As soon as the calleeÆs UA > has finished the resource reservation in the callee-caller > direction > (using RSVP for instance) and a COMET arrives from the caller > (confirming that resources are also available in the caller-callee > direction) the callee will be alerted." > > Reading the manyfolks draft 'cold', without having been involved in > the original discussions, I did not get the impression that there was > any asumption that the callee was responsible for 'callee->caller' > reservation and the caller for the reverse direction. This assumption > seems to be specific to certain reservation technologies. > > Rather, I read the draft as implying that the COMET from caller to > callee was sent when the caller had done 'whatever is necessary' to > provide the QoS/Security preconditions which were negotiated in the > SDP. > > Does there need to be an assumption about what 'whenever is necessary' > is ? Surely this, and whether or not the caller/callee needs the other > to confirm it, is dependent on the particular QoS technology being > used ? > > Regards, > > Mark Watson > Nortel Networks > > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > Sent: 09 October 2000 07:33 > To: sip > Subject: [SIP] Feedback on manyfolks > > Hi, > > Here you have a new I-D that contains feedback on the manyfolks draft. > > http://search.ietf.org/internet-drafts/draft-camarillo-manyfolks-confirm-00.txt > > " > Abstract > > This document describes certain functionality that is missing in > the > current "Integration of Resource Management and SIP" [1] (a.k.a. > manyfolks draft). An extension to add this functionality is > outlined. > > This functionality is needed in general to provide richer > signalling > capabilities and can be employed in several scenarios. This draft > describes its use in third party call control applications. > > If this extension is accepted it is foreseen that this draft would > be merged with [1]. > " > > Best regards, > > Gonzalo > -- > Gonzalo Camarillo Phone : +358 9 299 33 71 > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > Telecom R&D Fax : +358 9 299 30 52 > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > Finland http://www.hut.fi/~gonzalo > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland http://www.hut.fi/~gonzalo _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 9 07:24:00 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA01169 for ; Mon, 9 Oct 2000 07:24:00 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9648C44361; Mon, 9 Oct 2000 06:24:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from china.com (TCE-E-7-182-11.bta.net.cn [202.106.182.11]) by lists.bell-labs.com (Postfix) with SMTP id AF60E44336 for ; Mon, 9 Oct 2000 00:37:09 -0400 (EDT) Received: from china.com([10.1.7.100]) by china.com(JetMail 2.5.3.0) with SMTP id jm239e1c491; Mon, 9 Oct 2000 05:34:27 -0000 Content-Type: text/plain Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Message-ID: From: fordtrueman@china.com To: SIP@lists.bell-labs.com X-Priority: 3 Subject: [SIP] Consultation Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 9 Oct 2000 13:34:26 +0800 (CST) Content-Transfer-Encoding: 8bit Hi: I want to consult everyone one question? In RFC2543, 403 (forbidden) response, which is explained as " The server understood the request, but is refusing to fulfill it. Authorization will not help, and the request". Could anyone give me some detailed idea under what situation, the server refuse to fulfill it? is there any examples? Thank you very much! Yours: Ford SHOULD NOT be repeated. ---------------------------------------------- ÖлªÍø»ýÉÍÖ®ÂÃ,´ó½±ÈÎÄúÓ®£¡ http://points4u.china.com ²Î¼ÓÍøÉÏÅÄÂô£¬ÃûÈËÇ©ÃûÎïÆ·ÈÎÄãÕù! http://auction4u.china.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 9 07:25:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA01210 for ; Mon, 9 Oct 2000 07:25:03 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 599864436C; Mon, 9 Oct 2000 06:24:08 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lists.bell-labs.com (Postfix) with ESMTP id 33EC644361 for ; Mon, 9 Oct 2000 05:36:48 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00590; Mon, 9 Oct 2000 06:34:04 -0400 (EDT) Message-Id: <200010091034.GAA00590@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@lists.bell-labs.com From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: [SIP] I-D ACTION:draft-ietf-sip-srv-00.txt Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 09 Oct 2000 06:34:03 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : SIP: Session Initiation Protocol -- Locating SIP Servers Author(s) : H. Schulzrinne, J. Rosenberg Filename : draft-ietf-sip-srv-00.txt Pages : 6 Date : 06-Oct-00 This document describes how a SIP client locates a SIP server based on the Request-URI or a preconfigured outbound proxy server. This document updates the process described in RFC 2543. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-srv-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-srv-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-srv-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: <20001006130813.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-srv-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-srv-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001006130813.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 9 08:05:59 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA02116 for ; Mon, 9 Oct 2000 08:05:59 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 74C3544361; Mon, 9 Oct 2000 07:06:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from drago1.ubiquity.net (unknown [194.202.146.92]) by lists.bell-labs.com (Postfix) with SMTP id B276A44338 for ; Mon, 9 Oct 2000 07:05:46 -0400 (EDT) Received: from gecko.ubiquity.co.uk by drago1.ubiquity.net via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 9 Oct 2000 12:06:10 UT Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id NAA21737; Mon, 9 Oct 2000 13:03:57 +0100 (BST) From: "Jo Hornsby" To: , Subject: RE: [SIP] Consultation Message-ID: <001001c031e9$00d82480$4e34c3c1@ubiquity.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 9 Oct 2000 13:03:57 +0100 Content-Transfer-Encoding: 7bit > Hi: > I want to consult everyone one question? > In RFC2543, 403 (forbidden) response, which is explained as " > The server understood the request, but is refusing to fulfill it. > Authorization will not help, and the request". > > Could anyone give me some detailed idea under what > situation, the server > refuse to fulfill it? is there any examples? > Thank you very much! > Yours: Ford > SHOULD NOT be repeated. Off the top of my head: a Registrar which doesn't allow 3rd Party Registration might respond to a 3rd Party Registration Request with a 403. - Jo. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 9 14:56:14 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA08200 for ; Mon, 9 Oct 2000 14:56:14 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6E22C4433C; Mon, 9 Oct 2000 13:56:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from pigeon.vovida.com (a98.vovida.com [209.237.8.98]) by lists.bell-labs.com (Postfix) with ESMTP id 15F5644338 for ; Mon, 9 Oct 2000 13:55:51 -0400 (EDT) Received: from vovida.com ([209.237.8.113]) by pigeon.vovida.com (Netscape Messaging Server 4.15) with ESMTP id G26EXS00.ME9; Mon, 9 Oct 2000 11:49:04 -0700 Message-ID: <39E214B3.766B11C@vovida.com> From: Sunitha Kumar Organization: Vovida Networks X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14 i686) X-Accept-Language: en MIME-Version: 1.0 To: Bobby Sardana Cc: Amit Choksi , sip@lists.bell-labs.com Subject: Re: [SIP] SIP ISUP MIME draft References: <39DE73A6.6B178B28@vovida.com> <39DE8A2F.2A948F2D@mobilerain.com> Content-Type: multipart/alternative; boundary="------------65DAF07A53DBD9CEE6B52DFE" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 09 Oct 2000 11:55:48 -0700 --------------65DAF07A53DBD9CEE6B52DFE Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit The comment is on the single content length field value for the entire message. If this is considered, then, essentially we may not be able to encrypt a single content data. i.e We have to either encrypt the entire set of content data list, i.e maybe ISUP, SDP..etc; or none of them. Any comments on this? thanks sunitha Bobby Sardana wrote: > Hello Amit: > > Amit Choksi wrote: > > > Hi, > > I am having a doubt concerning a message containing multiple content > > types like SDP, ISUP, OSP. > > In a message containing multiple content types > > > > 1. Content-Length = 333 (example) > > Does this specify the length of the total all the Content-Types and > > corresponding data > > Yes. Total Length = (Header Length Count) + (Unique Boundary Count) + > (Message Count) > > > > > > > can we have individual content lengths for all content types ? > > No. From HTTP 1.1 Section 4.4 Message Length. > > > > > > > 2. When there are multiple Content-Types is it compulsory to have the > > first one as > > > > Content-Type: multipart/....; boundary = unique-boundary1 > > so that we can use the boundary all over , What if this is not > > there then can we just use CRLF as boundary > > Can conflict with message content that has CRLF in it. So to distinguish > between the two a boundary is needed. > > Hope this helps. > > Regards, > > Bobby.Sardana@mobilerain.com > > > > > > > or if it is not specified then can i just use CRLF as the delimiter > > > > Content-Type:application/OSP CRLF > > CRLF > > > > ....data..... > > > > unique-boundary1 > > Content-Type:application/ISUP;version-nxv3 CRLF > > CRLF > > > > .....data..... > > unique-boundary1 > > > > Please point out, if i have wrongly interpreted it. > > I greatly appreciate any help on this. > > > > Thanks > > Amit Choksi > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip -- Sunitha Kumar http://www.vovida.com --------------65DAF07A53DBD9CEE6B52DFE Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit The comment is on the single content length field value for the entire message. If this is considered, then, essentially we may not be able to encrypt a single content data. i.e We have to either encrypt the entire set of content data list, i.e maybe ISUP, SDP..etc; or none of them.

Any comments on this?

thanks
sunitha
 
 
 
 

Bobby Sardana wrote:

Hello Amit:

Amit Choksi wrote:

> Hi,
> I am having a doubt concerning a message containing multiple content
> types like SDP, ISUP, OSP.
> In a message containing multiple content types
>
> 1. Content-Length = 333 (example)
>     Does this specify the length of the total all the Content-Types and
> corresponding data

Yes. Total Length = (Header Length Count) + (Unique Boundary Count) +
(Message Count)

>
>
>     can we have individual content lengths for all content types ?

No. From HTTP 1.1 Section 4.4 Message Length.

>
>
> 2.  When there are multiple Content-Types is it compulsory to have the
> first one as
>
> Content-Type: multipart/....; boundary = unique-boundary1
>   so that we can use the boundary all over ,    What if this is not
> there then can we just use CRLF as boundary

Can conflict with message content that has CRLF in it. So to distinguish
between the two a boundary is needed.

Hope this helps.

Regards,

Bobby.Sardana@mobilerain.com

>
>
>  or if it is not specified then can i just use CRLF as the delimiter
>
>          Content-Type:application/OSP       CRLF
>          CRLF
>
>            ....data.....
>
>            unique-boundary1
>         Content-Type:application/ISUP;version-nxv3   CRLF
>         CRLF
>
>            .....data.....
>          unique-boundary1
>
> Please point out, if i have wrongly interpreted it.
> I greatly appreciate any help on this.
>
> Thanks
> Amit Choksi
>
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip

-- 
Sunitha Kumar
http://www.vovida.com
  --------------65DAF07A53DBD9CEE6B52DFE-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 9 15:12:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA08648 for ; Mon, 9 Oct 2000 15:12:00 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0989E4433D; Mon, 9 Oct 2000 14:12:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from wusr3.mobilerain.com (sdsl-208-185-234-252.dsl.sjc.megapath.net [208.185.234.252]) by lists.bell-labs.com (Postfix) with ESMTP id 7611F4433C for ; Mon, 9 Oct 2000 14:11:24 -0400 (EDT) Received: from mobilerain.com (IDENT:dsardana@localhost [127.0.0.1]) by wusr3.mobilerain.com (8.9.3/8.9.3) with ESMTP id MAA16073; Mon, 9 Oct 2000 12:09:31 -0700 Message-ID: <39E217EB.F5F8C751@mobilerain.com> From: Bobby Sardana Organization: MobileRain Technologies, Inc. X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: Sunitha Kumar Cc: Amit Choksi , sip@lists.bell-labs.com Subject: Re: [SIP] SIP ISUP MIME draft References: <39DE73A6.6B178B28@vovida.com> <39DE8A2F.2A948F2D@mobilerain.com> <39E214B3.766B11C@vovida.com> Content-Type: multipart/mixed; boundary="------------51E6B7639C9D9A9B76A839C0" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 09 Oct 2000 12:09:31 -0700 This is a multi-part message in MIME format. --------------51E6B7639C9D9A9B76A839C0 Content-Type: multipart/alternative; boundary="------------C7F8CA19C311850CE7FFCE83" --------------C7F8CA19C311850CE7FFCE83 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello Sunitha: Sunitha Kumar wrote: > The comment is on the single content length field value for the entire > message. If this is considered, This is a rule for encoding! > then, essentially we may not be able to encrypt a single content data. > i.e We have to either encrypt the entire set of content data list, i.e > maybe ISUP, SDP..etc; or none of them. Why not? Peform individual encryption of data for each corresponding type excluding the embedded headers, calculate the length and assign it to the Content-Length. The decoding is simple by extracting the individual content and decrypting it. For message transport, the Content-Length remains the same. Regards, Bobby.Sardana@mobilerain.com > > > Any comments on this? > > thanks > sunitha > > > > > > Bobby Sardana wrote: > >> Hello Amit: >> >> Amit Choksi wrote: >> >> > Hi, >> > I am having a doubt concerning a message containing multiple >> content >> > types like SDP, ISUP, OSP. >> > In a message containing multiple content types >> > >> > 1. Content-Length = 333 (example) >> > Does this specify the length of the total all the >> Content-Types and >> > corresponding data >> >> Yes. Total Length = (Header Length Count) + (Unique Boundary Count) >> + >> (Message Count) >> >> > >> > >> > can we have individual content lengths for all content types ? >> >> No. From HTTP 1.1 Section 4.4 Message Length. >> >> > >> > >> > 2. When there are multiple Content-Types is it compulsory to have >> the >> > first one as >> > >> > Content-Type: multipart/....; boundary = unique-boundary1 >> > so that we can use the boundary all over , What if this is >> not >> > there then can we just use CRLF as boundary >> >> Can conflict with message content that has CRLF in it. So to >> distinguish >> between the two a boundary is needed. >> >> Hope this helps. >> >> Regards, >> >> Bobby.Sardana@mobilerain.com >> >> > >> > >> > or if it is not specified then can i just use CRLF as the >> delimiter >> > >> > Content-Type:application/OSP CRLF >> > CRLF >> > >> > ....data..... >> > >> > unique-boundary1 >> > Content-Type:application/ISUP;version-nxv3 CRLF >> > CRLF >> > >> > .....data..... >> > unique-boundary1 >> > >> > Please point out, if i have wrongly interpreted it. >> > I greatly appreciate any help on this. >> > >> > Thanks >> > Amit Choksi >> > >> > _______________________________________________ >> > SIP mailing list >> > SIP@lists.bell-labs.com >> > http://lists.bell-labs.com/mailman/listinfo/sip > > -- > Sunitha Kumar > http://www.vovida.com > > --------------C7F8CA19C311850CE7FFCE83 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hello Sunitha:
 

Sunitha Kumar wrote:

The comment is on the single content length field value for the entire message. If this is considered,
This is a rule for encoding!
then, essentially we may not be able to encrypt a single content data. i.e We have to either encrypt the entire set of content data list, i.e maybe ISUP, SDP..etc; or none of them.
Why not? Peform individual encryption of data for each corresponding type excluding the embedded headers, calculate the length and assign it to the Content-Length. The decoding is simple by extracting the individual content and decrypting it. For message transport, the Content-Length remains the same.

Regards,

Bobby.Sardana@mobilerain.com

 

Any comments on this?

thanks
sunitha
 
 
 
 

Bobby Sardana wrote:

Hello Amit:

Amit Choksi wrote:

> Hi,
> I am having a doubt concerning a message containing multiple content
> types like SDP, ISUP, OSP.
> In a message containing multiple content types
>
> 1. Content-Length = 333 (example)
>     Does this specify the length of the total all the Content-Types and
> corresponding data

Yes. Total Length = (Header Length Count) + (Unique Boundary Count) +
(Message Count)

>
>
>     can we have individual content lengths for all content types ?

No. From HTTP 1.1 Section 4.4 Message Length.

>
>
> 2.  When there are multiple Content-Types is it compulsory to have the
> first one as
>
> Content-Type: multipart/....; boundary = unique-boundary1
>   so that we can use the boundary all over ,    What if this is not
> there then can we just use CRLF as boundary

Can conflict with message content that has CRLF in it. So to distinguish
between the two a boundary is needed.

Hope this helps.

Regards,

Bobby.Sardana@mobilerain.com

>
>
>  or if it is not specified then can i just use CRLF as the delimiter
>
>          Content-Type:application/OSP       CRLF
>          CRLF
>
>            ....data.....
>
>            unique-boundary1
>         Content-Type:application/ISUP;version-nxv3   CRLF
>         CRLF
>
>            .....data.....
>          unique-boundary1
>
> Please point out, if i have wrongly interpreted it.
> I greatly appreciate any help on this.
>
> Thanks
> Amit Choksi
>
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip

-- 
Sunitha Kumar
http://www.vovida.com
 
--------------C7F8CA19C311850CE7FFCE83-- --------------51E6B7639C9D9A9B76A839C0 Content-Type: text/x-vcard; charset=us-ascii; name="bobby.sardana.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Bobby Sardana Content-Disposition: attachment; filename="bobby.sardana.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Sardana;Bobby x-mozilla-html:FALSE org:MobileRain Technologies, Inc.;Telecommunications adr:;;;;;; version:2.1 email;internet:bobby.sardana@mobilerain.com title:Engineer x-mozilla-cpt:;0 fn:Bobby Sardana end:vcard --------------51E6B7639C9D9A9B76A839C0-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 9 18:47:11 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA10754 for ; Mon, 9 Oct 2000 18:47:10 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2029C4433C; Mon, 9 Oct 2000 17:47:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mail2.siemenscom.com (mail2.siemenscom.com [206.154.192.5]) by lists.bell-labs.com (Postfix) with ESMTP id BE95E44338 for ; Mon, 9 Oct 2000 17:46:16 -0400 (EDT) Received: from pobox.rolm.com (gate.siemenscom.com [206.154.192.3]) by mail2.siemenscom.com (8.9.3/8.9.3) with ESMTP id PAA19307 for ; Mon, 9 Oct 2000 15:36:17 -0700 (PDT) Received: from STCA100A.bus.sc.rolm.com by pobox.rolm.com with ESMTP for SIP@lists.bell-labs.com; Mon, 9 Oct 2000 15:46:11 -0700 Received: by stca100a.bus.sc.rolm.com with Internet Mail Service (5.5.2650.21) id ; Mon, 9 Oct 2000 15:46:09 -0700 Message-Id: <19B014596613D111AA08006097937C1003152454@stca902a.eng.sc.rolm.com> From: "Burger, Christian" To: "'SIP@lists.bell-labs.com'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] Session Information Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 9 Oct 2000 15:46:01 -0700 Hi, I had a question concerning Session Information that can be sent via SIP (or in fact SDP). I did not find a size limit as to how much text could this way be conveyed. Is there such a limit of how much can be sent with a SIP message? Greetings, Christian Burger E-mail: Christian.Burger@icn.siemens.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 9 18:55:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA10843 for ; Mon, 9 Oct 2000 18:55:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2AE224433C; Mon, 9 Oct 2000 17:55:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from pigeon.vovida.com (a98.vovida.com [209.237.8.98]) by lists.bell-labs.com (Postfix) with ESMTP id D9DAE44338 for ; Mon, 9 Oct 2000 17:54:53 -0400 (EDT) Received: from vovida.com ([209.237.8.113]) by pigeon.vovida.com (Netscape Messaging Server 4.15) with ESMTP id G26Q0600.SDZ; Mon, 9 Oct 2000 15:48:06 -0700 Message-ID: <39E24CBC.BB472E00@vovida.com> From: Sunitha Kumar Organization: Vovida Networks X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14 i686) X-Accept-Language: en MIME-Version: 1.0 To: "Burger Christian" Cc: "'SIP@lists.bell-labs.com'" Subject: Re: [SIP] Session Information References: <19B014596613D111AA08006097937C1003152454@stca902a.eng.sc.rolm.com> Content-Type: multipart/alternative; boundary="------------4F900765E7EC8CD46D6318FD" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 09 Oct 2000 15:54:52 -0700 --------------4F900765E7EC8CD46D6318FD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Christian: The maximum size of the SIP message , including the content data MUST be within the bounds of 1500 bytes, inorder to prevent fragmentation of packets. Please refer Section 3, of the August 6, SIP draft. sunitha "Burger, Christian" wrote: > Hi, > > I had a question concerning Session Information that can be sent via SIP (or > in fact SDP). > I did not find a size limit as to how much text could this way be conveyed. > Is there such a limit of how much can be sent with a SIP message? > Greetings, > > Christian Burger > E-mail: Christian.Burger@icn.siemens.com > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip -- Sunitha Kumar http://www.vovida.com --------------4F900765E7EC8CD46D6318FD Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Christian:

The maximum size of the SIP message , including the content data MUST be within the bounds of 1500 bytes, inorder to prevent fragmentation of packets. Please refer Section 3, of the August 6, SIP draft.

sunitha
 
 
 
 
 

"Burger, Christian" wrote:

Hi,

I had a question concerning Session Information that can be sent via SIP (or
in fact SDP).
I did not find a size limit as to how much text could this way be conveyed.
Is there such a limit of how much can be sent with a SIP message?
Greetings,

Christian Burger
E-mail: Christian.Burger@icn.siemens.com

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip

-- 
Sunitha Kumar
http://www.vovida.com
  --------------4F900765E7EC8CD46D6318FD-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 9 21:51:15 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA13466 for ; Mon, 9 Oct 2000 21:51:15 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 234C04433C; Mon, 9 Oct 2000 20:51:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cybertron.div8.net (el05-24-131-150-91.ce.mediaone.net [24.131.150.91]) by lists.bell-labs.com (Postfix) with ESMTP id 6DD0744338 for ; Mon, 9 Oct 2000 18:35:37 -0400 (EDT) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for sip@lists.bell-labs.com; Mon, 9 Oct 2000 18:35:33 -0500 (CDT) From: Billy Biggs To: SIP Mailing List Message-ID: <20001009183533.A10195@div8.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i Subject: [SIP] Mid-Call Redirects with a Route Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 9 Oct 2000 18:35:33 -0500 Hi, If I get redirected (say a 302) on a re-INVITE or BYE request on an active call-leg end, and the call-leg has a Route, what do I do? My possible suggestions: a) Use the Record-Route and Contact from the redirect response to build a Route header for my new transaction. This seems inconsistent, unless I also honor the Record-Route on a 300-class response to an initial INVITE. But hey, maybe I should do that too? b) Place the Contact at the end of the current Route list, and hope it was the last guy who redirected me. This scares me. c) Use the Contact as the Request-URI, keep the Route the same, and mess things up completely. Definitely broken. d) Drop the Route completely and hope this never happens. Regarding (a), am I correct in assuming that with every transaction the Route is rebuilt completely, not just a possible update of the Contact address at the end? -- Billy Biggs, 3Com Billy_Biggs@3com.com http://www.div8.net/billy/ bbiggs@div8.net _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 9 23:28:59 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA14986 for ; Mon, 9 Oct 2000 23:28:59 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id ED51A4433C; Mon, 9 Oct 2000 22:29:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mars.hss.co.in (unknown [202.54.26.197]) by lists.bell-labs.com (Postfix) with ESMTP id D8B9644338 for ; Mon, 9 Oct 2000 22:28:39 -0400 (EDT) Received: from sampark.hss.hns.com (sampark [139.85.229.22]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id e9A3SZC24262; Tue, 10 Oct 2000 08:58:35 +0530 (IST) Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 65256974.00136965 ; Tue, 10 Oct 2000 09:02:01 +0530 X-Lotus-FromDomain: HSSBLR From: archow@hss.hns.com To: Sunitha Kumar Cc: "Burger Christian" , "'SIP@lists.bell-labs.com'" Message-ID: <65256974.001367AE.00@sampark.hss.hns.com> Subject: Re: [SIP] Session Information Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=IEW0qydviBbXkKxBFdxHj1XYIRIBQLISpIQ4ctJkc2GWZjD2yiGnAIaq" Content-Disposition: inline Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 10 Oct 2000 09:01:53 +0530 --0__=IEW0qydviBbXkKxBFdxHj1XYIRIBQLISpIQ4ctJkc2GWZjD2yiGnAIaq Content-type: text/plain; charset=us-ascii Content-Disposition: inline sk> The maximum size of the SIP message , including the content data MUST be within sk> the bounds of 1500 bytes, inorder to prevent fragmentation of packets. Please sk> refer Section 3, of the August 6, SIP draft. No, that is not true, The draft mentions that it as a SHOULD and I think that is hardly true now. Even 'typical' SIP messages cross well over 2000 bytes, especially with all these new extensions chipping into the message. Afaik, there is no MUST limit (maybe except the max size allocated to a n/w read kernel buffer - usually 64k ? ) as such for the length of payload- just that try and keep it as short as possible, and if its getting really big, look at the new message and see if you really should be doing it wrapped in SIP or not. Regds Arjun -- Arjun Roychowdhury @ Hughes Software Systems Sunitha Kumar on 10/10/2000 04:24:52 AM To: "Burger Christian" cc: "'SIP@lists.bell-labs.com'" Subject: Re: [SIP] Session Information Christian: The maximum size of the SIP message , including the content data MUST be within the bounds of 1500 bytes, inorder to prevent fragmentation of packets. Please refer Section 3, of the August 6, SIP draft. sunitha "Burger, Christian" wrote: > Hi, > > I had a question concerning Session Information that can be sent via SIP (or > in fact SDP). > I did not find a size limit as to how much text could this way be conveyed. > Is there such a limit of how much can be sent with a SIP message? > Greetings, > > Christian Burger > E-mail: Christian.Burger@icn.siemens.com > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip -- Sunitha Kumar http://www.vovida.com --0__=IEW0qydviBbXkKxBFdxHj1XYIRIBQLISpIQ4ctJkc2GWZjD2yiGnAIaq Content-type: text/html; name="att-1.htm" Content-Disposition: attachment; filename="att-1.htm" Content-Description: Internet HTML Content-Transfer-Encoding: base64 PCFkb2N0eXBlIGh0bWwgcHVibGljICItLy93M2MvL2R0ZCBodG1sIDQuMCB0cmFuc2l0aW9uYWwv L2VuIj4NCjxodG1sPg0KQ2hyaXN0aWFuOg0KPHA+VGhlIG1heGltdW0gc2l6ZSBvZiB0aGUgU0lQ IG1lc3NhZ2UgLCBpbmNsdWRpbmcgdGhlIGNvbnRlbnQgZGF0YSBNVVNUDQpiZSB3aXRoaW4gdGhl IGJvdW5kcyBvZiAxNTAwIGJ5dGVzLCBpbm9yZGVyIHRvIHByZXZlbnQgZnJhZ21lbnRhdGlvbiBv Zg0KcGFja2V0cy4gUGxlYXNlIHJlZmVyIFNlY3Rpb24gMywgb2YgdGhlIEF1Z3VzdCA2LCBTSVAg ZHJhZnQuDQo8cD5zdW5pdGhhDQo8YnI+Jm5ic3A7DQo8YnI+Jm5ic3A7DQo8YnI+Jm5ic3A7DQo8 YnI+Jm5ic3A7DQo8YnI+Jm5ic3A7DQo8cD4iQnVyZ2VyLCBDaHJpc3RpYW4iIHdyb3RlOg0KPGJs b2NrcXVvdGUgVFlQRT1DSVRFPkhpLA0KPHA+SSBoYWQgYSBxdWVzdGlvbiBjb25jZXJuaW5nIFNl c3Npb24gSW5mb3JtYXRpb24gdGhhdCBjYW4gYmUgc2VudCB2aWENClNJUCAob3INCjxicj5pbiBm YWN0IFNEUCkuDQo8YnI+SSBkaWQgbm90IGZpbmQgYSBzaXplIGxpbWl0IGFzIHRvIGhvdyBtdWNo IHRleHQgY291bGQgdGhpcyB3YXkgYmUgY29udmV5ZWQuDQo8YnI+SXMgdGhlcmUgc3VjaCBhIGxp bWl0IG9mIGhvdyBtdWNoIGNhbiBiZSBzZW50IHdpdGggYSBTSVAgbWVzc2FnZT8NCjxicj5HcmVl dGluZ3MsDQo8cD5DaHJpc3RpYW4gQnVyZ2VyDQo8YnI+RS1tYWlsOiBDaHJpc3RpYW4uQnVyZ2Vy QGljbi5zaWVtZW5zLmNvbQ0KPHA+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCjxicj5TSVAgbWFpbGluZyBsaXN0DQo8YnI+U0lQQGxpc3RzLmJlbGwtbGFi cy5jb20NCjxicj48YSBocmVmPSJodHRwOi8vbGlzdHMuYmVsbC1sYWJzLmNvbS9tYWlsbWFuL2xp c3RpbmZvL3NpcCI+aHR0cDovL2xpc3RzLmJlbGwtbGFicy5jb20vbWFpbG1hbi9saXN0aW5mby9z aXA8L2E+PC9ibG9ja3F1b3RlPg0KDQo8cHJlPi0tJm5ic3A7DQpTdW5pdGhhIEt1bWFyDQo8QSBI UkVGPSJodHRwOi8vd3d3LnZvdmlkYS5jb20iPmh0dHA6Ly93d3cudm92aWRhLmNvbTwvQT48L3By ZT4NCiZuYnNwOzwvaHRtbD4NCg0K --0__=IEW0qydviBbXkKxBFdxHj1XYIRIBQLISpIQ4ctJkc2GWZjD2yiGnAIaq-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 10 00:29:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA15832 for ; Tue, 10 Oct 2000 00:29:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id DF94C44338; Mon, 9 Oct 2000 23:29:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id E2A1F44338 for ; Mon, 9 Oct 2000 23:28:55 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA09019; Tue, 10 Oct 2000 00:30:32 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Tue, 10 Oct 2000 00:24:50 -0400 Message-ID: From: Jonathan Rosenberg To: "'archow@hss.hns.com'" , "'Sunitha Kumar'" Cc: "'Burger Christian'" , "'SIP@lists.bell-labs.com'" Subject: RE: [SIP] Session Information MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 10 Oct 2000 00:24:50 -0400 > -----Original Message----- > From: archow@hss.hns.com [mailto:archow@hss.hns.com] > Sent: Monday, October 09, 2000 11:32 PM > To: Sunitha Kumar > Cc: Burger Christian; 'SIP@lists.bell-labs.com' > Subject: Re: [SIP] Session Information > > > > > > > sk> The maximum size of the SIP message , including the > content data MUST > be within > sk> the bounds of 1500 bytes, inorder to prevent > fragmentation of packets. > Please > sk> refer Section 3, of the August 6, SIP draft. > > > No, that is not true, The draft mentions that it as a SHOULD > and I think > that is hardly > true now. Even 'typical' SIP messages cross well over 2000 bytes, > especially with all these > new extensions chipping into the message. Correct. In fact, I think this 1500 limit needs to be qualified or changed. > > Afaik, there is no MUST limit (maybe except the max size > allocated to a n/w > read kernel buffer - usually 64k ? ) Maximum IP packed size is 64K, so this represents the absolute upper bound on a SIP message. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 10 02:03:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA26647 for ; Tue, 10 Oct 2000 02:03:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id F07E24433C; Tue, 10 Oct 2000 01:03:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 8E2B144338 for ; Tue, 10 Oct 2000 01:02:10 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA09254; Tue, 10 Oct 2000 02:04:12 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Tue, 10 Oct 2000 01:58:30 -0400 Message-ID: From: Jonathan Rosenberg To: "'Billy Biggs'" , "'SIP Mailing List'" Subject: RE: [SIP] Mid-Call Redirects with a Route MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 10 Oct 2000 01:58:29 -0400 Yuck. See comments below. > -----Original Message----- > From: Billy Biggs [mailto:Billy_Biggs@3com.com] > Sent: Monday, October 09, 2000 7:36 PM > To: SIP Mailing List > Subject: [SIP] Mid-Call Redirects with a Route > > > Hi, > > If I get redirected (say a 302) on a re-INVITE or BYE request on an > active call-leg end, and the call-leg has a Route, what do I do? This should really never happen. I don't think there is any happy solution in this case. Is there a specific scenario you were thinking of? > > My possible suggestions: > > a) Use the Record-Route and Contact from the redirect response to > build a Route header for my new transaction. > > This seems inconsistent, unless I also honor the > Record-Route on a > 300-class response to an initial INVITE. But hey, maybe I should > do that too? > > b) Place the Contact at the end of the current Route list, > and hope it > was the last guy who redirected me. This scares me. > > c) Use the Contact as the Request-URI, keep the Route the same, and > mess things up completely. Definitely broken. > > d) Drop the Route completely and hope this never happens. > > Regarding (a), am I correct in assuming that with every transaction > the Route is rebuilt completely, not just a possible update of the > Contact address at the end? No, thats not correct. Since its currently only for the initial INVITE, it would not be backwards compatible to mandate it for each transaction. The latest bis says proxies should insert it, but UAs shouldn't use it for a new Route (only the Contact can change after call is setup). Seems useless, but it can help if there is a crash and restart. Anyway, the only reasonable thing to do in this case would be (d). Although, as I said, I can't imagine when this would ever happen. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 10 02:37:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA29080 for ; Tue, 10 Oct 2000 02:37:00 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D6EF44433C; Tue, 10 Oct 2000 01:37:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 98D8544338 for ; Tue, 10 Oct 2000 01:36:12 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA09329; Tue, 10 Oct 2000 02:38:13 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Tue, 10 Oct 2000 02:32:31 -0400 Message-ID: From: Jonathan Rosenberg To: "'Gonzalo Camarillo'" , "'sip'" Subject: RE: [SIP] Feedback on manyfolks MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 10 Oct 2000 02:32:29 -0400 This seems reasonable to me, and needed, as Gonzalo points out. My only issue is whether all this stuff should be optional at all. Wouldn't it be easier if both sides always sent COMET, period? All this negotiation stuff is a pain. We're not talking tons of messages here. Can't we keep it simple? -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > Sent: Monday, October 09, 2000 2:33 AM > To: sip > Subject: [SIP] Feedback on manyfolks > > > Hi, > > Here you have a new I-D that contains feedback on the manyfolks draft. > > http://search.ietf.org/internet-drafts/draft-camarillo-manyfol > ks-confirm-00.txt > > " > Abstract > > This document describes certain functionality that is > missing in the > current "Integration of Resource Management and SIP" [1] (a.k.a. > manyfolks draft). An extension to add this functionality is > outlined. > > This functionality is needed in general to provide richer > signalling > capabilities and can be employed in several scenarios. This draft > describes its use in third party call control applications. > > If this extension is accepted it is foreseen that this draft would > be merged with [1]. > " > > Best regards, > > Gonzalo > -- > Gonzalo Camarillo Phone : +358 9 299 33 71 > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > Telecom R&D Fax : +358 9 299 30 52 > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > Finland http://www.hut.fi/~gonzalo > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 10 02:43:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA29113 for ; Tue, 10 Oct 2000 02:43:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4FDD34436C; Tue, 10 Oct 2000 01:43:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 86E734433C for ; Tue, 10 Oct 2000 01:42:53 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA09341; Tue, 10 Oct 2000 02:44:52 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Tue, 10 Oct 2000 02:39:11 -0400 Message-ID: From: Jonathan Rosenberg To: "'Mark Watson'" , Jonathan Rosenberg , "'Gonzalo.Camarillo@lmf.ericsson.se'" Cc: "'sip@lists.bell-labs.com'" Subject: RE: [SIP] FW: Delaying alerting at UAS MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 10 Oct 2000 02:39:08 -0400 -----Original Message----- >From: Mark Watson [mailto:mwatson@nortelnetworks.com] >Sent: Monday, October 09, 2000 5:50 AM >To: 'Jonathan Rosenberg'; Mark Watson; 'Gonzalo.Camarillo@lmf.ericsson.se' >Cc: 'sip@lists.bell-labs.com' >Subject: RE: [SIP] FW: Delaying alerting at UAS > > >Jonathan, >Mayby I am missing something, but if there are multiple hops, with different transports, >then there is always a stateful proxy on the boundry between the reliable transport hops >and the unreliable transport hops (I understand that proxies supporting reliable transport >must be stateful - perhaps that it where I am wrong ?) > >This proxy on the boundry could provide the PRACKs on the unreliable transport hops. We've been down that path. Doing PRACK hop by hop was a huge nightmare. It had backwards compatibility problems, had difficulties dealing with forking, etc. Thats why we settled on the e2e model, which works just like 200 OK for INVITE. In any case, there is a reasonable (not great, but reasonable) separation of SIP function from transport details right now. There is currently no SIP message which does or does not get sent based on the transport, and I'd rather not change that. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 10 02:56:00 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA29177 for ; Tue, 10 Oct 2000 02:56:00 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6822F4436C; Tue, 10 Oct 2000 01:56:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id C6F154433C for ; Tue, 10 Oct 2000 01:55:35 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA09374; Tue, 10 Oct 2000 02:57:15 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Tue, 10 Oct 2000 02:51:33 -0400 Message-ID: From: Jonathan Rosenberg To: "'Jon.Peterson@Level3.com'" , "'bodgey@in.huawei.com'" Cc: "'sip@lists.bell-labs.com'" Subject: RE: [SIP] The Option-tag of supported: MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 10 Oct 2000 02:51:32 -0400 There are several ways that SIp is extended, and there are different ways to indicate/negotiate that depending on which one is used. For new methods (i.e, INFO) the 405/Allow mechanism is used. For new content in the bodies, the 415/Accept mechanism is used. For extensions that include new headers/semantics, the 420/Require mechanism (which usage option tags), is used. Each draft that is a real extension defines a new option tag. When these become RFCs, those tags are registered with IANA. As Jon points out, SIP-T is not a real extension; it uses a new method and some new bodies, and is thus covered by the 405/Allow and 415/Accept mechanisms. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com > -----Original Message----- > From: Jon.Peterson@Level3.com [mailto:Jon.Peterson@Level3.com] > Sent: Saturday, October 07, 2000 3:03 PM > To: bodgey@in.huawei.com > Cc: sip@lists.bell-labs.com > Subject: RE: [SIP] The Option-tag of supported: > > > The process of encapsulating ISUP in and of itself does not currently > require any kind of option-tag. It is generally desirable in > SIP-T that an > endpoint should process ISUP if possible (if it's a gateway), > but ignore it > if not. The Content-Disposition header can therefore specify > whether or not > the handling of any particular MIME body is required for the > session to > continue. So, essentially, the Content-Disposition header can > be used to > communicate whether or not ISUP needs to be used. Supplying > additional MIME > bodies is a function of the multipart/mixed MIME type, not an > extension to > SIP. > > INFO and, if necessary, PRACK for SIP-T can be marked as > Required/Supported. > I don't really have any feelings one way or another about > grouping multiple > option-tags under umbrella tags, except in so far as it seems > like there > will be more symbols that an endpoint will have to be able to > recognize, > even if there are less tags transmitted in any particular signal. > > Jon Peterson > Level(3) Communications > > -----Original Message----- > From: Bodgey [mailto:bodgey@in.huawei.com] > Sent: Saturday, October 07, 2000 6:52 AM > To: sip@lists.bell-labs.com > Subject: [SIP] The Option-tag of supported: > > > Hi, > I have some questions of Option-tag. Now there are many > extesions of SIP, a > sip entity must use "Supported" header to indicate what > extension the it > support so that it can communicate with other entitys with the same > function. Is there some option-tags to indicate extensions of all the > extension such as PRACK, INFO, MIME for ISUP etc? > On other hand, the SIP-T contain many extensions such as PRACK, INFO. > Perhaps, we can use one Option-tag to indicate it, isn't it? > Would someone give a answer? Thanks! > > Bodgey > > > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 10 03:22:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA29391 for ; Tue, 10 Oct 2000 03:22:00 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 99B0C4433C; Tue, 10 Oct 2000 02:22:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 3A91244338 for ; Tue, 10 Oct 2000 02:21:34 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id DAA09404; Tue, 10 Oct 2000 03:23:25 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Tue, 10 Oct 2000 03:17:43 -0400 Message-ID: From: Jonathan Rosenberg To: "'vkg@lucent.com'" , "'Jo Hornsby'" Cc: "'sip@lists.bell-labs.com'" Subject: RE: [SIP] Second branch parameter MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 10 Oct 2000 03:17:42 -0400 > -----Original Message----- > From: Vijay K. Gurbani [mailto:vkg@lucent.com] > Sent: Tuesday, October 03, 2000 3:25 PM > To: Jo Hornsby > Cc: sip@lists.bell-labs.com > Subject: Re: [SIP] Second branch parameter > > > Henning/Jonathan: > > Should we chop off the word "second" (vis-a-vis the branch parameter) > from the definition of an isomorphic request, as Jo suggests? > I am for > it. For all its worth, I was confused on the initial reading of the > definition and reconciliation of how the branch parameter is > constructed. > > Comments? I agree. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 10 04:12:00 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA29687 for ; Tue, 10 Oct 2000 04:12:00 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7444F4433C; Tue, 10 Oct 2000 03:12:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from drago1.ubiquity.net (unknown [194.202.146.92]) by lists.bell-labs.com (Postfix) with SMTP id 4BA8F44338 for ; Tue, 10 Oct 2000 03:11:11 -0400 (EDT) Received: from gecko.ubiquity.co.uk by drago1.ubiquity.net via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 10 Oct 2000 08:11:35 UT Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id JAA21250; Tue, 10 Oct 2000 09:09:10 +0100 (BST) From: "Jo Hornsby" To: "Jonathan Rosenberg" , , "'Sunitha Kumar'" Cc: "'Burger Christian'" , Subject: RE: [SIP] Session Information Message-ID: <000a01c03291$5e0c6050$4e34c3c1@ubiquity.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 10 Oct 2000 09:09:09 +0100 Content-Transfer-Encoding: 7bit > > Afaik, there is no MUST limit (maybe except the max size > > allocated to a n/w read kernel buffer - usually 64k ? ) > > Maximum IP packed size is 64K, so this represents the absolute upper > bound on a SIP message. How about if I have TCP connection between two UAs, for example? I agree in the general case one cannot know whether UDP (or other unreliable transport) will be used anywhere along the signalling path, but should this rule out messages > 64K? Cheers, - Jo. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 10 04:18:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA29723 for ; Tue, 10 Oct 2000 04:18:00 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 55D4444384; Tue, 10 Oct 2000 03:18:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 857D84433C for ; Tue, 10 Oct 2000 03:17:28 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id EAA09519; Tue, 10 Oct 2000 04:19:29 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Tue, 10 Oct 2000 04:13:47 -0400 Message-ID: From: Jonathan Rosenberg To: "'Eric Tremblay'" , "'sip@lists.bell-labs.com'" Subject: RE: [SIP] Registrars and Date MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 10 Oct 2000 04:13:47 -0400 Good catch. Wouldn't life be easier if every device had a GPS receiver with completely syncrhonized time.... oh well. ANyway, there are a few possible solutions here: 1. always send a response with a delta-time if the request had an expires with a delta-time 2. always use relative times in register responses 3. always send Date in the 200 OK response to INVITE The third solution is what is proposed by Eric. 2 and 3 assume that registrars have access to the date. I thinks its a reasonable assumption. The easiest solution for all is probably 2, as it eliminates another option. But, I suspect that there are already implementations that always send absolute times. Comments? -Jonathan R. > -----Original Message----- > From: Eric Tremblay [mailto:etremblay@mediatrix.com] > Sent: Wednesday, September 27, 2000 11:14 AM > To: sip@lists.bell-labs.com > Subject: [SIP] Registrars and Date > > > > I have a very simple question/request: > > Would it be possible to make the Date header mandatory in Registrar > responses? This would be required if the registrar sends its > expires time > in SIP-date format. > > The reason for this are the following: > > 1- Some embedded devices don't keep track of the time at all. > 2- Other that do might be connecting to a NTP/SNTP server to > acquire the > notion of time (probably at bootup). What if the server is down? The > device has no knowledge of the time. This sould not prevent > the device from > registering. If the date header is not included, the device > cannot know for > how long the registration is valid, until the time server > comes back up. > > Regards, > > EricT > > ___________________________________________ > Eric Tremblay | Mediatrix Telecom Inc. > Technical Leader | www.mediatrix.com > > etremblay@mediatrix.com > tel: +1-819-829-8749 x238 > fax: +1-819-829-5100 > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 10 04:25:58 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA29773 for ; Tue, 10 Oct 2000 04:25:58 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 72ABF44384; Tue, 10 Oct 2000 03:26:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 133064433C for ; Tue, 10 Oct 2000 03:25:37 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id EAA09536; Tue, 10 Oct 2000 04:27:35 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Tue, 10 Oct 2000 04:21:53 -0400 Message-ID: From: Jonathan Rosenberg To: "'Jo Hornsby'" , Jonathan Rosenberg , "'archow@hss.hns.com'" , "'Sunitha Kumar'" Cc: "'Burger Christian'" , "'SIP@lists.bell-labs.com'" Subject: RE: [SIP] Session Information MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 10 Oct 2000 04:21:53 -0400 Hmm. TCP itself would be able to handle SIP messages above 64k, yes. It would just send them in multiple IP packets. The problem is, if we have a scenario of TCP->UDP->TCP through proxies, that UDP hop is not going to work. We could mandate the usage of TCP for sending messages over a certain size. I'm not that fond of this approach, though. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com > -----Original Message----- > From: Jo Hornsby [mailto:jhornsby@ubiquity.net] > Sent: Tuesday, October 10, 2000 4:09 AM > To: Jonathan Rosenberg; archow@hss.hns.com; 'Sunitha Kumar' > Cc: 'Burger Christian'; SIP@lists.bell-labs.com > Subject: RE: [SIP] Session Information > > > > > Afaik, there is no MUST limit (maybe except the max size > > > allocated to a n/w read kernel buffer - usually 64k ? ) > > > > Maximum IP packed size is 64K, so this represents the absolute upper > > bound on a SIP message. > > How about if I have TCP connection between two UAs, for example? > I agree in the general case one cannot know whether UDP (or other > unreliable transport) will be used anywhere along the signalling > path, but should this rule out messages > 64K? > > Cheers, > > > - Jo. > > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 10 04:50:00 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA29903 for ; Tue, 10 Oct 2000 04:50:00 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 235164433C; Tue, 10 Oct 2000 03:50:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mars.hss.co.in (unknown [202.54.26.197]) by lists.bell-labs.com (Postfix) with ESMTP id CB1B644338 for ; Tue, 10 Oct 2000 03:49:55 -0400 (EDT) Received: from sampark.hss.hns.com (sampark [139.85.229.22]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id e9A8nPC04570; Tue, 10 Oct 2000 14:19:25 +0530 (IST) Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 65256974.0030CAA5 ; Tue, 10 Oct 2000 14:22:56 +0530 X-Lotus-FromDomain: HSSBLR From: archow@hss.hns.com To: Jonathan Rosenberg Cc: "'Jo Hornsby'" , Jonathan Rosenberg , archow@hss.hns.com, "'Sunitha Kumar'" , "'Burger Christian'" , "'SIP@lists.bell-labs.com'" Message-ID: <65256974.0030C97C.00@sampark.hss.hns.com> Subject: RE: [SIP] Session Information Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 10 Oct 2000 14:22:52 +0530 Yes, Im not keen on having to mandate a protocol just for some size message. Then, we would be saying that 'for this type of message, SIP is transport dependant' . And if we must make it transport independant, lot of dirty application level breakup and co-relation of UDP would be needed - does not seem to be worth it. Also, isnt 64K size enough to put SIP into a 'bulk transporter' something which its not supposed to be ? imho, the 64k limit is really enough (hoping that this does not go down as the infamous '640K memory is all that a computer needs' quote way) . Regds Arjun -- Arjun Roychowdhury @ Hughes Software Systems Jonathan Rosenberg on 10/10/2000 01:51:53 PM To: "'Jo Hornsby'" , Jonathan Rosenberg , archow, "'Sunitha Kumar'" cc: "'Burger Christian'" , "'SIP@lists.bell-labs.com'" Subject: RE: [SIP] Session Information Hmm. TCP itself would be able to handle SIP messages above 64k, yes. It would just send them in multiple IP packets. The problem is, if we have a scenario of TCP->UDP->TCP through proxies, that UDP hop is not going to work. We could mandate the usage of TCP for sending messages over a certain size. I'm not that fond of this approach, though. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com > -----Original Message----- > From: Jo Hornsby [mailto:jhornsby@ubiquity.net] > Sent: Tuesday, October 10, 2000 4:09 AM > To: Jonathan Rosenberg; archow@hss.hns.com; 'Sunitha Kumar' > Cc: 'Burger Christian'; SIP@lists.bell-labs.com > Subject: RE: [SIP] Session Information > > > > > Afaik, there is no MUST limit (maybe except the max size > > > allocated to a n/w read kernel buffer - usually 64k ? ) > > > > Maximum IP packed size is 64K, so this represents the absolute upper > > bound on a SIP message. > > How about if I have TCP connection between two UAs, for example? > I agree in the general case one cannot know whether UDP (or other > unreliable transport) will be used anywhere along the signalling > path, but should this rule out messages > 64K? > > Cheers, > > > - Jo. > > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 10 04:58:59 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA29940 for ; Tue, 10 Oct 2000 04:58:59 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5BA3B4433C; Tue, 10 Oct 2000 03:59:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from web5302.mail.yahoo.com (web5302.mail.yahoo.com [216.115.106.111]) by lists.bell-labs.com (Postfix) with SMTP id B68DB44338 for ; Tue, 10 Oct 2000 03:58:17 -0400 (EDT) Message-ID: <20001010085810.10144.qmail@web5302.mail.yahoo.com> Received: from [12.10.198.194] by web5302.mail.yahoo.com; Tue, 10 Oct 2000 01:58:10 PDT From: Anubhav Srivastav Subject: Re: [SIP] SIP Mobility To: Samir Chatterjee , farhan Cc: sip MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 10 Oct 2000 01:58:10 -0700 (PDT) Thanks Samir and Farhan, I am still going thru the refrences you have given. I agree that user mobility is well taken care at application level with SIP etc. Now SIP uses (though it can use other mechanisms also) transport layer L4 for data transfer (UDP, TCP). Now SIP is worried about terminal mobility (giving rise to continuous mobility as discussed earlier). Now the existing solutions for IP domain (Mobile IP) seems to be inefficient to lot of us and that happens because M-IP tries to solve the problem at L3. Other approaches also try to solve the problem at L2. Both of above lead to the actual data transfer path getting unnecessarily long just to keep the L4 unchanged. According to me the hand-off problem is best solved at L4 where L4 knows that its L3 SAP (service access point) is being changed and hence can actually make use of the most efficient data path. I would like to know if there has been any work in this area.. This solution should not affect SIP at all as it is anyway using L4 only. Thanks Anubhav --- Samir Chatterjee wrote: > We may be unnecessarily complicating things here. > Most of what you > mention below is happening at link layer (L2) and > below and even L3 may > be oblivious. Keep in mind that SIP is an > application layer signaling > protocol that works over IP (L3). IP addresses has 2 > parts (NetID, > hostID). A host attached to a network will get the > same netID prefix. In > case of mobility, there are 2 cases. First, the host > may be hopping > between networks (discrete mobility) and gets a > dynamic IP address each > time it connects. Mobile IP takes care of most > things in this case. The > other difficult case is continuous mobility in which > the host computer > is using some kind of wireless interface and is > moving around. Again > typically you may be inside a wireless LAN domain in > which even though > you are roaming around a BS connected to a wired > network, you are still > assigned the same netID prefix, that of the wireless > LAN. In another > case, you may be roaming within a city and then you > are most probably > using cellular IP or CDPD in which case even though > you may move between > cells (L2 connectivity is preserved by handoff), I > believe you still > retain one IP address. In a continuous mobility > case, if your host IP > address changes, there could be lots of problems to > handle. I think that > there are still open challenges in the case when you > have switched from > a wireless LAN domain to a WAN domain inside a city. > Can your networking > software automatically switch to the necessary > wireless technology? See > some interesting work in this regard being done at > CMU (Wirelss Andrew > Project). > If L3 and below takes care of most mobility issues, > then anything > running higher up should remain oblivious and should > run smoothly > without change. (This was the basic design principle > of TCP/IP BTW, and > the designers chose not to provide application layer > connectivity.) > However, since SIP also addresses the case of user > mobility (not > necessarily terminal mobility) there could be some > issues about > registration etc that may need some extra research > and digging. I > believe Radhika's attempt in this thread is just to > come up with such > issues, if at all they exist. > > Samir Chatterjee > Georgia State University > > farhan wrote: > > > > srivastav - > > > > a wireless network has a few more design issues as > compared to wire network. > > > > 1. minimise the air time. there is only ether for > the whole of universe. > > therefore, each node should only use as much as is > absolutely essential. > > this is another way of saying, dont use excessive > handshake and bandwidth. > > 2. minmise the erp (effective radiated power). > this is required to keep the > > handsets of Alpine mountaineers from gettng jammed > by teenagers at a Munich > > disco. > > 3. keep things private. anyone with a ham set can > snoop on you.keep your > > data payload encrypted. > > 4. co-operate. give right of way to other packets. > take your chance when > > given. behave. > > > > okay, now what happens at L3 is something like > this: > > 1. when a node comes up, it searches for a > controller node (equivalent of a > > base station in cell phones) on particular > channels (note that i dont say > > frequencies. channels can be made by > round-robining access among various > > channels on the same frequency or moving various > channels out into a band of > > individual frequencies or spatter all the signals > of a channel across the > > band in a pseudo random pattern that the channel > member nodes can correlate > > to and others can avoid). > > 2. once a controller node is found, the controller > will allocate a slot to > > the newly inducted node. This is optional, the > pure aloha implementations > > dont do this. anyway, once a node in in the > 'ring'. the power levels > > required to sustain communications with the remote > peer are continuously > > varied in a negative feedback loop with fair > amount of damping. This is done > > to conserve battery as well as RFI (radio > frequency interference) with other > > services. > > 3. when a node starts loosing signal strength with > another peer. the QoS > > monitor through protocols like RTCP on app layer > or L3 notices the fading > > (QSB) and another better path is negotiated. the > new path is selected on the > > basis of best signal to noise ratio and least cost > routing. The algorithms > > are extremely deployment critical. A space > application (like satellite > > telemetry) may have a totally different approach > from a cell phone handoff. > > 4. It is a possiblity that in such a case, > isomorphic requests may arrive > > through multiple routes. protocols like SIP or TCP > discard the identical > > packets in anycase. So should the RTP handlers. > During the process of > > handoff from one coverage area to another, it is > expected and always a good > > idea to have an overlap of coverage from two > different 'cells' until the new === message truncated === __________________________________________________ Do You Yahoo!? Get Yahoo! Mail - Free email you can access from anywhere! http://mail.yahoo.com/ _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 10 05:20:00 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA00036 for ; Tue, 10 Oct 2000 05:20:00 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8D3FF4433C; Tue, 10 Oct 2000 04:20:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mars.hss.co.in (unknown [202.54.26.197]) by lists.bell-labs.com (Postfix) with ESMTP id A5E9444338 for ; Tue, 10 Oct 2000 04:19:18 -0400 (EDT) Received: from sandesh.hss.hns.com (sandesh [139.85.242.35]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id e9A9K0C05375 for ; Tue, 10 Oct 2000 14:50:00 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256974.00323AF7 ; Tue, 10 Oct 2000 14:38:38 +0530 X-Lotus-FromDomain: HSS From: rogupta@hss.hns.com To: "'SIP@lists.bell-labs.com'" Message-ID: <65256974.003239C3.00@sandesh.hss.hns.com> Subject: RE: [SIP] Session Information Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 10 Oct 2000 14:38:35 +0530 Some protocols do infact provide for a segmentation feature which allows segmented messages to be sent, received and assembled. For example, some versions of SS7 provide this at an ISUP level (which is similar to the level at which SIP is). So I guess, if there is a real need to support messages above 64 K (now or in future) then the segmentation facility should be provided in the protocol - independent of the transport (TCP/UDP). Ofcourse this also requires the protocol to specify how to handle lost/duplicated segments and so on.... Rohit archow@hss.hns.com on 10/10/2000 03:22:52 PM To: Jonathan Rosenberg cc: "'Jo Hornsby'" , Jonathan Rosenberg , Arjun Roychowdhury/HSSBLR@HSSBLR, "'Sunitha Kumar'" , "'Burger Christian'" , "'SIP@lists.bell-labs.com'" (bcc: Rohit Gupta/HSS) Subject: RE: [SIP] Session Information Yes, Im not keen on having to mandate a protocol just for some size message. Then, we would be saying that 'for this type of message, SIP is transport dependant' . And if we must make it transport independant, lot of dirty application level breakup and co-relation of UDP would be needed - does not seem to be worth it. Also, isnt 64K size enough to put SIP into a 'bulk transporter' something which its not supposed to be ? imho, the 64k limit is really enough (hoping that this does not go down as the infamous '640K memory is all that a computer needs' quote way) . Regds Arjun -- Arjun Roychowdhury @ Hughes Software Systems Jonathan Rosenberg on 10/10/2000 01:51:53 PM To: "'Jo Hornsby'" , Jonathan Rosenberg , archow, "'Sunitha Kumar'" cc: "'Burger Christian'" , "'SIP@lists.bell-labs.com'" Subject: RE: [SIP] Session Information Hmm. TCP itself would be able to handle SIP messages above 64k, yes. It would just send them in multiple IP packets. The problem is, if we have a scenario of TCP->UDP->TCP through proxies, that UDP hop is not going to work. We could mandate the usage of TCP for sending messages over a certain size. I'm not that fond of this approach, though. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com > -----Original Message----- > From: Jo Hornsby [mailto:jhornsby@ubiquity.net] > Sent: Tuesday, October 10, 2000 4:09 AM > To: Jonathan Rosenberg; archow@hss.hns.com; 'Sunitha Kumar' > Cc: 'Burger Christian'; SIP@lists.bell-labs.com > Subject: RE: [SIP] Session Information > > > > > Afaik, there is no MUST limit (maybe except the max size > > > allocated to a n/w read kernel buffer - usually 64k ? ) > > > > Maximum IP packed size is 64K, so this represents the absolute upper > > bound on a SIP message. > > How about if I have TCP connection between two UAs, for example? > I agree in the general case one cannot know whether UDP (or other > unreliable transport) will be used anywhere along the signalling > path, but should this rule out messages > 64K? > > Cheers, > > > - Jo. > > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 10 06:54:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA00939 for ; Tue, 10 Oct 2000 06:54:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4900C4433C; Tue, 10 Oct 2000 05:54:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mars.hss.co.in (unknown [202.54.26.197]) by lists.bell-labs.com (Postfix) with ESMTP id 87D7A44338 for ; Tue, 10 Oct 2000 05:53:34 -0400 (EDT) Received: from sampark.hss.hns.com (sampark [139.85.229.22]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id e9AAqxC07676; Tue, 10 Oct 2000 16:23:00 +0530 (IST) Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 65256974.003C18FE ; Tue, 10 Oct 2000 16:26:25 +0530 X-Lotus-FromDomain: HSSBLR From: archow@hss.hns.com To: Jonathan Rosenberg Cc: "'Eric Tremblay'" , "'sip@lists.bell-labs.com'" Message-ID: <65256974.003C1838.00@sampark.hss.hns.com> Subject: RE: [SIP] Registrars and Date Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 10 Oct 2000 16:26:23 +0530 I prefer option 1. Since the embedded device sending it in this case has no concept of absolute time, it sends a relative time to the server, server replies back in relative time. If an endpoint sends expiry in a format, I feel the server should respect that format in its response (thouh not mandatory, this makes interpretation simpler for the person who sent it) solution 2 does not seem very natural to me - that is, if I say REGISTER with expiry='13 Dec, 2000', if a server returns back the calcuated relative time starting today in say seconds, its correct but some how not natural. Regds Arjun -- Arjun Roychowdhury @ Hughes Software Systems Jonathan Rosenberg on 10/10/2000 01:43:47 PM To: "'Eric Tremblay'" , "'sip@lists.bell-labs.com'" cc: Subject: RE: [SIP] Registrars and Date Good catch. Wouldn't life be easier if every device had a GPS receiver with completely syncrhonized time.... oh well. ANyway, there are a few possible solutions here: 1. always send a response with a delta-time if the request had an expires with a delta-time 2. always use relative times in register responses 3. always send Date in the 200 OK response to INVITE The third solution is what is proposed by Eric. 2 and 3 assume that registrars have access to the date. I thinks its a reasonable assumption. The easiest solution for all is probably 2, as it eliminates another option. But, I suspect that there are already implementations that always send absolute times. Comments? -Jonathan R. > -----Original Message----- > From: Eric Tremblay [mailto:etremblay@mediatrix.com] > Sent: Wednesday, September 27, 2000 11:14 AM > To: sip@lists.bell-labs.com > Subject: [SIP] Registrars and Date > > > > I have a very simple question/request: > > Would it be possible to make the Date header mandatory in Registrar > responses? This would be required if the registrar sends its > expires time > in SIP-date format. > > The reason for this are the following: > > 1- Some embedded devices don't keep track of the time at all. > 2- Other that do might be connecting to a NTP/SNTP server to > acquire the > notion of time (probably at bootup). What if the server is down? The > device has no knowledge of the time. This sould not prevent > the device from > registering. If the date header is not included, the device > cannot know for > how long the registration is valid, until the time server > comes back up. > > Regards, > > EricT > > ___________________________________________ > Eric Tremblay | Mediatrix Telecom Inc. > Technical Leader | www.mediatrix.com > > etremblay@mediatrix.com > tel: +1-819-829-8749 x238 > fax: +1-819-829-5100 > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 10 07:25:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA01400 for ; Tue, 10 Oct 2000 07:25:02 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id AA2214433C; Tue, 10 Oct 2000 06:25:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from esebh01nok.ntc.nokia.com (esebh01nok.ntc.nokia.com [131.228.118.150]) by lists.bell-labs.com (Postfix) with ESMTP id E8EFE4433C for ; Tue, 10 Oct 2000 01:59:09 -0400 (EDT) Received: by esebh01nok with Internet Mail Service (5.5.2652.78) id <4SGCVHJF>; Tue, 10 Oct 2000 09:58:53 +0300 Message-ID: <25B79E9476BAD211811B0008C7894CDC04024AF6@treis04nok> From: petri.koskelainen@nokia.com To: sip@lists.bell-labs.com Subject: [SIP] Session Information MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 10 Oct 2000 09:58:50 +0300 >> sk> The maximum size of the SIP message , including the >> content data MUST >> be within >> sk> the bounds of 1500 bytes, inorder to prevent >> fragmentation of packets. >> Please >> sk> refer Section 3, of the August 6, SIP draft. >> >> >> No, that is not true, The draft mentions that it as a SHOULD >> and I think >> that is hardly >> true now. Even 'typical' SIP messages cross well over 2000 bytes, >> especially with all these >> new extensions chipping into the message. > >Correct. In fact, I think this 1500 limit needs to be qualified or changed. > >> >> Afaik, there is no MUST limit (maybe except the max size >> allocated to a n/w >> read kernel buffer - usually 64k ? ) > >Maximum IP packed size is 64K, so this represents the absolute upper bound >on a SIP message. True for UDP, but in SIP over TCP there isn't 64k limitation. This max size definition should be dropped from the spec (or kept as a SHOULD), since there are many situations in which TCP can be used end-to-end and the SIP message size may exceed 64k (or any other fixed limit). Or course, this is less friendly approach and may cause problems if used in some environments. Anyway, this should not be forbidden by the spec. -- Petri _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 10 07:42:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA01764 for ; Tue, 10 Oct 2000 07:42:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D19D144399; Tue, 10 Oct 2000 06:42:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 6200B44399 for ; Tue, 10 Oct 2000 06:41:47 -0400 (EDT) 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 HAA02098; Tue, 10 Oct 2000 07:41:41 -0400 (EDT) Message-ID: <39E30075.256D48F3@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: "'SIP@lists.bell-labs.com'" Subject: Re: [SIP] Session Information References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 10 Oct 2000 07:41:41 -0400 Content-Transfer-Encoding: 7bit Added sentence: than the path maximum transmission unit (MTU) if the MTU is known, or 1500 bytes if the MTU is unknown. \begin{changebar} However, implementations {\MUST} be able to handle messages up to the maximum UDP packet size. \end{changebar} Other wording fix suggestions appreciated. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 10 07:58:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA02069 for ; Tue, 10 Oct 2000 07:58:05 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C3D8144399; Tue, 10 Oct 2000 06:57:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 6A2CA4433C for ; Tue, 10 Oct 2000 06:56:06 -0400 (EDT) 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 HAA02770; Tue, 10 Oct 2000 07:55:53 -0400 (EDT) Message-ID: <39E303C9.4D4ADD3F@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: "'Jo Hornsby'" , "'archow@hss.hns.com'" , "'Sunitha Kumar'" , "'Burger Christian'" , "'SIP@lists.bell-labs.com'" Subject: Re: [SIP] Session Information References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 10 Oct 2000 07:55:53 -0400 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > Hmm. > > TCP itself would be able to handle SIP messages above 64k, yes. It would > just send them in multiple IP packets. > > The problem is, if we have a scenario of TCP->UDP->TCP through proxies, that > UDP hop is not going to work. > > We could mandate the usage of TCP for sending messages over a certain size. > I'm not that fond of this approach, though. That is the approach used by DNS, for example. However, redirects only work if the end system supports TCP. Most of the end systems that only support UDP are unlikely to ever send such large messages, so in practice this is not likely to be a problem. The basic issue is how to find out whether the recipient can handle large messages and, if necessary, can switch to TCP. If web pages are included, the "nice" thing to do would be to do an OPTIONS and then decide whether the other side can accept text/html. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 10 08:30:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA02782 for ; Tue, 10 Oct 2000 08:30:02 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 28BF844391; Tue, 10 Oct 2000 07:30:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from web1401.mail.yahoo.com (web1401.mail.yahoo.com [128.11.23.165]) by lists.bell-labs.com (Postfix) with SMTP id C21814433C for ; Tue, 10 Oct 2000 07:29:29 -0400 (EDT) Received: (qmail 5199 invoked by uid 60001); 10 Oct 2000 12:29:26 -0000 Message-ID: <20001010122926.5198.qmail@web1401.mail.yahoo.com> Received: from [206.82.141.26] by web1401.mail.yahoo.com; Tue, 10 Oct 2000 05:29:26 PDT From: zeeshan razzaque To: sip@lists.bell-labs.com Cc: jdrosen@dynamicsoft.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [SIP] Gateway Question Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 10 Oct 2000 05:29:26 -0700 (PDT) Hi, Well I continue from where I left. I asked how the Gateways register themselves and I was told to use TRIP instead of REGISTER. What is the current status of TRIP. Who sponsors it and is it widely enough used? What is the method 'in vogue' for SIP Gateway Registration? Secondly, if my Gateway has a concurrent capacity of say a 100 connections, does it register 100 different UAs for that? Or is there any other SIP support for it? Now the default port for SIP listener is 5060. If the gateway spawns a 100 or more(or less for that matter) UAs, when INVITES arrive at the Gateway, is the gateway supposed to send 200 OK and put the UA SIP URL in the CONTACT header or does it send a 300 REDIRECT response. In other words should it act as a big brother or the Redirect Server. Is it mandated by SIP in nay way or is it an implementation detail not handled by SIP? Cheers, Zeeshan. __________________________________________________ Do You Yahoo!? Get Yahoo! Mail - Free email you can access from anywhere! http://mail.yahoo.com/ _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 10 08:59:00 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA03165 for ; Tue, 10 Oct 2000 08:59:00 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 27E854433C; Tue, 10 Oct 2000 07:59:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mars.hss.co.in (unknown [202.54.26.197]) by lists.bell-labs.com (Postfix) with ESMTP id BA91B44338 for ; Tue, 10 Oct 2000 07:58:45 -0400 (EDT) Received: from sampark.hss.hns.com (sampark [139.85.229.22]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id e9ACwKC10938; Tue, 10 Oct 2000 18:28:22 +0530 (IST) Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 65256974.003CB370 ; Tue, 10 Oct 2000 16:33:00 +0530 X-Lotus-FromDomain: HSSBLR From: archow@hss.hns.com To: archow@hss.hns.com Cc: Jonathan Rosenberg , "'Eric Tremblay'" , "'sip@lists.bell-labs.com'" Message-ID: <65256974.003CB212.00@sampark.hss.hns.com> Subject: RE: [SIP] Registrars and Date Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 10 Oct 2000 16:32:56 +0530 arc> solution 2 does not seem very natural to me - that is, if I say REGISTER arc> with expiry='13 Dec, 2000', if a server arc> returns back the calcuated relative time starting today in say seconds, its arc> correct but some how not natural. On second thought , that depends. If 13th Dec is months away and the server only supports 1 hr, it may be fine if it sent back 1 hr in delta time. What I mean is that unless the server has to modify the expiry time, I see no reason why it should change the unit in its response, if the sender himself had sent in SIP-DATE format. archow@hss.hns.com on 10/10/2000 04:26:23 PM To: Jonathan Rosenberg cc: "'Eric Tremblay'" , "'sip@lists.bell-labs.com'" Subject: RE: [SIP] Registrars and Date I prefer option 1. Since the embedded device sending it in this case has no concept of absolute time, it sends a relative time to the server, server replies back in relative time. If an endpoint sends expiry in a format, I feel the server should respect that format in its response (thouh not mandatory, this makes interpretation simpler for the person who sent it) solution 2 does not seem very natural to me - that is, if I say REGISTER with expiry='13 Dec, 2000', if a server returns back the calcuated relative time starting today in say seconds, its correct but some how not natural. Regds Arjun -- Arjun Roychowdhury @ Hughes Software Systems Jonathan Rosenberg on 10/10/2000 01:43:47 PM To: "'Eric Tremblay'" , "'sip@lists.bell-labs.com'" cc: Subject: RE: [SIP] Registrars and Date Good catch. Wouldn't life be easier if every device had a GPS receiver with completely syncrhonized time.... oh well. ANyway, there are a few possible solutions here: 1. always send a response with a delta-time if the request had an expires with a delta-time 2. always use relative times in register responses 3. always send Date in the 200 OK response to INVITE The third solution is what is proposed by Eric. 2 and 3 assume that registrars have access to the date. I thinks its a reasonable assumption. The easiest solution for all is probably 2, as it eliminates another option. But, I suspect that there are already implementations that always send absolute times. Comments? -Jonathan R. > -----Original Message----- > From: Eric Tremblay [mailto:etremblay@mediatrix.com] > Sent: Wednesday, September 27, 2000 11:14 AM > To: sip@lists.bell-labs.com > Subject: [SIP] Registrars and Date > > > > I have a very simple question/request: > > Would it be possible to make the Date header mandatory in Registrar > responses? This would be required if the registrar sends its > expires time > in SIP-date format. > > The reason for this are the following: > > 1- Some embedded devices don't keep track of the time at all. > 2- Other that do might be connecting to a NTP/SNTP server to > acquire the > notion of time (probably at bootup). What if the server is down? The > device has no knowledge of the time. This sould not prevent > the device from > registering. If the date header is not included, the device > cannot know for > how long the registration is valid, until the time server > comes back up. > > Regards, > > EricT > > ___________________________________________ > Eric Tremblay | Mediatrix Telecom Inc. > Technical Leader | www.mediatrix.com > > etremblay@mediatrix.com > tel: +1-819-829-8749 x238 > fax: +1-819-829-5100 > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 10 09:20:59 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA03528 for ; Tue, 10 Oct 2000 09:20:59 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 08DC34433C; Tue, 10 Oct 2000 08:21:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 8019844338 for ; Tue, 10 Oct 2000 08:20:15 -0400 (EDT) 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 JAA06983; Tue, 10 Oct 2000 09:19:53 -0400 (EDT) Message-ID: <39E3177A.7504A5EC@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: "'Eric Tremblay'" , "'sip@lists.bell-labs.com'" Subject: Re: [SIP] Registrars and Date References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 10 Oct 2000 09:19:54 -0400 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > Good catch. > > Wouldn't life be easier if every device had a GPS receiver with completely > syncrhonized time.... oh well. > > ANyway, there are a few possible solutions here: > > 1. always send a response with a delta-time if the request had an expires > with a delta-time > 2. always use relative times in register responses > 3. always send Date in the 200 OK response to INVITE > > The third solution is what is proposed by Eric. 2 and 3 assume that > registrars have access to the date. I thinks its a reasonable assumption. > > The easiest solution for all is probably 2, as it eliminates another option. > But, I suspect that there are already implementations that always send > absolute times. I would suggest that servers send Date headers. Everyone does anyways (as far as I can tell), it allows really simple end systems that use the registrar for a rough notion of time, without reliance on another service, and the incremental pain for registrars is zero. We really don't want to add to the two big blunders in electrical engineering, blinking 12:00 on VCRs and ISDN phones that have to have their time set manually... Restricting Expires headers just adds yet another error condition. If the end system truly has no notion of time and gets an absolute expiration time, it just keeps to the one hour default. If the registrar doesn't like this, it just gets what it deserves by saving five lines of program code. > > Comments? > > -Jonathan R. > > > -----Original Message----- > > From: Eric Tremblay [mailto:etremblay@mediatrix.com] > > Sent: Wednesday, September 27, 2000 11:14 AM > > To: sip@lists.bell-labs.com > > Subject: [SIP] Registrars and Date > > > > > > > > I have a very simple question/request: > > > > Would it be possible to make the Date header mandatory in Registrar > > responses? This would be required if the registrar sends its > > expires time > > in SIP-date format. > > > > The reason for this are the following: > > > > 1- Some embedded devices don't keep track of the time at all. > > 2- Other that do might be connecting to a NTP/SNTP server to > > acquire the > > notion of time (probably at bootup). What if the server is down? The > > device has no knowledge of the time. This sould not prevent > > the device from > > registering. If the date header is not included, the device > > cannot know for > > how long the registration is valid, until the time server > > comes back up. > > > > Regards, > > > > EricT > > > > ___________________________________________ > > Eric Tremblay | Mediatrix Telecom Inc. > > Technical Leader | www.mediatrix.com > > > > etremblay@mediatrix.com > > tel: +1-819-829-8749 x238 > > fax: +1-819-829-5100 > > > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > --- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 10 09:42:06 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA03821 for ; Tue, 10 Oct 2000 09:42:05 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id CEA4544391; Tue, 10 Oct 2000 08:42:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cybertron.div8.net (el05-24-131-150-91.ce.mediaone.net [24.131.150.91]) by lists.bell-labs.com (Postfix) with ESMTP id 148234433C for ; Tue, 10 Oct 2000 08:34:52 -0400 (EDT) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for sip@lists.bell-labs.com; Tue, 10 Oct 2000 08:34:28 -0500 (CDT) From: Billy Biggs To: Jonathan Rosenberg Cc: "'SIP Mailing List'" Subject: Re: [SIP] Mid-Call Redirects with a Route Message-ID: <20001010083428.A11132@div8.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i In-Reply-To: ; from jdrosen@dynamicsoft.com on Tue, Oct 10, 2000 at 01:58:29AM -0400 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 10 Oct 2000 08:34:28 -0500 Jonathan Rosenberg (jdrosen@dynamicsoft.com): > > If I get redirected (say a 302) on a re-INVITE or BYE request on > > an active call-leg end, and the call-leg has a Route, what do I > > do? > > This should really never happen. I don't think there is any happy > solution in this case. Is there a specific scenario you were thinking > of? Sure. Say I'm a client which always uses a Contact of its globally-visible URI, and the URI is that of a redirect server, and the calling party has a Record-Route'ing outbound proxy. I guess in that scenario I'm also assuming that redirect servers (or at least this one) will proxy ACKs. Is that true? If not, maybe this is a ridiculous case. I definitely agree that this should never happen otherwise, unless a proxy in the middle is reconfigured mid-call, and then its the proxy's fault for not keeping state. Ouch. > > Regarding (a), am I correct in assuming that with every transaction > > the Route is rebuilt completely, not just a possible update of the > > Contact address at the end? > > No, thats not correct. Since its currently only for the initial > INVITE, it would not be backwards compatible to mandate it for each > transaction. The latest bis says proxies should insert it, but UAs > shouldn't use it for a new Route (only the Contact can change after > call is setup). Seems useless, but it can help if there is a crash and > restart. Even more useless since the UA has to remember tags in the case of a restart. I guess it does help somewhat for debugging, or if someone is doing an "evil Route hack" on the initial transaction of a call-leg. But regardless, thanks for the clarification. :) -- Billy Biggs, 3Com Billy_Biggs@3com.com http://www.div8.net/billy/ bbiggs@div8.net _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 10 10:47:18 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA05250 for ; Tue, 10 Oct 2000 10:47:12 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 47D504433D; Tue, 10 Oct 2000 09:47:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id CBDB54433A for ; Tue, 10 Oct 2000 09:46:26 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id KAA12142; Tue, 10 Oct 2000 10:48:27 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Tue, 10 Oct 2000 10:42:45 -0400 Message-ID: From: Jonathan Rosenberg To: "'Henning Schulzrinne'" , Jonathan Rosenberg Cc: "'Eric Tremblay'" , "'sip@lists.bell-labs.com'" Subject: RE: [SIP] Registrars and Date MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 10 Oct 2000 10:42:44 -0400 > -----Original Message----- > From: Henning Schulzrinne [mailto:schulzrinne@cs.columbia.edu] > Sent: Tuesday, October 10, 2000 9:20 AM > To: Jonathan Rosenberg > Cc: 'Eric Tremblay'; 'sip@lists.bell-labs.com' > Subject: Re: [SIP] Registrars and Date > > > Jonathan Rosenberg wrote: > > > > Good catch. > > > > Wouldn't life be easier if every device had a GPS receiver > with completely > > syncrhonized time.... oh well. > > > > ANyway, there are a few possible solutions here: > > > > 1. always send a response with a delta-time if the request > had an expires > > with a delta-time > > 2. always use relative times in register responses > > 3. always send Date in the 200 OK response to INVITE > > > > The third solution is what is proposed by Eric. 2 and 3 assume that > > registrars have access to the date. I thinks its a > reasonable assumption. > > > > The easiest solution for all is probably 2, as it > eliminates another option. > > But, I suspect that there are already implementations that > always send > > absolute times. > > I would suggest that servers send Date headers. Everyone does anyways > (as far as I can tell), it allows really simple end systems > that use the > registrar for a rough notion of time, without reliance on another > service, and the incremental pain for registrars is zero. We really > don't want to add to the two big blunders in electrical engineering, > blinking 12:00 on VCRs and ISDN phones that have to have > their time set > manually... > > Restricting Expires headers just adds yet another error condition. > > If the end system truly has no notion of time and gets an absolute > expiration time, it just keeps to the one hour default. If > the registrar > doesn't like this, it just gets what it deserves by saving > five lines of > program code. Sounds reasonable. Lets go with that. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 10 10:47:31 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA05267 for ; Tue, 10 Oct 2000 10:47:31 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 15B7E443AA; Tue, 10 Oct 2000 09:47:09 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lists.bell-labs.com (Postfix) with ESMTP id 6F15D4433A for ; Tue, 10 Oct 2000 09:46:27 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id e9AEkMt15966; Tue, 10 Oct 2000 16:46:22 +0200 (MEST) Received: from lmf.ericsson.se (E005004B57CE1.lmf.ericsson.se [131.160.30.148]) by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id RAA18382; Tue, 10 Oct 2000 17:46:18 +0300 (EET DST) Message-ID: <39E32BB1.1325ADA@lmf.ericsson.se> 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: Jonathan Rosenberg Cc: "'sip'" Subject: Re: [SIP] Feedback on manyfolks References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 10 Oct 2000 17:46:09 +0300 Content-Transfer-Encoding: 7bit Hi, Certainly we are not talking about tons of messages. However, in this case I would rather let the confim be negotiated. The negotiation is rather simple. The UAC can request: 1) No COMET 2) one COMET UAC->UAS 3) one COMET UAC- > This seems reasonable to me, and needed, as Gonzalo points out. > > My only issue is whether all this stuff should be optional at all. Wouldn't > it be easier if both sides always sent COMET, period? All this negotiation > stuff is a pain. We're not talking tons of messages here. Can't we keep it > simple? > > -Jonathan R. > > --- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > > -----Original Message----- > > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > Sent: Monday, October 09, 2000 2:33 AM > > To: sip > > Subject: [SIP] Feedback on manyfolks > > > > > > Hi, > > > > Here you have a new I-D that contains feedback on the manyfolks draft. > > > > http://search.ietf.org/internet-drafts/draft-camarillo-manyfol > > ks-confirm-00.txt > > > > " > > Abstract > > > > This document describes certain functionality that is > > missing in the > > current "Integration of Resource Management and SIP" [1] (a.k.a. > > manyfolks draft). An extension to add this functionality is > > outlined. > > > > This functionality is needed in general to provide richer > > signalling > > capabilities and can be employed in several scenarios. This draft > > describes its use in third party call control applications. > > > > If this extension is accepted it is foreseen that this draft would > > be merged with [1]. > > " > > > > Best regards, > > > > Gonzalo > > -- > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > Telecom R&D Fax : +358 9 299 30 52 > > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > > Finland http://www.hut.fi/~gonzalo > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland http://www.hut.fi/~gonzalo _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 10 11:00:54 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA05530 for ; Tue, 10 Oct 2000 11:00:54 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 58C0F443B4; Tue, 10 Oct 2000 09:59:06 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id EE13A443A8 for ; Tue, 10 Oct 2000 09:58:17 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id LAA12343; Tue, 10 Oct 2000 11:00:19 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Tue, 10 Oct 2000 10:54:37 -0400 Message-ID: From: Jonathan Rosenberg To: "'rogupta@hss.hns.com'" , "'SIP@lists.bell-labs.com'" Subject: RE: [SIP] Session Information MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 10 Oct 2000 10:54:37 -0400 > -----Original Message----- > From: rogupta@hss.hns.com [mailto:rogupta@hss.hns.com] > Sent: Tuesday, October 10, 2000 5:09 AM > To: 'SIP@lists.bell-labs.com' > Subject: RE: [SIP] Session Information > > > > > > Some protocols do infact provide for a segmentation feature > which allows > segmented messages to > be sent, received and assembled. For example, some versions > of SS7 provide this > at an ISUP > level (which is similar to the level at which SIP is). So I > guess, if there is a > real need to support > messages above 64 K (now or in future) then the segmentation > facility should be > provided in the > protocol - independent of the transport (TCP/UDP). Ofcourse > this also requires > the protocol to > specify how to handle lost/duplicated segments and so on.... There is no need for such large messages. We are not seeing anything near that size today. The discussion was motivated by the need to describe any remote possible case in the spec. Furthermore, adding segmentation at the app level to SIP would completely break it right now, so there is no way we are doing that. Other fine protocols like TCP do this already for us. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 10 11:03:50 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA05605 for ; Tue, 10 Oct 2000 11:03:30 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4B385443BC; Tue, 10 Oct 2000 10:00:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lists.bell-labs.com (Postfix) with ESMTP id 7BE68443B3 for ; Tue, 10 Oct 2000 09:59:04 -0400 (EDT) Received: from esealnt409.al.sw.ericsson.se (esealnt409.al.sw.ericsson.se [153.88.251.32]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id e9AEx0Z18151 for ; Tue, 10 Oct 2000 16:59:00 +0200 (MEST) Received: FROM esealnt743.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Tue Oct 10 16:58:52 2000 +0200 Received: by esealnt743.al.sw.ericsson.se with Internet Mail Service (5.5.2651.58) id ; Tue, 10 Oct 2000 16:58:52 +0200 Message-ID: <56E7307B0850D411B1480008C75DD5EAB73D14@enlrynt303.dsn.ericsson.se> From: "Arnoud van Wijk (ELN)" To: "Sip (E-mail)" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] The definition of Multi-media Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 10 Oct 2000 16:58:42 +0200 Hello all. I am encountering more and more issues about the definition of multimedia. We at the SIP WG are actually enabling Multimedia IP (VoIP is just the beginning). Is multimedia now streaming video, audio and voice? Would an RTP stream with text be multimedia? Would a file send to your mobile device be multimedia? (downloaded movie vs streaming video). Would an instant message sent to your buddy via SIP be part of multi-media? And IRC like chat via SIP? My definition of Multimedia is real-time receiving of different media, which is audio and video and written data. No difference between streaming or download and then play. In fact everything that SIP does or initiates. :-) (but not SIP itself). If any of you has a clear definition of Multimedia and possibly also the source, I will be very grateful. I do not want this to start a long discussion thread. But to make our work easier (and improve communications with managers and vendors so that we will indeed talk about the same case). Thanks Arnoud _______________________________________________________________ ERICSSON EUROLABS NETHERLANDS BV Arnoud van Wijk ABACUS Lab Research & Development (ELN/V) Fax: +31-161 247569 _______________________________________________________________ _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 10 11:15:15 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA05865 for ; Tue, 10 Oct 2000 11:15:15 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id BF559443B7; Tue, 10 Oct 2000 10:15:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from pentagon.cisco.com (pentagon.cisco.com [161.44.199.141]) by lists.bell-labs.com (Postfix) with ESMTP id 40704443B4 for ; Tue, 10 Oct 2000 10:14:09 -0400 (EDT) Received: from cia.cisco.com (mirapoint@cia.cisco.com [161.44.199.157]) by pentagon.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA08464; Tue, 10 Oct 2000 11:14:03 -0400 (EDT) Received: from mhammer-nt.cisco.com (va-dhcp198-137.cisco.com [161.44.198.137]) by cia.cisco.com (Mirapoint) with ESMTP id ABS09858; Tue, 10 Oct 2000 11:14:01 -0400 (EDT) Message-Id: <4.3.2.7.2.20001010111038.00b37690@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: archow@hss.hns.com, Jonathan Rosenberg From: hammer michael Subject: RE: [SIP] Session Information Cc: "'Jo Hornsby'" , Jonathan Rosenberg , archow@hss.hns.com, "'Sunitha Kumar'" , "'Burger Christian'" , "'SIP@lists.bell-labs.com'" In-Reply-To: <65256974.0030C97C.00@sampark.hss.hns.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 10 Oct 2000 11:18:53 -0700 If the "signaling" message becomes that obese, then perhaps it is time to split the functionality supported by that message into smaller parts supported by multiple smaller messages (not the same as blindly segmenting). Also, if it is routing information that is causing this, then it is time to find a shorter path, that does not waste as much network bandwidth. Surely the added delay is not good. Mike At 02:22 PM 10/10/2000 +0530, archow@hss.hns.com wrote: >Yes, >Im not keen on having to mandate a protocol just for some size message. >Then, we would be saying that 'for this type of >message, SIP is transport dependant' . And if we must make it transport >independant, lot of dirty application level breakup >and co-relation of UDP would be needed - does not seem to be worth it. > >Also, isnt 64K size enough to put SIP into a 'bulk transporter' something >which its not supposed to be ? > >imho, the 64k limit is really enough (hoping that this does not go down as >the infamous '640K memory is all that a computer >needs' quote way) . > >Regds >Arjun > >-- >Arjun Roychowdhury @ Hughes Software Systems > > > > > > > >Jonathan Rosenberg on 10/10/2000 01:51:53 PM > >To: "'Jo Hornsby'" , Jonathan Rosenberg > , archow, "'Sunitha Kumar'" > >cc: "'Burger Christian'" , > "'SIP@lists.bell-labs.com'" > >Subject: RE: [SIP] Session Information > > > > >Hmm. > >TCP itself would be able to handle SIP messages above 64k, yes. It would >just send them in multiple IP packets. > >The problem is, if we have a scenario of TCP->UDP->TCP through proxies, >that >UDP hop is not going to work. > >We could mandate the usage of TCP for sending messages over a certain size. >I'm not that fond of this approach, though. > >-Jonathan R. > >--- >Jonathan D. Rosenberg 72 Eagle Rock Ave. >Chief Scientist First Floor >dynamicsoft East Hanover, NJ 07936 >jdrosen@dynamicsoft.com FAX: (973) 952-5050 >http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 >http://www.dynamicsoft.com > > > -----Original Message----- > > From: Jo Hornsby [mailto:jhornsby@ubiquity.net] > > Sent: Tuesday, October 10, 2000 4:09 AM > > To: Jonathan Rosenberg; archow@hss.hns.com; 'Sunitha Kumar' > > Cc: 'Burger Christian'; SIP@lists.bell-labs.com > > Subject: RE: [SIP] Session Information > > > > > > > > Afaik, there is no MUST limit (maybe except the max size > > > > allocated to a n/w read kernel buffer - usually 64k ? ) > > > > > > Maximum IP packed size is 64K, so this represents the absolute upper > > > bound on a SIP message. > > > > How about if I have TCP connection between two UAs, for example? > > I agree in the general case one cannot know whether UDP (or other > > unreliable transport) will be used anywhere along the signalling > > path, but should this rule out messages > 64K? > > > > Cheers, > > > > > > - Jo. > > > > > >_______________________________________________ >SIP mailing list >SIP@lists.bell-labs.com >http://lists.bell-labs.com/mailman/listinfo/sip > > > > > >_______________________________________________ >SIP mailing list >SIP@lists.bell-labs.com >http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 10 11:46:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA06409 for ; Tue, 10 Oct 2000 11:46:00 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 32D054438C; Tue, 10 Oct 2000 10:46:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from thalia.fm.intel.com (thalia.fm.intel.com [132.233.247.11]) by lists.bell-labs.com (Postfix) with ESMTP id 12A3E4433D for ; Tue, 10 Oct 2000 10:45:45 -0400 (EDT) Received: from SMTP (fmsmsxvs02-1.fm.intel.com [132.233.42.202]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.31 2000/08/22 00:15:13 dmccart Exp $) with SMTP id PAA26834 for ; Tue, 10 Oct 2000 15:46:42 GMT Received: from fmsmsx29.FM.INTEL.COM ([132.233.48.29]) by 132.233.48.202 (Norton AntiVirus for Internet Email Gateways 1.0) ; Tue, 10 Oct 2000 15:45:27 0000 (GMT) Received: by fmsmsx29.fm.intel.com with Internet Mail Service (5.5.2650.21) id <4LBTD0LM>; Tue, 10 Oct 2000 08:45:26 -0700 Message-ID: From: "Agarwal, Aseem" To: "'SIP@lists.bell-labs.com'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Subject: [SIP] Question on draft-ietf-sip-srv-00.txt Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 10 Oct 2000 08:45:26 -0700 This draft requires a stateless proxy to select the same SRV record for all requests (original request + retransmissions) in a SIP transaction. IMO, this behavior should be expected from a stateful proxy as well. Is there a specific reason for mandating this behavior only for stateless proxies ? Even a stateful proxy may transmit a request retransmission to a different server, resulting in state synch requirements at all the servers with same priority in the SRV records. Comments ? Pls correct the expiry date of the draft. -aseem _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 10 11:51:12 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA06573 for ; Tue, 10 Oct 2000 11:51:05 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E32744438C; Tue, 10 Oct 2000 10:51:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 314F64433D for ; Tue, 10 Oct 2000 10:50:18 -0400 (EDT) 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 LAA16718; Tue, 10 Oct 2000 11:50:06 -0400 (EDT) Message-ID: <39E33AAE.61B2A788@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "Agarwal, Aseem" Cc: "'SIP@lists.bell-labs.com'" Subject: Re: [SIP] Question on draft-ietf-sip-srv-00.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 10 Oct 2000 11:50:06 -0400 Content-Transfer-Encoding: 7bit "Agarwal, Aseem" wrote: > > This draft requires a stateless proxy to select the same SRV record for all > requests (original request + retransmissions) in a SIP transaction. > > IMO, this behavior should be expected from a stateful proxy as well. Is > there > a specific reason for mandating this behavior only for stateless proxies ? > Even a stateful proxy may transmit a request retransmission to a different > server, resulting in state synch requirements at all the servers with same > priority in the SRV records. Comments ? Yes, this is general behavior. Clarified. > > Pls correct the expiry date of the draft. Done. Thanks. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 10 12:20:08 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA07309 for ; Tue, 10 Oct 2000 12:20:03 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2570F4433D; Tue, 10 Oct 2000 11:20:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from drago1.ubiquity.net (unknown [194.202.146.92]) by lists.bell-labs.com (Postfix) with SMTP id 8374A4433A for ; Tue, 10 Oct 2000 11:19:06 -0400 (EDT) Received: from gecko.ubiquity.co.uk by drago1.ubiquity.net via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 10 Oct 2000 16:19:31 UT Received: from jundery.ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id RAA02812; Tue, 10 Oct 2000 17:17:26 +0100 (BST) Received: from localhost (jundery@localhost) by jundery.ubiquity.net (8.9.3/8.9.3) with ESMTP id RAA03809; Tue, 10 Oct 2000 17:17:26 GMT X-Authentication-Warning: jundery.ubiquity.net: jundery owned process doing -bs From: James Undery To: Henning Schulzrinne Cc: "Agarwal, Aseem" , "'SIP@lists.bell-labs.com'" Subject: Re: [SIP] Question on draft-ietf-sip-srv-00.txt In-Reply-To: <39E33AAE.61B2A788@cs.columbia.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 10 Oct 2000 17:17:26 +0000 (GMT) On Tue, 10 Oct 2000, Henning Schulzrinne wrote: > "Agarwal, Aseem" wrote: > > > > This draft requires a stateless proxy to select the same SRV record for all > > requests (original request + retransmissions) in a SIP transaction. > > > > IMO, this behavior should be expected from a stateful proxy as well. Is > > there > > a specific reason for mandating this behavior only for stateless proxies ? > > Even a stateful proxy may transmit a request retransmission to a different > > server, resulting in state synch requirements at all the servers with same > > priority in the SRV records. Comments ? > > Yes, this is general behavior. Clarified. I've just thought of something that might be worth mentioning in the draft. Stateless proxies will need to ensure the SRV RRs are ordered identically within the priority classes each time they do a SRV lookup as you can't be sure the RRs will be in the same order in two consecutive lookups. (e.g. try two DNS lookups on www.microsoft.com and you will see the answer RRs ordering change). James Undery _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 10 13:37:07 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA08874 for ; Tue, 10 Oct 2000 13:37:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4F8F54433C; Tue, 10 Oct 2000 12:37:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from longmail.lboard.com (mail.lboard.com [204.17.219.203]) by lists.bell-labs.com (Postfix) with ESMTP id 127B84433A for ; Tue, 10 Oct 2000 12:33:12 -0400 (EDT) Received: by longmail.lboard.com with Internet Mail Service (5.5.2650.21) id <4LCGMQDD>; Tue, 10 Oct 2000 10:36:13 -0700 Message-ID: From: Ragunath Devarasu To: "'sip@lists.bell-labs.com'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] PGP in SIP. Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 10 Oct 2000 10:36:12 -0700 Hi, Is there any sip Phones/Porxy Server that support PGP authentication schemes?. I am just wondering, how the public key of SIP Phones/Proxy Server will be made available to each other. Sorry if it is Off-topic. Thanks ragunath. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 10 13:48:08 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA09151 for ; Tue, 10 Oct 2000 13:48:07 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 299E24433C; Tue, 10 Oct 2000 12:48:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id DE99C4433A for ; Tue, 10 Oct 2000 12:47:08 -0400 (EDT) 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 NAA25146; Tue, 10 Oct 2000 13:46:55 -0400 (EDT) Message-ID: <39E3560F.29506605@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Ragunath Devarasu Cc: "'sip@lists.bell-labs.com'" Subject: Re: [SIP] PGP in SIP. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 10 Oct 2000 13:46:55 -0400 Content-Transfer-Encoding: 7bit Ragunath Devarasu wrote: > > Hi, > > Is there any sip Phones/Porxy Server that support PGP authentication > schemes?. I am just wondering, how the public key of SIP Phones/Proxy Server > will > be made available to each other. The Columbia SIP server and client support PGP, although we rarely use it... I would imagine that the keys of users would be made available in the same manner as for email, e.g., via public key rings. Given the lack of widespread use of PGP email, this type of infrastructure seems hard to set up. (Or people don't much care about securing their email.) > > Sorry if it is Off-topic. > > Thanks > ragunath. > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 10 14:15:37 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA09565 for ; Tue, 10 Oct 2000 14:15:34 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 28DAF4433A; Tue, 10 Oct 2000 13:15:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ganymede.or.intel.com (ganymede.or.intel.com [134.134.248.3]) by lists.bell-labs.com (Postfix) with ESMTP id 58F9944338 for ; Tue, 10 Oct 2000 13:14:43 -0400 (EDT) Received: from SMTP (orsmsxvs02-1.jf.intel.com [192.168.65.201]) by ganymede.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.31 2000/08/22 00:15:13 dmccart Exp $) with SMTP id LAA25168 for ; Tue, 10 Oct 2000 11:14:38 -0700 (PDT) Received: from orsmsx29.jf.intel.com ([192.168.70.29]) by 192.168.70.201 (Norton AntiVirus for Internet Email Gateways 1.0) ; Tue, 10 Oct 2000 18:14:37 0000 (GMT) Received: by orsmsx29.jf.intel.com with Internet Mail Service (5.5.2650.21) id <4LQD7AZN>; Tue, 10 Oct 2000 11:14:36 -0700 Message-ID: From: "Schmidlin, David" To: "'sip@lists.bell-labs.com'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] Sip Proxy/Clients for download. Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 10 Oct 2000 10:41:30 -0700 All, Are there any SIP Proxy's and/or clients that are available download on a trial basis that can be used to test our product? Thanks, David _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 10 14:23:13 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA09756 for ; Tue, 10 Oct 2000 14:23:12 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id BBFDB4433A; Tue, 10 Oct 2000 13:23:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cisco.com (mayo.cisco.com [161.44.3.207]) by lists.bell-labs.com (Postfix) with ESMTP id 9A90A44338 for ; Tue, 10 Oct 2000 13:22:42 -0400 (EDT) Received: from cisco.com (mayo.cisco.com [161.44.3.207]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id OAA13990; Tue, 10 Oct 2000 14:21:16 -0400 (EDT) Message-ID: <39E35E1B.E5CC517F@cisco.com> From: Nilesh Trivedi Organization: Packet Development Unit X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "Schmidlin, David" Cc: "'sip@lists.bell-labs.com'" Subject: Re: [SIP] Sip Proxy/Clients for download. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 10 Oct 2000 14:21:16 -0400 Content-Transfer-Encoding: 7bit Hi David, You might want to look at; http://www.cs.columbia.edu/~hgs/sip/implementations.html Have a good day!! Cheers, Nilesh. "Schmidlin, David" wrote: > All, > > Are there any SIP Proxy's and/or clients that are available download on a > trial basis that > can be used to test our product? > > Thanks, > David > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 10 14:58:09 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA10731 for ; Tue, 10 Oct 2000 14:58:04 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4E71E4433A; Tue, 10 Oct 2000 13:58:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 8B37C44338 for ; Tue, 10 Oct 2000 13:57:42 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id OAA15374; Tue, 10 Oct 2000 14:59:33 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Tue, 10 Oct 2000 14:53:50 -0400 Message-ID: From: Jonathan Rosenberg To: "'Schmidlin, David'" , "'sip@lists.bell-labs.com'" Subject: RE: [SIP] Sip Proxy/Clients for download. MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 10 Oct 2000 14:53:49 -0400 dynamicsoft's user agent product is available for download from our web site, http://www.dynamicsoft.com. You can find a more complete listing at the sip page, http://www.cs.columbia.edu/~hgs/sip. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com > -----Original Message----- > From: Schmidlin, David [mailto:david.schmidlin@intel.com] > Sent: Tuesday, October 10, 2000 1:41 PM > To: 'sip@lists.bell-labs.com' > Subject: [SIP] Sip Proxy/Clients for download. > > > All, > > Are there any SIP Proxy's and/or clients that are available > download on a > trial basis that > can be used to test our product? > > Thanks, > David > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 10 17:45:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA14001 for ; Tue, 10 Oct 2000 17:45:00 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5B57744339; Tue, 10 Oct 2000 16:45:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from smtprch2.nortel.com (smtprch2.nortelnetworks.com [192.135.215.15]) by lists.bell-labs.com (Postfix) with ESMTP id F149344338 for ; Tue, 10 Oct 2000 16:44:49 -0400 (EDT) Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprch2.nortel.com; Tue, 10 Oct 2000 16:39:22 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2652.35) id <44ZNN4S1>; Tue, 10 Oct 2000 16:43:18 -0500 Message-ID: <63E0DAD7784FD21188310000F80824B3029C99FC@zmpkdx02.us.nortel.com> From: "Francois Audet" To: "'sip'" Subject: RE: [SIP] Feedback on manyfolks MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C03303.178A6C40" X-Orig: Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 10 Oct 2000 16:43:13 -0500 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_01C03303.178A6C40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable These are more comments on the manyfolk draft itself. When a user is alerted in band, should a second 183 response be sent when the alerting actually start after the COMET? The 4th paragraph in = 7.1=20 of manyfolks says that it does send a second 183 in that case. Also, the 3rd paragraph in 7.1 says that "the UAC does not generate = local ringback until the mandatory preconditions are met". Shouldn't it be the 180 response that would trigger local alerting at the UAC instead = of completion of resource reservation (that's what the 4th paragraph = says)?=20 Section 7.2 has similar wording. =20 ---- Fran=E7ois AUDET, Nortel Networks mailto:audet@nortelnetworks.com, tel:+1 408 495 3756 > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Monday, October 09, 2000 11:32 PM > To: 'Gonzalo Camarillo'; 'sip' > Subject: RE: [SIP] Feedback on manyfolks >=20 >=20 > This seems reasonable to me, and needed, as Gonzalo points out. >=20 > My only issue is whether all this stuff should be optional at=20 > all. Wouldn't > it be easier if both sides always sent COMET, period? All=20 > this negotiation > stuff is a pain. We're not talking tons of messages here.=20 > Can't we keep it > simple? >=20 > -Jonathan R. >=20 > --- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > http://www.dynamicsoft.com >=20 > > -----Original Message----- > > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > Sent: Monday, October 09, 2000 2:33 AM > > To: sip > > Subject: [SIP] Feedback on manyfolks > >=20 > >=20 > > Hi, > >=20 > > Here you have a new I-D that contains feedback on the=20 > manyfolks draft. > >=20 > > http://search.ietf.org/internet-drafts/draft-camarillo-manyfol > > ks-confirm-00.txt > >=20 > > " > > Abstract > >=20 > > This document describes certain functionality that is=20 > > missing in the > > current "Integration of Resource Management and SIP" [1] (a.k.a. > > manyfolks draft). An extension to add this functionality is > > outlined. > >=20 > > This functionality is needed in general to provide richer=20 > > signalling > > capabilities and can be employed in several scenarios. This = draft > > describes its use in third party call control applications. > >=20 > > If this extension is accepted it is foreseen that this=20 > draft would > > be merged with [1]. > > " > >=20 > > Best regards, > >=20 > > Gonzalo > > --=20 > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > Telecom R&D Fax : +358 9 299 30 52 > > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > > Finland http://www.hut.fi/~gonzalo > >=20 > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > >=20 >=20 > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip >=20 ------_=_NextPart_001_01C03303.178A6C40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [SIP] Feedback on manyfolks

These are more comments on the manyfolk draft = itself.

When a user is alerted in band, should a second 183 = response be sent
when the alerting actually start after the COMET? = The 4th paragraph in 7.1
of manyfolks says that it does send a second 183 in = that case.

Also, the 3rd paragraph in 7.1 says that "the = UAC does not generate local
ringback until the mandatory preconditions are = met". Shouldn't it be
the 180 response that would trigger local alerting = at the UAC instead of
completion of resource reservation (that's what the = 4th paragraph says)?
Section 7.2 has similar wording. 

----
Fran=E7ois AUDET, Nortel Networks
mailto:audet@nortelnetworks.com= , tel:+1 408 495 3756


> -----Original Message-----
> From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> Sent: Monday, October 09, 2000 11:32 PM
> To: 'Gonzalo Camarillo'; 'sip'
> Subject: RE: [SIP] Feedback on manyfolks
>
>
> This seems reasonable to me, and needed, as = Gonzalo points out.
>
> My only issue is whether all this stuff should = be optional at
> all. Wouldn't
> it be easier if both sides always sent COMET, = period? All
> this negotiation
> stuff is a pain. We're not talking tons of = messages here.
> Can't we keep it
> simple?
>
> -Jonathan R.
>
> ---
> Jonathan D. = Rosenberg          &nb= sp;            = 72 Eagle Rock Ave.
> Chief = Scientist          &nb= sp;           &nb= sp;      First Floor
> = dynamicsoft          &= nbsp;           &= nbsp;          East = Hanover, NJ 07936
> = jdrosen@dynamicsoft.com        &= nbsp;            = FAX:   (973) 952-5050
> http://www.cs.columbia.edu/~jdrosen  &nb= sp;      PHONE: (973) 952-5000
> http://www.dynamicsoft.com
>
> > -----Original Message-----
> > From: Gonzalo Camarillo [mailto:Gonzalo.Camaril= lo@lmf.ericsson.se]
> > Sent: Monday, October 09, 2000 2:33 = AM
> > To: sip
> > Subject: [SIP] Feedback on = manyfolks
> >
> >
> > Hi,
> >
> > Here you have a new I-D that contains = feedback on the
> manyfolks draft.
> >
> > http://search.ietf.org/internet-drafts/draft-camarillo= -manyfol
> > ks-confirm-00.txt
> >
> > "
> > Abstract
> >
> >    This document describes = certain functionality that is
> > missing in the
> >    current = "Integration of Resource Management and SIP" [1] = (a.k.a.
> >    manyfolks draft). An = extension to add this functionality is
> >    outlined.
> >
> >    This functionality is = needed in general to provide richer
> > signalling
> >    capabilities and can be = employed in several scenarios. This draft
> >    describes its use in = third party call control applications.
> >
> >    If this extension is = accepted it is foreseen that this
> draft would
> >    be merged with = [1].
> > "
> >
> > Best regards,
> >
> > Gonzalo
> > --
> > Gonzalo = Camarillo         Phone :  = +358  9 299 33 71
> > Oy L M Ericsson = Ab        Mobile:  +358 40 702 = 35 35
> > Telecom = R&D           = ;    Fax   :  +358  9 299 30 = 52
> > FIN-02420 = Jorvas          Email = :  Gonzalo.Camarillo@ericsson.com
> > = Finland           = ;        http://www.hut.fi/~gonzalo
> >
> > = _______________________________________________
> > SIP mailing list
> > SIP@lists.bell-labs.com
> > http://lists.bell-labs.com/mailman/listinfo/sip
> >
>
> = _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip
>

------_=_NextPart_001_01C03303.178A6C40-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 10 21:40:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA17512 for ; Tue, 10 Oct 2000 21:40:00 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C1A8A4433A; Tue, 10 Oct 2000 20:40:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from rwcxch02.clarent.com (unknown [208.205.112.25]) by lists.bell-labs.com (Postfix) with ESMTP id B2BAD44339 for ; Tue, 10 Oct 2000 20:39:32 -0400 (EDT) Received: by rwcxch02.clarent.com with Internet Mail Service (5.5.2650.21) id <43RDLVYN>; Tue, 10 Oct 2000 18:37:36 -0700 Message-ID: <6374EFC78443D41197DD00508B5C35DD0148FF4E@rwcxch02.clarent.com> From: Jean-Francois Mule To: SIP ietf wg Subject: [SIP] re-INVITE with SDP modifications of media description MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 10 Oct 2000 18:37:29 -0700 Context: We consider the case of UDP transport only. A SIP session is active between UA1 and UA2. A re-INVITE is sent with an updated SDP body from UA1 to UA2, in particular, a new media description is given (only 1 m= line appears in SDP body, for e.g., with a new RTP port). If the receiving UA, UA2, can honor the new request, it sends a 200 OK back to UA1. In that case, UA1 sends ACK and starts listening for media on the new UDP port. It also releases *any* previously allocated port for that call / connection (same cseq, call-id, to:, from:). Upon receipt of ACK from UA1, UA2 starts sending media to the new RTP port. => Agreed? Comments? If the intent of UA1 is to add one additional media connection, it MUST repeat the previous m= lines. => Agreed? Comments? Thank you in advance, Jean-Francois Mule. Clarent _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 11 00:07:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA19975 for ; Wed, 11 Oct 2000 00:07:04 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2B08B4433A; Tue, 10 Oct 2000 23:07:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from hotmail.com (f304.law7.hotmail.com [216.33.236.182]) by lists.bell-labs.com (Postfix) with ESMTP id B9A9144338 for ; Tue, 10 Oct 2000 23:06:58 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 10 Oct 2000 21:06:54 -0700 Received: from 164.164.6.34 by lw7fd.law7.hotmail.msn.com with HTTP; Wed, 11 Oct 2000 04:06:54 GMT X-Originating-IP: [164.164.6.34] From: "rahul pande" To: sip@lists.bell-labs.com Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 11 Oct 2000 04:06:54.0730 (UTC) FILETIME=[B102A6A0:01C03338] Subject: [SIP] a question on "pgp"... Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 11 Oct 2000 09:36:54 IST hello Sir, In the encryption and other headers the grammar allows only the well known PGP algorithm, shouldn't it be more general to allow other encryption algorithms, some x-tokens can also be included so that people can try their own private algoritms too. The algoritm should no doubt be known to all the participants in the conference. Please clear my doubt as to why only "pgp" is mentioned and if people can use other techniques, in that case the grammar will definitely change. Thanking you, rahul _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. Share information about yourself, create your own public profile at http://profiles.msn.com. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 11 00:26:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA20308 for ; Wed, 11 Oct 2000 00:26:02 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A291D4433A; Tue, 10 Oct 2000 23:26:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 23E7244339 for ; Tue, 10 Oct 2000 23:25:49 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA19676; Wed, 11 Oct 2000 00:27:40 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Wed, 11 Oct 2000 00:21:57 -0400 Message-ID: From: Jonathan Rosenberg To: "'Jean-Francois Mule'" , "'SIP ietf wg'" Subject: RE: [SIP] re-INVITE with SDP modifications of media description MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 11 Oct 2000 00:21:56 -0400 Sounds right to me. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com > -----Original Message----- > From: Jean-Francois Mule [mailto:jfmule@clarent.com] > Sent: Tuesday, October 10, 2000 9:37 PM > To: SIP ietf wg > Subject: [SIP] re-INVITE with SDP modifications of media description > > > Context: > We consider the case of UDP transport only. A SIP session is > active between > UA1 and UA2. > A re-INVITE is sent with an updated SDP body from UA1 to UA2, > in particular, > a new media description is given (only 1 m= line appears in > SDP body, for > e.g., with a new RTP port). If the receiving UA, UA2, can > honor the new > request, it sends a 200 OK back to UA1. > > In that case, UA1 sends ACK and starts listening for media on > the new UDP > port. It also releases *any* previously allocated port for > that call / > connection (same cseq, call-id, to:, from:). Upon receipt of > ACK from UA1, > UA2 starts sending media to the new RTP port. > => Agreed? Comments? > > If the intent of UA1 is to add one additional media > connection, it MUST > repeat the previous m= lines. > => Agreed? Comments? > > Thank you in advance, > Jean-Francois Mule. > Clarent > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 11 00:47:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA20427 for ; Wed, 11 Oct 2000 00:47:02 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1AF3C4433A; Tue, 10 Oct 2000 23:47:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from june.Broomfield1.level3.net (june.Broomfield1.Level3.net [209.245.18.7]) by lists.bell-labs.com (Postfix) with ESMTP id CC32744339 for ; Tue, 10 Oct 2000 23:46:42 -0400 (EDT) Received: from f1ee40-19.idc1.level3.com (hme0.f1ee40-19.idc1.oss.level3.com [10.1.144.204]) by june.Broomfield1.level3.net (8.9.3/8.9.3) with ESMTP id EAA14716 for ; Wed, 11 Oct 2000 04:46:37 GMT From: Aparna.Vemuri@Level3.com Received: from n0195idc1.oss.level3.com (localhost [127.0.0.1]) by f1ee40-19.idc1.level3.com (8.8.8+Sun/8.8.8) with ESMTP id WAA16193 for ; Tue, 10 Oct 2000 22:46:26 -0600 (MDT) Received: by n0195idc1.oss.level3.com with Internet Mail Service (5.5.2650.21) id <4R3LTBVS>; Tue, 10 Oct 2000 22:48:17 -0600 Message-ID: To: sip@lists.bell-labs.com MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] Conferencing Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 10 Oct 2000 22:46:19 -0600 Hello. I have a question about SIP-based conferencing. Let us assume the existence of a SIP UA that performs conferencing. SIP UAs that want to join a conference send SIP INVITEs to the conference server to conference them in, i.e. for an n-party conference, the CS will receive n INVITEs. I believe there has to be a need for corrolation and disambiguation of the different call-legs at the conference server. For a dial-in conference such as this, I think the easiest (and the most intuitive) way to corrolate all these n INVITEs (that have different Call-IDs) is via the dialed number/ conference-ID (i.e. the "To" field). However, if all these different call-legs were initiated by a third-party entity (called the controller) that sent these INVITEs on behalf of the actual participants, how should the corrolation and disambiguation of call-legs be performed at the conference server? I think there are two options: a) Same as before. Have each one of the INVITEs have different Call-IDs and have the conferencing SIP UA corrolate them based on the "To" field. This requires the controller to have a mechanism to corrolate all these call-legs at its end. b) Mandate that all the call-legs share the same Call-ID. The 'From' field in each INVITE sent to the CS (from the controller) must then be tagged. The CS could use the Call-ID to corrolate all these call-legs and the tag in the From to help distinguish one from the other. Is there a reason to prefer one over the other? Is there a third option that I have missed? Is there a preferred/ accepted mechanism to accomplish this and is this documented somewhere? Thanks, Aparna _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 11 01:26:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA23491 for ; Wed, 11 Oct 2000 01:26:03 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A90D64433A; Wed, 11 Oct 2000 00:26:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lists.bell-labs.com (Postfix) with ESMTP id 3FE4044339 for ; Wed, 11 Oct 2000 00:25:01 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id e9B5Ott18315; Wed, 11 Oct 2000 07:24:55 +0200 (MEST) Received: from lmf.ericsson.se (E005004B57CE1.lmf.ericsson.se [131.160.30.148]) by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id IAA13843; Wed, 11 Oct 2000 08:24:55 +0300 (EET DST) Message-ID: <39E3F99A.2E10D31A@lmf.ericsson.se> 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: Aparna.Vemuri@Level3.com Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Conferencing References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 11 Oct 2000 08:24:42 +0300 Content-Transfer-Encoding: 7bit Hi Aparna, Check section 3 of: http://search.ietf.org/internet-drafts/draft-camarillo-3pcc-qos-00.txt The request-URI is used in order to know which conference you want to join. The example includes also a controller. Regards, Gonzalo Aparna.Vemuri@Level3.com wrote: > > Hello. > I have a question about SIP-based conferencing. Let us assume the existence > of a SIP UA that performs conferencing. SIP UAs that want to join a > conference send SIP INVITEs to the conference server to conference them in, > i.e. for an n-party conference, the CS will receive n INVITEs. I believe > there has to be a need for corrolation and disambiguation of the different > call-legs at the conference server. For a dial-in conference such as this, I > think the easiest (and the most intuitive) way to corrolate all these n > INVITEs (that have different Call-IDs) is via the dialed number/ > conference-ID (i.e. the "To" field). > > However, if all these different call-legs were initiated by a third-party > entity (called the controller) that sent these INVITEs on behalf of the > actual participants, how should the corrolation and disambiguation of > call-legs be performed at the conference server? > > I think there are two options: > a) Same as before. Have each one of the INVITEs have different Call-IDs and > have the conferencing SIP UA corrolate them based on the "To" field. > This requires the controller to have a mechanism to corrolate all these > call-legs at its end. > > b) Mandate that all the call-legs share the same Call-ID. The 'From' field > in each INVITE sent to the CS (from the controller) must then be tagged. > The CS could use the Call-ID to corrolate all these call-legs and the tag in > the From to help distinguish one from the other. > > Is there a reason to prefer one over the other? Is there a third option that > I have missed? Is there a preferred/ accepted mechanism to accomplish this > and is this documented somewhere? > > Thanks, > Aparna > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland http://www.hut.fi/~gonzalo _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 11 02:50:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA03911 for ; Wed, 11 Oct 2000 02:50:02 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1DC5F4433A; Wed, 11 Oct 2000 01:50:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from marie.nada.co.kr (mail.nadatel.com [203.229.244.2]) by lists.bell-labs.com (Postfix) with ESMTP id 369D344339 for ; Wed, 11 Oct 2000 01:49:02 -0400 (EDT) Received: from vctest1 ([192.168.1.153]) by marie.nada.co.kr (8.9.3/8.9.3) with SMTP id PAA12765; Wed, 11 Oct 2000 15:54:26 +0900 Message-ID: <004301c03350$1afc3370$9901a8c0@nadatel.com> From: "Junyoung Heo" To: "Gonzalo Camarillo" , Cc: References: <39E3F99A.2E10D31A@lmf.ericsson.se> Subject: Re: [SIP] Conferencing MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 11 Oct 2000 15:54:22 +0900 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id CAA03911 Hi, all. > Hi Aparna, > > Check section 3 of: > http://search.ietf.org/internet-drafts/draft-camarillo-3pcc-qos-00.txt > I cannot understand that draft camarillo-3pcc-qos-00. What is PRACK, COMET ? I have never seen these methods. Where can I find its definition? > The request-URI is used in order to know which conference you want to > join. I know request-URI may be changed by proxies. So, How changable field can be used as ID? And, I think, SIP is not necessary to support multi-unicast call itself. It overburden SIP. I like SIP for its simplicity. I use origin of SDP for conference ID. Thanks so much if you point out my misunderstanding about SIP and related doc. > The example includes also a controller. > > Regards, > > Gonzalo > > Aparna.Vemuri@Level3.com wrote: > > > > Hello. > > I have a question about SIP-based conferencing. Let us assume the existence > > of a SIP UA that performs conferencing. SIP UAs that want to join a > > conference send SIP INVITEs to the conference server to conference them in, > > i.e. for an n-party conference, the CS will receive n INVITEs. I believe > > there has to be a need for corrolation and disambiguation of the different > > call-legs at the conference server. For a dial-in conference such as this, I > > think the easiest (and the most intuitive) way to corrolate all these n > > INVITEs (that have different Call-IDs) is via the dialed number/ > > conference-ID (i.e. the "To" field). > > > > However, if all these different call-legs were initiated by a third-party > > entity (called the controller) that sent these INVITEs on behalf of the > > actual participants, how should the corrolation and disambiguation of > > call-legs be performed at the conference server? > > > > I think there are two options: > > a) Same as before. Have each one of the INVITEs have different Call-IDs and > > have the conferencing SIP UA corrolate them based on the "To" field. > > This requires the controller to have a mechanism to corrolate all these > > call-legs at its end. > > > > b) Mandate that all the call-legs share the same Call-ID. The 'From' field > > in each INVITE sent to the CS (from the controller) must then be tagged. > > The CS could use the Call-ID to corrolate all these call-legs and the tag in > > the From to help distinguish one from the other. > > > > Is there a reason to prefer one over the other? Is there a third option that > > I have missed? Is there a preferred/ accepted mechanism to accomplish this > > and is this documented somewhere? > > > > Thanks, > > Aparna > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > -- > Gonzalo Camarillo Phone : +358 9 299 33 71 > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > Telecom R&D Fax : +358 9 299 30 52 > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > Finland http://www.hut.fi/~gonzalo > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÒ ùšŠX§‚X¬µ"þX¬¶ÏÛzYÿ•¦ìýÊ&†ÛiÿÿåŠËlý·¥—ùZnÏÜ¢oæj)fjåŠËbú? From sip-admin@lists.bell-labs.com Wed Oct 11 03:14:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA04058 for ; Wed, 11 Oct 2000 03:14:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8B04F4433A; Wed, 11 Oct 2000 02:14:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lists.bell-labs.com (Postfix) with ESMTP id 2A6A544339 for ; Wed, 11 Oct 2000 02:13:33 -0400 (EDT) Received: from esealnt409.al.sw.ericsson.se (esealnt409.al.sw.ericsson.se [153.88.251.32]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id e9B7DSZ01926 for ; Wed, 11 Oct 2000 09:13:28 +0200 (MEST) Received: FROM esealnt743.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Wed Oct 11 09:13:27 2000 +0200 Received: by esealnt743.al.sw.ericsson.se with Internet Mail Service (5.5.2651.58) id ; Wed, 11 Oct 2000 09:13:28 +0200 Message-ID: <56E7307B0850D411B1480008C75DD5EAB73D17@enlrynt303.dsn.ericsson.se> From: "Arnoud van Wijk (ELN)" To: "Sip (E-mail)" Subject: RE: [SIP] The definition of Multi-media MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 11 Oct 2000 09:13:26 +0200 Hi, Let me clarify this question a little more. I also made an error in the "my definition".(I should take a nap first :-) A definition of Multimedia is real-time receiving of different media, which is audio and video and written data. No difference between streaming or download and then play. In fact everything that SIP does or initiates. :-) (but not SIP itself). But some definitions of Multimedia is simply always streaming data, in this way everything that is not sent via a real-time (streaming) protocol, is then not Multimedia? Even if you download a movieclip and a few seconds later it is being played on your computerscreen? It is still real-time delivery, just not streaming media. Thanks Arnoud van Wijk -----Original Message----- From: Arnoud van Wijk (ELN) Sent: dinsdag 10 okt 2000 16:59 To: Sip (E-mail) Subject: [SIP] The definition of Multi-media Hello all. I am encountering more and more issues about the definition of multimedia. We at the SIP WG are actually enabling Multimedia IP (VoIP is just the beginning). Is multimedia now streaming video, audio and voice? Would an RTP stream with text be multimedia? Would a file send to your mobile device be multimedia? (downloaded movie vs streaming video). Would an instant message sent to your buddy via SIP be part of multi-media? And IRC like chat via SIP? If any of you has a clear definition of Multimedia and possibly also the source, I will be very grateful. I do not want this to start a long discussion thread. But to make our work easier (and improve communications with managers and vendors so that we will indeed talk about the same case). Thanks Arnoud _______________________________________________________________ ERICSSON EUROLABS NETHERLANDS BV Arnoud van Wijk ABACUS Lab Research & Development (ELN/V) Fax: +31-161 247569 _______________________________________________________________ _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 11 03:45:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA04310 for ; Wed, 11 Oct 2000 03:45:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 827264433A; Wed, 11 Oct 2000 02:45:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lists.bell-labs.com (Postfix) with ESMTP id ED72844339 for ; Wed, 11 Oct 2000 02:44:25 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id e9B7iJZ18979; Wed, 11 Oct 2000 09:44:19 +0200 (MEST) Received: from lmf.ericsson.se (E005004B57CE1.lmf.ericsson.se [131.160.30.148]) by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id KAA24392; Wed, 11 Oct 2000 10:44:15 +0300 (EET DST) Message-ID: <39E41A41.F08632A6@lmf.ericsson.se> 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: Junyoung Heo Cc: Aparna.Vemuri@Level3.com, sip@lists.bell-labs.com Subject: Re: [SIP] Conferencing References: <39E3F99A.2E10D31A@lmf.ericsson.se> <004301c03350$1afc3370$9901a8c0@nadatel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 11 Oct 2000 10:44:01 +0300 Content-Transfer-Encoding: 7bit Hi, > I cannot understand that draft camarillo-3pcc-qos-00. > > What is PRACK, COMET ? > Check these references out: http://search.ietf.org/internet-drafts/draft-ietf-sip-100rel-02.txt http://search.ietf.org/internet-drafts/draft-manyfolks-sip-resource-01.txt http://search.ietf.org/internet-drafts/draft-camarillo-manyfolks-confirm-00.txt Gonzalo -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland http://www.hut.fi/~gonzalo _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 11 04:09:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA04568 for ; Wed, 11 Oct 2000 04:09:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 122F54433A; Wed, 11 Oct 2000 03:09:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from drago1.ubiquity.net (unknown [194.202.146.92]) by lists.bell-labs.com (Postfix) with SMTP id 1519044339 for ; Wed, 11 Oct 2000 03:08:26 -0400 (EDT) Received: from gecko.ubiquity.co.uk by drago1.ubiquity.net via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 11 Oct 2000 08:08:50 UT Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id JAA22822; Wed, 11 Oct 2000 09:06:42 +0100 (BST) Message-ID: <39E41F92.2CAB95D2@ubiquity.net> From: Neil Deason Organization: Ubiquity Software Corporation Limited X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "Schmidlin, David" Cc: "'sip@lists.bell-labs.com'" Subject: Re: [SIP] Sip Proxy/Clients for download. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 11 Oct 2000 09:06:42 +0100 Content-Transfer-Encoding: 7bit Hi David. Ubiquity has made a User Agent, capable of doing the SIP signalling and supporting audio, freely available from www.sipcenter.com. We have also provided a public SIP Proxy, running at sip.sipcenter.com port 5060, to test against. hth, Neil -- Ubiquity Software Corporation, UK http://www.ubiquity.net "Schmidlin, David" wrote: > > All, > > Are there any SIP Proxy's and/or clients that are available download on a > trial basis that > can be used to test our product? > > Thanks, > David > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 11 04:36:00 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA04782 for ; Wed, 11 Oct 2000 04:36:00 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3EF094433A; Wed, 11 Oct 2000 03:36:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14]) by lists.bell-labs.com (Postfix) with ESMTP id C3D2D44339 for ; Wed, 11 Oct 2000 03:35:31 -0400 (EDT) Received: from zcard015.ca.nortel.com (actually zcard015) by smtprch1.nortel.com; Wed, 11 Oct 2000 03:32:05 -0500 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) id <4VK49KY9>; Wed, 11 Oct 2000 04:31:55 -0400 Message-ID: <01F6ABE44577D31187900000F805A8D5C67E92@crchy270.us.nortel.com> From: "Pedro Luna" To: "'sip@lists.bell-labs.com'" Subject: RE: [SIP] Sip Proxy/Clients for download. MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0335D.B40E6030" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 11 Oct 2000 04:31:51 -0400 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_01C0335D.B40E6030 Content-Type: text/plain; charset="iso-8859-1" Howdy! The Nortel Networks SIP Proxy is publicly available at http://sipfx.com We also have a SIP to PRI Gateway at the same address. Cheerio, Pedro Pedro Luna SIP Shared Components Manager CS3000 IMS ped@nortelnetworks.com Nortel Networks, Richardson > -----Original Message----- > From: Schmidlin, David [mailto:david.schmidlin@intel.com] > Sent: Tuesday, October 10, 2000 12:42 PM > To: 'sip@lists.bell-labs.com' > Subject: [SIP] Sip Proxy/Clients for download. > > > All, > > Are there any SIP Proxy's and/or clients that are available > download on a > trial basis that > can be used to test our product? > > Thanks, > David > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > ------_=_NextPart_001_01C0335D.B40E6030 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [SIP] Sip Proxy/Clients for download.

Howdy!  The Nortel Networks SIP Proxy is = publicly available at
http://sipfx.com   We also have a SIP = to PRI Gateway at the same
address.

Cheerio,

Pedro

Pedro Luna
SIP Shared Components Manager
CS3000 IMS
ped@nortelnetworks.com
Nortel Networks, Richardson




> -----Original Message-----
> From: Schmidlin, David [mailto:david.schmidlin@intel.c= om]
> Sent: Tuesday, October 10, 2000 12:42 PM
> To: 'sip@lists.bell-labs.com'
> Subject: [SIP] Sip Proxy/Clients for = download.
>
>
> All,
>
> Are there any SIP Proxy's and/or clients that = are available
> download on a
> trial basis that
> can be used to test our product?
>
> Thanks,
> David
>
>
> = _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip
>

------_=_NextPart_001_01C0335D.B40E6030-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 11 05:23:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA05054 for ; Wed, 11 Oct 2000 05:23:00 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4BF8C4433A; Wed, 11 Oct 2000 04:23:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mail-in.audiocodes.com (AC-INT-LP.ser.netvision.net.il [212.143.113.33]) by lists.bell-labs.com (Postfix) with ESMTP id 3AB0044339 for ; Wed, 11 Oct 2000 04:22:26 -0400 (EDT) Received: by MAIL-IN with Internet Mail Service (5.5.2650.21) id <44ASGMR3>; Wed, 11 Oct 2000 11:21:06 +0200 Message-ID: <81C3E8FE6C0AD4119D49009027C3AAB28C25FD@MAIL-IN> From: Michel Eilat To: "'sip@lists.bell-labs.com'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="windows-1255" Subject: [SIP] Phone number in SIP Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 11 Oct 2000 11:21:05 +0200 Hello all, Let's imagine that a call need to be made from a POTS telephone to a SIP endpoint through a PSTN-SIP GW. From the POTS, one will dial for example 1234. How is the GW suppose to complete the SIP address form the phone number. What procedure must the GW undergo ? Sorry if it is off interset - new to SIP Michel Eilat Audiocodes LTD 4 Hahoresh St, P.O.Box 14 Yehud 56470 Israel Direct: +972-3-5394160 Fax: +972-3-5394040 Email: michel.eilat@audiocodes.com Web Site: http://www.audiocodes.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 11 05:35:00 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA05158 for ; Wed, 11 Oct 2000 05:35:00 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 62292443D7; Wed, 11 Oct 2000 04:35:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lists.bell-labs.com (Postfix) with ESMTP id D126444339 for ; Wed, 11 Oct 2000 04:34:01 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id e9B9XtZ02730; Wed, 11 Oct 2000 11:33:55 +0200 (MEST) Received: from lmf.ericsson.se (E005004B57CE1.lmf.ericsson.se [131.160.30.148]) by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id MAA03035; Wed, 11 Oct 2000 12:33:54 +0300 (EET DST) Message-ID: <39E433F5.6768FB14@lmf.ericsson.se> 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 Cc: adam.roach@ericsson.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] draft-camarillo-sip-isup-bcp-00.txt expired Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 11 Oct 2000 12:33:41 +0300 Content-Transfer-Encoding: 7bit Hi, We have reveived several quesions wondering when the new version of: http://search.ietf.org/internet-drafts/draft-camarillo-sip-isup-bcp-00.txt will be available. we are working on the last open issues and a new version will be released very soon. Regards, Gonzalo -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland http://www.hut.fi/~gonzalo _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 11 07:26:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA06820 for ; Wed, 11 Oct 2000 07:26:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 38C95443B3; Wed, 11 Oct 2000 06:26:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lists.bell-labs.com (Postfix) with ESMTP id 28FA244339 for ; Wed, 11 Oct 2000 05:31:44 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05676; Wed, 11 Oct 2000 06:31:40 -0400 (EDT) Message-Id: <200010111031.GAA05676@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@lists.bell-labs.com From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: [SIP] I-D ACTION:draft-levy-sip-diversion-00.txt Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 11 Oct 2000 06:31:40 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Diversion Indication in SIP Author(s) : S. Levy, B. Byerly, J. Yang Filename : draft-levy-sip-diversion-00.txt Pages : 40 Date : 10-Oct-00 This document proposes an extension to the Session Initiation Protocol (SIP). This extension provides the ability for the called SIP user agent to identify from whom the call was diverted and why the call was diverted. The extension defines a new general header, Diversion, which conveys the diversion information from other SIP user agents and proxies to the called user agent. This extension allows enhanced support for various features, including Unified Messaging, Third-Party Voicemail, and Automatic Call Distribution (ACD). SIP user agents and SIP proxies which receive diversion information may use this as supplemental information for feature invocation decisions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-levy-sip-diversion-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-levy-sip-diversion-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-levy-sip-diversion-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: <20001010143129.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-levy-sip-diversion-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-levy-sip-diversion-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001010143129.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 11 07:28:52 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA06859 for ; Wed, 11 Oct 2000 07:28:51 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 70B09443DA; Wed, 11 Oct 2000 06:27:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lists.bell-labs.com (Postfix) with ESMTP id 27FEB44339 for ; Wed, 11 Oct 2000 05:31:50 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05690; Wed, 11 Oct 2000 06:31:46 -0400 (EDT) Message-Id: <200010111031.GAA05690@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@lists.bell-labs.com From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: [SIP] I-D ACTION:draft-byerly-sip-hide-route-00.txt Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 11 Oct 2000 06:31:46 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : SIP Record-Route/Route Hiding Author(s) : B. Byerly, D. Daiker, S. Bhatnagar Filename : draft-byerly-sip-hide-route-00.txt Pages : 12 Date : 10-Oct-00 This document describes a proposed extension to SIP. This document proposes a mechansim to encrypt/hide Record-Route and Route entries in or to support confidentiality of SIP proxy routing information. The functionality of the Record-Route and Route headers are preserved. The introduction of this extension allows a set of trusted SIP proxies to cooperatively hide the route that SIP PDUs transit from untrusted proxies and user agents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-byerly-sip-hide-route-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-byerly-sip-hide-route-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-byerly-sip-hide-route-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: <20001010144022.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-byerly-sip-hide-route-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-byerly-sip-hide-route-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001010144022.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 11 07:35:43 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA07007 for ; Wed, 11 Oct 2000 07:35:42 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B27B1443E1; Wed, 11 Oct 2000 06:27:07 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lists.bell-labs.com (Postfix) with ESMTP id 5D90144339 for ; Wed, 11 Oct 2000 05:38:42 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05820; Wed, 11 Oct 2000 06:38:38 -0400 (EDT) Message-Id: <200010111038.GAA05820@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@lists.bell-labs.com From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: [SIP] I-D ACTION:draft-byerly-sip-radius-00.txt Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 11 Oct 2000 06:38:38 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : SIP Authentication using CHAP-Password Author(s) : B. Byerly, D. Williams Filename : draft-byerly-sip-radius-00.txt Pages : 13 Date : 10-Oct-00 This document describes a proposed extension to SIP. This document proposes using an alternative SIP authentication 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-byerly-sip-radius-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-byerly-sip-radius-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-byerly-sip-radius-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: <20001010150007.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-byerly-sip-radius-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-byerly-sip-radius-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001010150007.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 11 08:46:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA08883 for ; Wed, 11 Oct 2000 08:46:03 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id F0F4444392; Wed, 11 Oct 2000 07:46:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (unknown [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 59A7744339 for ; Wed, 11 Oct 2000 07:45:47 -0400 (EDT) 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 IAA02327; Wed, 11 Oct 2000 08:45:31 -0400 (EDT) Message-ID: <39E460EC.492EE0B7@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Junyoung Heo Cc: Gonzalo Camarillo , Aparna.Vemuri@Level3.com, sip@lists.bell-labs.com Subject: Re: [SIP] Conferencing References: <39E3F99A.2E10D31A@lmf.ericsson.se> <004301c03350$1afc3370$9901a8c0@nadatel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 11 Oct 2000 08:45:32 -0400 Content-Transfer-Encoding: 7bit Junyoung Heo wrote: > > Hi, all. > > > Hi Aparna, > > > > Check section 3 of: > > http://search.ietf.org/internet-drafts/draft-camarillo-3pcc-qos-00.txt > > > > I cannot understand that draft camarillo-3pcc-qos-00. > What is PRACK, COMET ? > I have never seen these methods. Where can I find its definition? You could, for example, consult the SIP web site at http://www.cs.columbia.edu/sip, under "drafts". -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 11 10:40:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA11970 for ; Wed, 11 Oct 2000 10:40:02 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D44AF4433A; Wed, 11 Oct 2000 09:40:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from drago1.ubiquity.net (unknown [194.202.146.92]) by lists.bell-labs.com (Postfix) with SMTP id 658CB44339 for ; Wed, 11 Oct 2000 09:39:00 -0400 (EDT) Received: from gecko.ubiquity.co.uk by drago1.ubiquity.net via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 11 Oct 2000 14:39:25 UT Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id PAA21470; Wed, 11 Oct 2000 15:37:18 +0100 (BST) Message-ID: <39E47B1F.D41D0A2D@ubiquity.net> From: Neil Deason Organization: Ubiquity Software Corporation Limited X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Subject: Re: [SIP] I-D ACTION:draft-byerly-sip-hide-route-00.txt References: <200010111031.GAA05690@ietf.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 11 Oct 2000 15:37:19 +0100 Content-Transfer-Encoding: 7bit There was a recent discussion on the list about Via hiding - the general feeling then was that it should be removed as it didn't really deliver and wasn't being implemented. This change was duly made in bis 02 and is documented in Section I. (Which I think should be titled Changes made in Version 02 not 01??). Cheers, Neil. -- Ubiquity Software Corporation, UK http://www.ubiquity.net Internet-Drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > Title : SIP Record-Route/Route Hiding > Author(s) : B. Byerly, D. Daiker, S. Bhatnagar > Filename : draft-byerly-sip-hide-route-00.txt > Pages : 12 > Date : 10-Oct-00 > > This document describes a proposed extension to SIP. > This document proposes a mechansim to encrypt/hide Record-Route and > Route entries in or to support confidentiality of SIP proxy > routing information. The functionality of the Record-Route and > Route headers are preserved. > The introduction of this extension allows a set of > trusted SIP proxies to cooperatively hide the route that > SIP PDUs transit from untrusted proxies and user agents. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 11 11:14:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA12789 for ; Wed, 11 Oct 2000 11:14:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A07D74433A; Wed, 11 Oct 2000 10:14:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cisco.com (bounty.cisco.com [161.44.3.204]) by lists.bell-labs.com (Postfix) with ESMTP id BA17D44339 for ; Wed, 11 Oct 2000 10:13:51 -0400 (EDT) Received: from cisco.com (blanc.cisco.com [161.44.3.203]) by cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id LAA21333; Wed, 11 Oct 2000 11:13:04 -0400 (EDT) Message-ID: <39E48377.8E20B647@cisco.com> From: Bryan Byerly X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Neil Deason , jdrosen@dynamicsoft.com, schulzrinne@cs.columbia.edu, sip@lists.bell-labs.com Cc: byerly@cisco.com, ddaiker@cisco.com, shbhatna@cisco.com, ntrivedi@cisco.com Subject: Re: [SIP] I-D ACTION:draft-byerly-sip-hide-route-00.txt References: <200010111031.GAA05690@ietf.org> <39E47B1F.D41D0A2D@ubiquity.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 11 Oct 2000 11:12:55 -0400 Content-Transfer-Encoding: 7bit Neil Deason wrote: > There was a recent discussion on the list about Via > hiding - the general feeling then was that it should > be removed as it didn't really deliver and wasn't being > implemented. I know of at least one vendor that has implemented Via header hiding. :-) It was my understanding from the discussion that the Via header hiding functionality was being removed (as a compliance) from the SIP bis draft. So, that makes Via header hiding optional for those that do not wish to implement it. It doesn't preclude others from implementing it. It would seem appropriate for Via header hiding to now be placed in a separate Internet-Draft for those that wish to use it. Jonathan/Henning, Is a Via header hiding draft in the works? Do you need volunteers to perform the extraction of Via into an I-D? thanks for your help, Bryan > This change was duly made in bis 02 and is documented > in Section I. (Which I think should be titled Changes > made in Version 02 not 01??). > > Cheers, > Neil. > -- > Ubiquity Software Corporation, UK http://www.ubiquity.net > > Internet-Drafts@ietf.org wrote: > > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > > Title : SIP Record-Route/Route Hiding > > Author(s) : B. Byerly, D. Daiker, S. Bhatnagar > > Filename : draft-byerly-sip-hide-route-00.txt > > Pages : 12 > > Date : 10-Oct-00 > > > > This document describes a proposed extension to SIP. > > This document proposes a mechansim to encrypt/hide Record-Route and > > Route entries in or to support confidentiality of SIP proxy > > routing information. The functionality of the Record-Route and > > Route headers are preserved. > > The introduction of this extension allows a set of > > trusted SIP proxies to cooperatively hide the route that > > SIP PDUs transit from untrusted proxies and user agents. > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 11 11:17:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA12843 for ; Wed, 11 Oct 2000 11:17:02 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C457F443E5; Wed, 11 Oct 2000 10:17:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (unknown [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 43AFF44339 for ; Wed, 11 Oct 2000 10:16:34 -0400 (EDT) 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 LAA12979; Wed, 11 Oct 2000 11:16:25 -0400 (EDT) Message-ID: <39E4844A.6FDD26F@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Bryan Byerly Cc: Neil Deason , jdrosen@dynamicsoft.com, sip@lists.bell-labs.com, ddaiker@cisco.com, shbhatna@cisco.com, ntrivedi@cisco.com Subject: Re: [SIP] I-D ACTION:draft-byerly-sip-hide-route-00.txt References: <200010111031.GAA05690@ietf.org> <39E47B1F.D41D0A2D@ubiquity.net> <39E48377.8E20B647@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 11 Oct 2000 11:16:26 -0400 Content-Transfer-Encoding: 7bit Bryan Byerly wrote: > > > Jonathan/Henning, > Is a Via header hiding draft in the works? Do you need volunteers to perform the > extraction of Via into an I-D? The reason that Via header hiding was removed is that some of us (including me) see it as a flawed mechanism. I can't prevent others from implementing anything, but I don't think I want to contribute to an I-D that prolongs its agony and further complicates the protocol, for extremely marginal gain in mostly feel-good security. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 11 11:46:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA13549 for ; Wed, 11 Oct 2000 11:46:02 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 82CB44436E; Wed, 11 Oct 2000 10:46:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from bbnrel4.net.external.hp.com (bbnrel4.net.external.hp.com [155.208.254.68]) by lists.bell-labs.com (Postfix) with ESMTP id D068344339 for ; Wed, 11 Oct 2000 10:45:02 -0400 (EDT) Received: from mylos.grenoble.hp.com (mylos.grenoble.hp.com [15.128.130.187]) by bbnrel4.net.external.hp.com (Postfix) with ESMTP id 04E31168BC; Wed, 11 Oct 2000 17:44:54 +0200 (METDST) Received: from mylos.grenoble.hp.com (labpc9.grenoble.hp.com [15.128.132.193]) by mylos.grenoble.hp.com with ESMTP (8.7.6/8.7.3 SMKit7.02) id RAA21586; Wed, 11 Oct 2000 17:44:54 +0200 (METDST) Message-ID: <39E48AF5.F7C2E55A@mylos.grenoble.hp.com> From: Frederic Huve Organization: Hewlett-Packard ( TID) X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Michel Eilat Cc: SIPbell-labs Subject: Re: [SIP] Phone number in SIP References: <81C3E8FE6C0AD4119D49009027C3AAB28C25FD@MAIL-IN> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 11 Oct 2000 17:44:53 +0200 Content-Transfer-Encoding: 7bit Michel, I think that you're missing a point, a SIP proxy have to take place between the PSTN-SIP GW and the SIP end point, this SIP proxy via some location logic translates the E164 to the SIP URL. see draft-johnston-sip-call-flows-00.txt (especially section 5). Fred. Michel Eilat wrote: > Hello all, > > Let's imagine that a call need to be made from a POTS telephone to a SIP > endpoint through a PSTN-SIP GW. From the POTS, one will dial for example > 1234. How is the GW suppose to complete the SIP address form the phone > number. What procedure must the GW undergo ? > > Sorry if it is off interset - new to SIP > > Michel Eilat > > Audiocodes LTD > 4 Hahoresh St, > P.O.Box 14 Yehud 56470 > Israel > > Direct: +972-3-5394160 > Fax: +972-3-5394040 > Email: michel.eilat@audiocodes.com > Web Site: http://www.audiocodes.com > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip -- Frederic HUVE 5,Avenue Raymond Chanas - Eybens R&D Engineer 38053 Grenoble Cedex 9 - FRANCE Telecom Infrastructure Division Tel +33 (0)4 76 14 47 43 Hewlett-Packard Fax +33 (0)4 76 14 14 88 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 11 12:18:10 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA14245 for ; Wed, 11 Oct 2000 12:18:09 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E96B6443D0; Wed, 11 Oct 2000 11:18:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from marvin.axion.bt.co.uk (marvin.axion.bt.co.uk [132.146.16.82]) by lists.bell-labs.com (Postfix) with ESMTP id 333C344339 for ; Wed, 11 Oct 2000 11:17:36 -0400 (EDT) Received: from cirwm3nt01.nor.bt.com by marvin (local) with ESMTP; Wed, 11 Oct 2000 17:16:44 +0100 Received: by cirwm3nt01.nor.bt.com with Internet Mail Service (5.5.2652.35) id <41BMN9L6>; Wed, 11 Oct 2000 17:16:38 +0100 Message-ID: From: clive.dellard@bt.com To: sip@lists.bell-labs.com MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: text/plain Subject: [SIP] From header to ISUP CgPN mapping Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 11 Oct 2000 17:16:33 +0100 In the call flows document draft-ietf-sip-call-flows-01.txt, scenario 4.1.1, the message detail and text show User A using a SIP telephone number rather than a SIP address in the From header. The text at the beginning of section 4 also says "that User A still uses his/her SIP URL in the Contact header, since the call could be redirected back to the SIP network." This implies that User A has pre-knowledge that the call is going to route to the PSTN and has the ability to chose the address to be used in the From header. This is maybe reasonable when calling a telephone number but what if User A makes a call to a SIP address and the called user has say forwarded their calls to a telephone number. If User A used a SIP address in the From header there would be no calling telephone number available when the call hits a gateway. Is there some way in which both the calling SIP address and SIP telephone number can be carried in an INVITE so that a Gateway (or even a Proxy?) could choose the appropriate calling identity to use? Regards, Clive Dellard 3G Networks > BTexaCT > > * PP 2C59, Angel Centre, 403 St. John Street, LONDON, EC1V 4PL. > * Office +44 20 7843 7084 > * Mobile +44 7711 045507 * +44 20 7843 6557 mailto:clive.dellard@bt.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 11 12:50:06 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA14971 for ; Wed, 11 Oct 2000 12:50:05 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8D561443CC; Wed, 11 Oct 2000 11:50:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from aphrodite.systems.cfer.com (me.voyanttech.com [63.89.131.5]) by lists.bell-labs.com (Postfix) with ESMTP id 8258144339 for ; Wed, 11 Oct 2000 11:49:28 -0400 (EDT) Received: from voyanttech.com (dough-pc.voyanttech.com [192.168.58.41]) by aphrodite.systems.cfer.com (8.8.8+Sun/8.8.8) with ESMTP id KAA24249; Wed, 11 Oct 2000 10:48:06 -0600 (MDT) Message-ID: <39E49B18.5BFF772@voyanttech.com> From: Doug Harbert X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: Aparna.Vemuri@level3.com Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Conferencing References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 11 Oct 2000 10:53:44 -0600 Content-Transfer-Encoding: 7bit Aparna.Vemuri@level3.com wrote: > Hello. > I have a question about SIP-based conferencing. Let us assume the existence > of a SIP UA that performs conferencing. SIP UAs that want to join a > conference send SIP INVITEs to the conference server to conference them in, > i.e. for an n-party conference, the CS will receive n INVITEs. I believe > there has to be a need for corrolation and disambiguation of the different > call-legs at the conference server. For a dial-in conference such as this, I > think the easiest (and the most intuitive) way to corrolate all these n > INVITEs (that have different Call-IDs) is via the dialed number/ > conference-ID (i.e. the "To" field). > > However, if all these different call-legs were initiated by a third-party > entity (called the controller) that sent these INVITEs on behalf of the > actual participants, how should the corrolation and disambiguation of > call-legs be performed at the conference server? > > I think there are two options: > a) Same as before. Have each one of the INVITEs have different Call-IDs and > have the conferencing SIP UA corrolate them based on the "To" field. > This requires the controller to have a mechanism to corrolate all these > call-legs at its end. > > b) Mandate that all the call-legs share the same Call-ID. The 'From' field > in each INVITE sent to the CS (from the controller) must then be tagged. > The CS could use the Call-ID to corrolate all these call-legs and the tag in > the From to help distinguish one from the other. > > Is there a reason to prefer one over the other? Is there a third option that > I have missed? Is there a preferred/ accepted mechanism to accomplish this > and is this documented somewhere? > > Thanks, > Aparna > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip Aparna: In either case, the conference controller must have some mechanism to correlate all of these calls and place them into the appropriate conference. In my opinion, supplying the conference identification in the request URI provides more flexibility for the SIP conference UA, and for the conference participants. I don't know how much control the third party conference controller assumes here, but participants may wish to access the conference via other means, for example, using the web to monitor the conference and dial out additional participants. It seems more intuitive to specify the name of the conference rather than a Call-ID and tag. The question that I have regarding the model in which all calls in a conference have the same Call-ID but are distinguished by tags on the FROM header is this: How do I know whether an INVITE represents a new call, or is simply an existing call which was forked by some proxy? Doug Harbert _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 11 13:20:08 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA15602 for ; Wed, 11 Oct 2000 13:20:08 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5EB41443F1; Wed, 11 Oct 2000 12:20:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from june.Broomfield1.level3.net (june.Broomfield1.Level3.net [209.245.18.7]) by lists.bell-labs.com (Postfix) with ESMTP id 56B1444339 for ; Wed, 11 Oct 2000 12:19:54 -0400 (EDT) Received: from f1ee40-19.idc1.level3.com (hme0.f1ee40-19.idc1.oss.level3.com [10.1.144.204]) by june.Broomfield1.level3.net (8.9.3/8.9.3) with ESMTP id RAA16336; Wed, 11 Oct 2000 17:19:47 GMT From: Aparna.Vemuri@Level3.com Received: from n0195idc1.oss.level3.com (localhost [127.0.0.1]) by f1ee40-19.idc1.level3.com (8.8.8+Sun/8.8.8) with ESMTP id LAA22299; Wed, 11 Oct 2000 11:19:46 -0600 (MDT) Received: by n0195idc1.oss.level3.com with Internet Mail Service (5.5.2650.21) id <4R3L4PTJ>; Wed, 11 Oct 2000 11:21:37 -0600 Message-ID: To: dough@voyanttech.com Cc: sip@lists.bell-labs.com Subject: RE: [SIP] Conferencing MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 11 Oct 2000 11:19:38 -0600 Doug, Pl. see my comments below. -Aparna -----Original Message----- From: Doug Harbert [ mailto:dough@voyanttech.com ] Sent: Wednesday, October 11, 2000 10:54 AM To: Vemuri, Aparna Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Conferencing Aparna.Vemuri@level3.com wrote: > Hello. > I have a question about SIP-based conferencing. Let us assume the existence > of a SIP UA that performs conferencing. SIP UAs that want to join a > conference send SIP INVITEs to the conference server to conference them in, > i.e. for an n-party conference, the CS will receive n INVITEs. I believe > there has to be a need for corrolation and disambiguation of the different > call-legs at the conference server. For a dial-in conference such as this, I > think the easiest (and the most intuitive) way to corrolate all these n > INVITEs (that have different Call-IDs) is via the dialed number/ > conference-ID (i.e. the "To" field). > > However, if all these different call-legs were initiated by a third-party > entity (called the controller) that sent these INVITEs on behalf of the > actual participants, how should the corrolation and disambiguation of > call-legs be performed at the conference server? > > I think there are two options: > a) Same as before. Have each one of the INVITEs have different Call-IDs and > have the conferencing SIP UA corrolate them based on the "To" field. > This requires the controller to have a mechanism to corrolate all these > call-legs at its end. > > b) Mandate that all the call-legs share the same Call-ID. The 'From' field > in each INVITE sent to the CS (from the controller) must then be tagged. > The CS could use the Call-ID to corrolate all these call-legs and the tag in > the From to help distinguish one from the other. > > Is there a reason to prefer one over the other? Is there a third option that > I have missed? Is there a preferred/ accepted mechanism to accomplish this > and is this documented somewhere? > > Thanks, > Aparna > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip Aparna: In either case, the conference controller must have some mechanism to correlate all of these calls and place them into the appropriate conference. In my opinion, supplying the conference identification in the request URI provides more flexibility for the SIP conference UA, and for the conference participants. I don't know how much control the third party conference controller assumes here, but participants may wish to access the conference via other means, for example, using the web to monitor the conference and dial out additional participants. It seems more intuitive to specify the name of the conference rather than a Call-ID and tag. The question that I have regarding the model in which all calls in a conference have the same Call-ID but are distinguished by tags on the FROM header is this: How do I know whether an INVITE represents a new call, or is simply an existing call which was forked by some proxy? Aparna says: 1. A call-leg is defined by a combination of the Call-ID, the To and the From (including any tags). The process for determining whether a request is new or not involves a three step process described in section 11.5 of the spec (and I believe it involves a comparison of the To and the From (including the tags) and the Call-ID.) My understanding is that a mismatch in the To and the From (tags included) should be interpreted as a new call-leg. 2. The tag in the From MUST be present when there are two instances of a user sharing a SIP address making call invitations with the same Call-ID. Our case is similar to this in that the controller issues INVITEs on behalf of all the participants. 3. The proxy copies the To, From, Call-ID and Contact tags from the original request. The proxy does not modify the tags in any way. It adds a branch parameter to the Via field. Aparna _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 11 13:41:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA16022 for ; Wed, 11 Oct 2000 13:41:02 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id BD6AD443F0; Wed, 11 Oct 2000 12:41:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from dnspri.npac.com (dnspri.npac.com [208.143.33.66]) by lists.bell-labs.com (Postfix) with ESMTP id 3E08544339 for ; Wed, 11 Oct 2000 12:40:07 -0400 (EDT) Received: by dnspri.npac.com; id MAA25359; Wed, 11 Oct 2000 12:40:02 -0500 (CDT) Received: from unknown(208.143.39.132) by dnspri.npac.com via smap (V5.0) id xma025034; Wed, 11 Oct 00 12:39:22 -0500 Received: by chi02.npac.com with Internet Mail Service (5.5.2650.21) id ; Wed, 11 Oct 2000 12:38:00 -0500 Message-ID: From: James Yu To: Michel Eilat Cc: SIPbell-labs , "'Frederic Huve'" Subject: RE: [SIP] Phone number in SIP MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 11 Oct 2000 12:35:37 -0500 Michel, It is an issue on how the PSTN will route the call to a GW. It may be the number itself that causes the PSTN to route the call to a GW or may be that the originating PSTN always routes the calls to a GW or a set of GWs. Since your question is about what happens when the GW receives the call, I'll mention one possibility - use ENUM (Telephone Number Mapping: phone number in ... URL out). The GW can initiate the ENUM process to retrieve all the NAPTR RRs associated with that phone number and selects the SIP URL(s) to route the call, or the GW can route the call to a SIP proxy server, which then initiates the ENUM process. An I-D on how to use ENUM to support SIP services will be out soon. James > -----Original Message----- > From: Frederic Huve [mailto:fred@mylos.grenoble.hp.com] > Sent: Wednesday, October 11, 2000 11:45 AM > To: Michel Eilat > Cc: SIPbell-labs > Subject: Re: [SIP] Phone number in SIP > > > Michel, > > I think that you're missing a point, a SIP proxy have to take > place between > the PSTN-SIP GW and the SIP end point, this SIP proxy via > some location logic > translates the E164 to the SIP URL. > see draft-johnston-sip-call-flows-00.txt (especially section 5). > > Fred. > > Michel Eilat wrote: > > > Hello all, > > > > Let's imagine that a call need to be made from a POTS > telephone to a SIP > > endpoint through a PSTN-SIP GW. From the POTS, one will > dial for example > > 1234. How is the GW suppose to complete the SIP address > form the phone > > number. What procedure must the GW undergo ? > > > > Sorry if it is off interset - new to SIP > > > > Michel Eilat > > > > Audiocodes LTD > > 4 Hahoresh St, > > P.O.Box 14 Yehud 56470 > > Israel > > > > Direct: +972-3-5394160 > > Fax: +972-3-5394040 > > Email: michel.eilat@audiocodes.com > > Web Site: http://www.audiocodes.com > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > -- > Frederic HUVE 5,Avenue Raymond Chanas - Eybens > R&D Engineer 38053 Grenoble Cedex 9 - FRANCE > Telecom Infrastructure Division Tel +33 (0)4 76 14 47 43 > Hewlett-Packard Fax +33 (0)4 76 14 14 88 > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 11 14:29:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA17272 for ; Wed, 11 Oct 2000 14:29:02 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7C89F4436E; Wed, 11 Oct 2000 13:29:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 2511F44339 for ; Wed, 11 Oct 2000 13:28:23 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id OAA25634; Wed, 11 Oct 2000 14:30:23 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <4WS2X2W4>; Wed, 11 Oct 2000 14:24:39 -0400 Message-ID: From: Jonathan Rosenberg To: "'Aparna.Vemuri@Level3.com'" , "'sip@lists.bell-labs.com'" Subject: RE: [SIP] Conferencing MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 11 Oct 2000 14:24:38 -0400 In the dial-up conference model, the request URI is really the only usable identifier that can describe the conference. Think of it as exactly the way conferences work in the PSTN; you dial a number plus a passcode (whcih is just an extension of the number, needed because of the limited number of phone numbers available), and that number represents the conference. Same here. A conferencing server should mix together everyone who calls the same request URI; that would be the nature of the resource defined by the collection of URIs on the conference server. As an example, a conference server might define: *-adhoc@conferences.com where * is anything, to represent ad-hoc conferences which don't even need to be pre-established. Junyoung writes: > I know request-URI may be changed by proxies. > So, How changable field can be used as ID? > And, I think, SIP is not necessary to support multi-unicast > call itself. > It overburden SIP. I like SIP for its simplicity. > I use origin of SDP for conference ID. Request URIs are not changed arbitrarily. They are changed in order to properly route the request to the identifed resource. Such translations may be needed even for conferences. Here's an example. Lets say you have a conference service, conferences.com. It hosts two servers, one for ad-hoc conferences, and another for pre-established conferences. WHen a call arrives at the conferences.com proxy, it examines the user part of the request URI. If its foo-adhoc, it gets translated to foo-adhoc@adhocserver.conferences.com, and proxied there. If its just some pre-arranged conference, conference21@conferences.com, that might get proxied to conference21@mainserver.conferences.com. Each of those servers is then configured to accept calls only for *-adhoc@adhocserver.conferences.com in the first case, and *@mainserver.conferences.com in the second. As another example, lets say I'm supposed to be in a conference call with Joe at 10am. I've forgotten the conference ID (i.e., the request URI), so I call joe. Joe has a CPL configured that if I call him during the conference, it proxies the request to the conference ID. Thus, the call will be forwarded there and I get dropped right into the conference with Joe. This service would not be possible if the request URI were not used as the conference ID. Whenever you want to access a service associated with some server on the network, and that server acts as a user agent (examples include IVR servers, media servers, conferencing servers, translation servers, etc.), using the request URI as the service identifier is an absolute MUST. This is exactly what the definition of the request URI is, and it has the really important advantage of turning a variety of service access problems into *routing* problems. Thats why I can write a CPL to drop someone into a conference when they call at a certain time; using the request URI as the conference identifier makes it into a routing problem, which is within the domain of CPL. I have an I-D pending that puts this all together and explains how this model of accessing certain services through defined patterns on the request URI has huge advantages. Should be out in a few weeks. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com > -----Original Message----- > From: Aparna.Vemuri@Level3.com [mailto:Aparna.Vemuri@Level3.com] > Sent: Wednesday, October 11, 2000 12:46 AM > To: sip@lists.bell-labs.com > Subject: [SIP] Conferencing > > > Hello. > I have a question about SIP-based conferencing. Let us assume > the existence > of a SIP UA that performs conferencing. SIP UAs that want to join a > conference send SIP INVITEs to the conference server to > conference them in, > i.e. for an n-party conference, the CS will receive n > INVITEs. I believe > there has to be a need for corrolation and disambiguation of > the different > call-legs at the conference server. For a dial-in conference > such as this, I > think the easiest (and the most intuitive) way to corrolate > all these n > INVITEs (that have different Call-IDs) is via the dialed number/ > conference-ID (i.e. the "To" field). > > However, if all these different call-legs were initiated by a > third-party > entity (called the controller) that sent these INVITEs on > behalf of the > actual participants, how should the corrolation and disambiguation of > call-legs be performed at the conference server? > > I think there are two options: > a) Same as before. Have each one of the INVITEs have > different Call-IDs and > have the conferencing SIP UA corrolate them based on the "To" field. > This requires the controller to have a mechanism to corrolate > all these > call-legs at its end. > > b) Mandate that all the call-legs share the same Call-ID. The > 'From' field > in each INVITE sent to the CS (from the controller) must > then be tagged. > The CS could use the Call-ID to corrolate all these call-legs > and the tag in > the From to help distinguish one from the other. > > Is there a reason to prefer one over the other? Is there a > third option that > I have missed? Is there a preferred/ accepted mechanism to > accomplish this > and is this documented somewhere? > > Thanks, > Aparna > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 11 14:30:27 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA17324 for ; Wed, 11 Oct 2000 14:30:27 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1D1CF44406; Wed, 11 Oct 2000 13:29:11 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by lists.bell-labs.com (Postfix) with SMTP id 52DE744339 for ; Wed, 11 Oct 2000 13:28:59 -0400 (EDT) Received: from 157.54.9.104 by mail2.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 11 Oct 2000 11:09:57 -0700 (Pacific Daylight Time) Received: by INET-IMC-02 with Internet Mail Service (5.5.2651.58) id <4ST4G2GS>; Wed, 11 Oct 2000 11:07:22 -0700 Message-ID: From: Christian Huitema To: "'Frederic Huve'" , Michel Eilat Cc: SIPbell-labs Subject: RE: [SIP] Phone number in SIP X-Mailer: Internet Mail Service (5.5.2651.58) Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 11 Oct 2000 11:07:05 -0700 Assume that the gateway receiving the call learns the dialed number, e.g. through caller-id, through ISDN signalling, or through SS7. There are at least two ways to perform the translation between this phone nuber and a destination address: you can either use ENUM, and look for a mapping from the dialed number to the sip service, or you can use a local database, somehow managed by the gateway (or by the call agent that controls the gateway.) The local database makes a lot of sense, since there must be some relation between the called number and the gateway service, otherwise the call would not be routed to the gateway in the first place. The local database could indeed use the ENUM technology. If the gateway is reached through a generic number, or through a service selection procedure such as the "10xxx" prefixes in the US, then using ENUM makes a lot of sense. -- Christian Huitema > -----Original Message----- > From: Frederic Huve [mailto:fred@mylos.grenoble.hp.com] > Sent: Wednesday, October 11, 2000 8:45 AM > To: Michel Eilat > Cc: SIPbell-labs > Subject: Re: [SIP] Phone number in SIP > > > Michel, > > I think that you're missing a point, a SIP proxy have to take > place between > the PSTN-SIP GW and the SIP end point, this SIP proxy via > some location logic > translates the E164 to the SIP URL. > see draft-johnston-sip-call-flows-00.txt (especially section 5). > > Fred. > > Michel Eilat wrote: > > > Hello all, > > > > Let's imagine that a call need to be made from a POTS > telephone to a SIP > > endpoint through a PSTN-SIP GW. From the POTS, one will > dial for example > > 1234. How is the GW suppose to complete the SIP address > form the phone > > number. What procedure must the GW undergo ? > > > > Sorry if it is off interset - new to SIP > > > > Michel Eilat > > > > Audiocodes LTD > > 4 Hahoresh St, > > P.O.Box 14 Yehud 56470 > > Israel > > > > Direct: +972-3-5394160 > > Fax: +972-3-5394040 > > Email: michel.eilat@audiocodes.com > > Web Site: http://www.audiocodes.com > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > -- > Frederic HUVE 5,Avenue Raymond Chanas - Eybens > R&D Engineer 38053 Grenoble Cedex 9 - FRANCE > Telecom Infrastructure Division Tel +33 (0)4 76 14 47 43 > Hewlett-Packard Fax +33 (0)4 76 14 14 88 > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 11 14:45:17 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA17814 for ; Wed, 11 Oct 2000 14:45:17 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id F1638443FC; Wed, 11 Oct 2000 13:45:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id D0EB244339 for ; Wed, 11 Oct 2000 13:44:32 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id OAA26007; Wed, 11 Oct 2000 14:46:28 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <4WS2X2ZB>; Wed, 11 Oct 2000 14:40:44 -0400 Message-ID: From: Jonathan Rosenberg To: "'clive.dellard@bt.com'" , "'sip@lists.bell-labs.com'" Subject: RE: [SIP] From header to ISUP CgPN mapping MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 11 Oct 2000 14:40:43 -0400 > -----Original Message----- > From: clive.dellard@bt.com [mailto:clive.dellard@bt.com] > Sent: Wednesday, October 11, 2000 12:17 PM > To: sip@lists.bell-labs.com > Subject: [SIP] From header to ISUP CgPN mapping > > > In the call flows document draft-ietf-sip-call-flows-01.txt, > scenario 4.1.1, > the message detail and text show User A using a SIP telephone > number rather > than a SIP address in the From header. The text at the > beginning of section > 4 also says "that User A still uses his/her SIP URL in the > Contact header, > since the call could be redirected back to the SIP network." > This implies that User A has pre-knowledge that the call is > going to route > to the PSTN and has the ability to chose the address to be > used in the From > header. No. The From header is the logical identity of the user making the call. Since the call is coming through a gateway, that user is some user on a PSTN terminal somewhere. The identity in this case can either be a tel URL, or a SIP URL at the domain of the originating network. The Contact is used for signaling addressing. Its not a logical identifier. It answers the question "where should I send SIP messages to for the rest of this call". The SIP spec says this is supposed to be a SIP URL preferably with a complete hostname, so that there are no ambiguities about where to send requests. Neither of these have anything to do with knowing where the call is going. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 11 15:06:07 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA18632 for ; Wed, 11 Oct 2000 15:06:04 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E9180443EF; Wed, 11 Oct 2000 14:06:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by lists.bell-labs.com (Postfix) with ESMTP id A5A8944339 for ; Wed, 11 Oct 2000 14:01:51 -0400 (EDT) Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id MAA24155; Wed, 11 Oct 2000 12:01:45 -0700 (PDT) Message-Id: <200010111901.MAA24155@boreas.isi.edu> To: IETF-Announce: ; Cc: rfc-ed@ISI.EDU, sip@lists.bell-labs.com Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart From: RFC Editor Subject: [SIP] RFC 2976 on SIP INFO Method Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 11 Oct 2000 12:01:45 -0700 --NextPart A new Request for Comments is now available in online RFC libraries. RFC 2976 Title: The SIP INFO Method Author(s): S. Donovan Status: Standards Track Date: October 2000 Mailbox: sdonovan@dynamicsoft.com Pages: 9 Characters: 17736 Updates/Obsoletes/SeeAlso: none I-D Tag: draft-ietf-sip-info-method-05.txt URL: ftp://ftp.isi.edu/in-notes/rfc2976.txt This document proposes an extension to the Session Initiation Protocol (SIP). This extension adds the INFO method to the SIP protocol. The intent of the INFO method is to allow for the carrying of session related control information that is generated during a session. One example of such session control information is ISUP and ISDN signaling messages used to control telephony call services. This and other example uses of the INFO method may be standardized in the future. This document is a product of the Session Initiation Protocol Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <001011115946.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc2976 --OtherAccess Content-Type: Message/External-body; name="rfc2976.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <001011115946.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 11 15:14:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA18845 for ; Wed, 11 Oct 2000 15:14:03 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6EA9944401; Wed, 11 Oct 2000 14:14:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from rwcxch02.clarent.com (unknown [208.205.112.25]) by lists.bell-labs.com (Postfix) with ESMTP id 565F744339 for ; Wed, 11 Oct 2000 14:13:39 -0400 (EDT) Received: by rwcxch02.clarent.com with Internet Mail Service (5.5.2650.21) id <4V3FLS94>; Wed, 11 Oct 2000 12:11:42 -0700 Message-ID: <6374EFC78443D41197DD00508B5C35DD014902D5@rwcxch02.clarent.com> From: Jean-Francois Mule To: James Yu , Michel Eilat Cc: SIPbell-labs , "'Frederic Huve'" Subject: RE: [SIP] Phone number in SIP MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 11 Oct 2000 12:11:39 -0700 The second method combining James & Christian' suggestions is more elegant: pstn-sip gw --> PROXY: use of ENUM or any other location services like LDAP directory, look-up in local DB to translate abbreviated number into a "routable" one. Jean-Francois. James Yu wrote: > -----Original Message----- > From: James Yu [mailto:james.yu@neustar.com] ... snip > I'll mention one possibility - use ENUM (Telephone Number > Mapping: phone > number in ... URL out). The GW can initiate the ENUM > process to retrieve > all the NAPTR RRs associated with that phone number and > selects the SIP > URL(s) to route the call, or the GW can route the call to a SIP proxy > server, which then initiates the ENUM process. An I-D on how > to use ENUM to > support SIP services will be out soon. > > James _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 11 16:14:06 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA20669 for ; Wed, 11 Oct 2000 16:14:03 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B710D4433A; Wed, 11 Oct 2000 15:14:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from wusr3.mobilerain.com (sdsl-208-185-234-252.dsl.sjc.megapath.net [208.185.234.252]) by lists.bell-labs.com (Postfix) with ESMTP id 3293C44339 for ; Wed, 11 Oct 2000 15:13:33 -0400 (EDT) Received: from mobilerain.com (IDENT:dsardana@localhost [127.0.0.1]) by wusr3.mobilerain.com (8.9.3/8.9.3) with ESMTP id NAA24712; Wed, 11 Oct 2000 13:10:52 -0700 Message-ID: <39E4C94C.32BDD184@mobilerain.com> From: Bobby Sardana Organization: MobileRain Technologies, Inc. X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: Jean-Francois Mule Cc: James Yu , Michel Eilat , SIPbell-labs , "'Frederic Huve'" Subject: Re: [SIP] Phone number in SIP References: <6374EFC78443D41197DD00508B5C35DD014902D5@rwcxch02.clarent.com> Content-Type: multipart/mixed; boundary="------------CB3C918CEECE09049F613DEA" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 11 Oct 2000 13:10:52 -0700 This is a multi-part message in MIME format. --------------CB3C918CEECE09049F613DEA Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Greetings: An I-D: http://www.ietf.org/internet-drafts/draft-lind-enum-callflows-00.txt does describe the use of ENUM and SIP. I was wondering what the new I-D, as mentioned by James Yu, will reflect? Regards, Bobby.Sardana@mobilerain.com Jean-Francois Mule wrote: > The second method combining James & Christian' suggestions is more elegant: > pstn-sip gw --> PROXY: use of ENUM or any other location services like LDAP > directory, look-up in local DB to translate abbreviated number into a > "routable" one. > > Jean-Francois. > > James Yu wrote: > > -----Original Message----- > > From: James Yu [mailto:james.yu@neustar.com] > ... snip > > I'll mention one possibility - use ENUM (Telephone Number > > Mapping: phone > > number in ... URL out). The GW can initiate the ENUM > > process to retrieve > > all the NAPTR RRs associated with that phone number and > > selects the SIP > > URL(s) to route the call, or the GW can route the call to a SIP proxy > > server, which then initiates the ENUM process. An I-D on how > > to use ENUM to > > support SIP services will be out soon. > > > > James > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip --------------CB3C918CEECE09049F613DEA Content-Type: text/x-vcard; charset=us-ascii; name="bobby.sardana.vcf" Content-Description: Card for Bobby Sardana Content-Disposition: attachment; filename="bobby.sardana.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Sardana;Bobby x-mozilla-html:FALSE org:MobileRain Technologies, Inc.;Telecommunications adr:;;;;;; version:2.1 email;internet:bobby.sardana@mobilerain.com title:Engineer x-mozilla-cpt:;0 fn:Bobby Sardana end:vcard --------------CB3C918CEECE09049F613DEA-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 11 16:54:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA21506 for ; Wed, 11 Oct 2000 16:54:05 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 991CB44386; Wed, 11 Oct 2000 15:54:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sj_exchange.sj.nuera.com (h-207-20-110-62.ncal.verio.net [207.20.110.62]) by lists.bell-labs.com (Postfix) with ESMTP id D8FFC44339 for ; Wed, 11 Oct 2000 15:53:44 -0400 (EDT) Received: by exchange.sj.nuera.com with Internet Mail Service (5.5.2650.21) id <4C7KR3TC>; Wed, 11 Oct 2000 13:53:36 -0700 Message-ID: <350860CC5B2AD311991D0008C7F7EEAAA0264E@exchange.sj.nuera.com> From: "Emami-Nouri, Mohsen" To: "'Christian Huitema'" , "'Frederic Huve'" , Michel Eilat Cc: SIPbell-labs Subject: RE: [SIP] Phone number in SIP MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 11 Oct 2000 13:53:36 -0700 I think TRIP is the other possibility. It is not as elegant as ENUM, but it addresses the routing information update well. -----Original Message----- From: Christian Huitema [mailto:huitema@microsoft.com] Sent: Wednesday, October 11, 2000 11:07 AM To: 'Frederic Huve'; Michel Eilat Cc: SIPbell-labs Subject: RE: [SIP] Phone number in SIP Assume that the gateway receiving the call learns the dialed number, e.g. through caller-id, through ISDN signalling, or through SS7. There are at least two ways to perform the translation between this phone nuber and a destination address: you can either use ENUM, and look for a mapping from the dialed number to the sip service, or you can use a local database, somehow managed by the gateway (or by the call agent that controls the gateway.) The local database makes a lot of sense, since there must be some relation between the called number and the gateway service, otherwise the call would not be routed to the gateway in the first place. The local database could indeed use the ENUM technology. If the gateway is reached through a generic number, or through a service selection procedure such as the "10xxx" prefixes in the US, then using ENUM makes a lot of sense. -- Christian Huitema > -----Original Message----- > From: Frederic Huve [mailto:fred@mylos.grenoble.hp.com] > Sent: Wednesday, October 11, 2000 8:45 AM > To: Michel Eilat > Cc: SIPbell-labs > Subject: Re: [SIP] Phone number in SIP > > > Michel, > > I think that you're missing a point, a SIP proxy have to take > place between > the PSTN-SIP GW and the SIP end point, this SIP proxy via > some location logic > translates the E164 to the SIP URL. > see draft-johnston-sip-call-flows-00.txt (especially section 5). > > Fred. > > Michel Eilat wrote: > > > Hello all, > > > > Let's imagine that a call need to be made from a POTS > telephone to a SIP > > endpoint through a PSTN-SIP GW. From the POTS, one will > dial for example > > 1234. How is the GW suppose to complete the SIP address > form the phone > > number. What procedure must the GW undergo ? > > > > Sorry if it is off interset - new to SIP > > > > Michel Eilat > > > > Audiocodes LTD > > 4 Hahoresh St, > > P.O.Box 14 Yehud 56470 > > Israel > > > > Direct: +972-3-5394160 > > Fax: +972-3-5394040 > > Email: michel.eilat@audiocodes.com > > Web Site: http://www.audiocodes.com > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > -- > Frederic HUVE 5,Avenue Raymond Chanas - Eybens > R&D Engineer 38053 Grenoble Cedex 9 - FRANCE > Telecom Infrastructure Division Tel +33 (0)4 76 14 47 43 > Hewlett-Packard Fax +33 (0)4 76 14 14 88 > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 11 16:58:32 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA21596 for ; Wed, 11 Oct 2000 16:58:26 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 224E644411; Wed, 11 Oct 2000 15:58:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ivigate.intervoice.com (ivigate.intervoice.com [208.200.21.196]) by lists.bell-labs.com (Postfix) with ESMTP id 9F6C444339 for ; Wed, 11 Oct 2000 15:57:17 -0400 (EDT) Received: from itmail-ict1.wichita.brite.com (itmail-ict1.wichita.brite.com [151.214.5.174]) by ivigate.intervoice.com (Build 98 8.9.3/NT-8.9.3) with ESMTP id PAA20031; Wed, 11 Oct 2000 15:58:50 -0500 Received: by itmail-ict1-imc.wichita.brite.com with Internet Mail Service (5.5.2448.0) id ; Wed, 11 Oct 2000 15:52:51 -0500 Message-ID: From: "Culpepper, Bert" To: stleavy@cisco.com, byerly@cisco.com, jryang@cisco.com Cc: SIP List MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] draft-levy-sip-diversion-00.txt Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 11 Oct 2000 15:52:50 -0500 Hi, Some comments on your draft. I believe the following are typos. 7.1.4: Invite from P1->B should be INV Bob@B not INV Carol@B 7.3.2 Invite from A->C should be INVITE Carol@C not INVITE Bob@C, also should be Diversion: Bob@B not Diversion: Carol@B 7.5.2 The 180 response is shown from D->C shouldn't it be from C->P2? 9.1 [9] Message desc. is SIP UAC to SIP proxy server 1, should be SIP UAC to SIP UAS1 9.1 In the Alice calls for roses call flow message descriptions 6, 7, & 8 also don't match your MSC. ACK is not shown on MSC. These are minor, or I'm not understanding something and maybe a better explanation is needed in the ID :-) When reading 9.2 and looking at the MSC I thought the voicemail had enough information to identify the correct mailbox (from the To header) if the UAC only replaced the Request-URI with the Contact and left the To header unchanged. This seems like proper SIP behavior. After reading the message contents I see that is the case in your example. However, SIP today does not provide the redirecting reason, which I assume is part of your motivation for this new header. I will be interested to see how this proposal is received since it can enhance a SIP application's functionality and addresses an area of PSTN-IP interworking not otherwise covered by existing work. Regards, Bert _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 11 17:40:16 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA22435 for ; Wed, 11 Oct 2000 17:40:08 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 982EA44400; Wed, 11 Oct 2000 16:40:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by lists.bell-labs.com (Postfix) with SMTP id 99AE644339 for ; Wed, 11 Oct 2000 16:39:11 -0400 (EDT) Received: from 157.54.9.104 by mail2.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 11 Oct 2000 14:23:02 -0700 (Pacific Daylight Time) Received: by INET-IMC-02 with Internet Mail Service (5.5.2651.58) id <4W0ALMPH>; Wed, 11 Oct 2000 14:23:02 -0700 Message-ID: From: Christian Huitema To: "'Emami-Nouri, Mohsen'" , "'Frederic Huve'" , Michel Eilat Cc: SIPbell-labs Subject: RE: [SIP] Phone number in SIP X-Mailer: Internet Mail Service (5.5.2651.58) Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 11 Oct 2000 14:23:12 -0700 Actually, TRIP solves a different problem, that of finding the adequate gateway to reach a phone number from the Internet. In the example, we would first use ENUM or a local DB to try to find a sip URL that corresponds to the phone number; if there is none, we would use TRIP to find an adequate gateway. > -----Original Message----- > From: Emami-Nouri, Mohsen [mailto:memami@nuera.com] > Sent: Wednesday, October 11, 2000 1:54 PM > To: Christian Huitema; 'Frederic Huve'; Michel Eilat > Cc: SIPbell-labs > Subject: RE: [SIP] Phone number in SIP > > > I think TRIP is the other possibility. It is not as elegant > as ENUM, but it > addresses the routing information update well. > > -----Original Message----- > From: Christian Huitema [mailto:huitema@microsoft.com] > Sent: Wednesday, October 11, 2000 11:07 AM > To: 'Frederic Huve'; Michel Eilat > Cc: SIPbell-labs > Subject: RE: [SIP] Phone number in SIP > > > Assume that the gateway receiving the call learns the dialed > number, e.g. > through caller-id, through ISDN signalling, or through SS7. > There are at > least two ways to perform the translation between this phone > nuber and a > destination address: you can either use ENUM, and look for a > mapping from > the dialed number to the sip service, or you can use a local database, > somehow managed by the gateway (or by the call agent that controls the > gateway.) The local database makes a lot of sense, since > there must be some > relation between the called number and the gateway service, > otherwise the > call would not be routed to the gateway in the first place. The local > database could indeed use the ENUM technology. > > If the gateway is reached through a generic number, or > through a service > selection procedure such as the "10xxx" prefixes in the US, > then using ENUM > makes a lot of sense. > > -- Christian Huitema > > > -----Original Message----- > > From: Frederic Huve [mailto:fred@mylos.grenoble.hp.com] > > Sent: Wednesday, October 11, 2000 8:45 AM > > To: Michel Eilat > > Cc: SIPbell-labs > > Subject: Re: [SIP] Phone number in SIP > > > > > > Michel, > > > > I think that you're missing a point, a SIP proxy have to take > > place between > > the PSTN-SIP GW and the SIP end point, this SIP proxy via > > some location logic > > translates the E164 to the SIP URL. > > see draft-johnston-sip-call-flows-00.txt (especially section 5). > > > > Fred. > > > > Michel Eilat wrote: > > > > > Hello all, > > > > > > Let's imagine that a call need to be made from a POTS > > telephone to a SIP > > > endpoint through a PSTN-SIP GW. From the POTS, one will > > dial for example > > > 1234. How is the GW suppose to complete the SIP address > > form the phone > > > number. What procedure must the GW undergo ? > > > > > > Sorry if it is off interset - new to SIP > > > > > > Michel Eilat > > > > > > Audiocodes LTD > > > 4 Hahoresh St, > > > P.O.Box 14 Yehud 56470 > > > Israel > > > > > > Direct: +972-3-5394160 > > > Fax: +972-3-5394040 > > > Email: michel.eilat@audiocodes.com > > > Web Site: http://www.audiocodes.com > > > > > > _______________________________________________ > > > SIP mailing list > > > SIP@lists.bell-labs.com > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > -- > > Frederic HUVE 5,Avenue Raymond > Chanas - Eybens > > R&D Engineer 38053 Grenoble Cedex > 9 - FRANCE > > Telecom Infrastructure Division Tel +33 (0)4 76 14 47 43 > > Hewlett-Packard Fax +33 (0)4 76 14 14 88 > > > > > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 11 18:19:36 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA22966 for ; Wed, 11 Oct 2000 18:19:34 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E4876443F6; Wed, 11 Oct 2000 17:19:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from hotmail.com (f297.law7.hotmail.com [216.33.236.175]) by lists.bell-labs.com (Postfix) with ESMTP id 9A08944339 for ; Wed, 11 Oct 2000 17:18:00 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 11 Oct 2000 15:17:56 -0700 Received: from 216.162.75.80 by lw7fd.law7.hotmail.msn.com with HTTP; Wed, 11 Oct 2000 22:17:56 GMT X-Originating-IP: [216.162.75.80] Reply-To: egoine@iname.com From: "Mathieu Gervais" To: sip@lists.bell-labs.com Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 11 Oct 2000 22:17:56.0209 (UTC) FILETIME=[1B17A610:01C033D1] Subject: [SIP] Call redirected (302) to more expensive destination. Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 11 Oct 2000 18:17:56 EDT Hi, Scenario : Caller A calls Callee B, but B User Agent redirects, with a 302, Caller A to another destination which is (way) more expensive for A. Because 302 is handled kind of automatically, the user A is not really asked if he still wants to try to reach B (at higher cost). (Someone that doesn't want to talk to you could easily redirect all your calls to an expensive destination, or something like that) Does this scenario makes sense? If yes, what do people think about this problem? I guess that the user agent of A can inform him where it is getting redirected, and give him a little delay to cancel the call before doing automatic redirection, but what if A does not look at the "screen", or just does not have an idea that it's going to be a more expensive address to contact? thanks, Mathieu _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. Share information about yourself, create your own public profile at http://profiles.msn.com. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 11 19:19:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA23611 for ; Wed, 11 Oct 2000 19:19:05 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id EEB624433A; Wed, 11 Oct 2000 18:19:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from aphrodite.systems.cfer.com (me.voyanttech.com [63.89.131.5]) by lists.bell-labs.com (Postfix) with ESMTP id 39C9F44339 for ; Wed, 11 Oct 2000 18:18:48 -0400 (EDT) Received: from voyanttech.com (dough-pc.voyanttech.com [192.168.58.41]) by aphrodite.systems.cfer.com (8.8.8+Sun/8.8.8) with ESMTP id RAA25742; Wed, 11 Oct 2000 17:17:17 -0600 (MDT) Message-ID: <39E4F64D.310EEEB@voyanttech.com> From: Doug Harbert X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: "'Aparna.Vemuri@Level3.com'" , "'sip@lists.bell-labs.com'" Subject: Re: [SIP] Conferencing References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 11 Oct 2000 17:22:53 -0600 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > In the dial-up conference model, the request URI is really the only usable > identifier that can describe the conference. > > Think of it as exactly the way conferences work in the PSTN; you dial a > number plus a passcode (whcih is just an extension of the number, needed > because of the limited number of phone numbers available), and that number > represents the conference. Same here. A conferencing server should mix > together everyone who calls the same request URI; that would be the nature > of the resource defined by the collection of URIs on the conference server. > As an example, a conference server might define: > > *-adhoc@conferences.com > > where * is anything, to represent ad-hoc conferences which don't even need > to be pre-established. > > Junyoung writes: > > I know request-URI may be changed by proxies. > > So, How changable field can be used as ID? > > And, I think, SIP is not necessary to support multi-unicast > > call itself. > > It overburden SIP. I like SIP for its simplicity. > > I use origin of SDP for conference ID. > > Request URIs are not changed arbitrarily. They are changed in order to > properly route the request to the identifed resource. Such translations may > be needed even for conferences. Here's an example. Lets say you have a > conference service, conferences.com. It hosts two servers, one for ad-hoc > conferences, and another for pre-established conferences. WHen a call > arrives at the conferences.com proxy, it examines the user part of the > request URI. If its foo-adhoc, it gets translated to > foo-adhoc@adhocserver.conferences.com, and proxied there. If its just some > pre-arranged conference, conference21@conferences.com, that might get > proxied to conference21@mainserver.conferences.com. Each of those servers is > then configured to accept calls only for *-adhoc@adhocserver.conferences.com > in the first case, and *@mainserver.conferences.com in the second. > > As another example, lets say I'm supposed to be in a conference call with > Joe at 10am. I've forgotten the conference ID (i.e., the request URI), so I > call joe. Joe has a CPL configured that if I call him during the conference, > it proxies the request to the conference ID. Thus, the call will be > forwarded there and I get dropped right into the conference with Joe. This > service would not be possible if the request URI were not used as the > conference ID. > > Whenever you want to access a service associated with some server on the > network, and that server acts as a user agent (examples include IVR servers, > media servers, conferencing servers, translation servers, etc.), using the > request URI as the service identifier is an absolute MUST. This is exactly > what the definition of the request URI is, and it has the really important > advantage of turning a variety of service access problems into *routing* > problems. Thats why I can write a CPL to drop someone into a conference when > they call at a certain time; using the request URI as the conference > identifier makes it into a routing problem, which is within the domain of > CPL. > > I have an I-D pending that puts this all together and explains how this > model of accessing certain services through defined patterns on the request > URI has huge advantages. Should be out in a few weeks. > > -Jonathan R. > > --- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > > -----Original Message----- > > From: Aparna.Vemuri@Level3.com [mailto:Aparna.Vemuri@Level3.com] > > Sent: Wednesday, October 11, 2000 12:46 AM > > To: sip@lists.bell-labs.com > > Subject: [SIP] Conferencing > > > > > > Hello. > > I have a question about SIP-based conferencing. Let us assume > > the existence > > of a SIP UA that performs conferencing. SIP UAs that want to join a > > conference send SIP INVITEs to the conference server to > > conference them in, > > i.e. for an n-party conference, the CS will receive n > > INVITEs. I believe > > there has to be a need for corrolation and disambiguation of > > the different > > call-legs at the conference server. For a dial-in conference > > such as this, I > > think the easiest (and the most intuitive) way to corrolate > > all these n > > INVITEs (that have different Call-IDs) is via the dialed number/ > > conference-ID (i.e. the "To" field). > > > > However, if all these different call-legs were initiated by a > > third-party > > entity (called the controller) that sent these INVITEs on > > behalf of the > > actual participants, how should the corrolation and disambiguation of > > call-legs be performed at the conference server? > > > > I think there are two options: > > a) Same as before. Have each one of the INVITEs have > > different Call-IDs and > > have the conferencing SIP UA corrolate them based on the "To" field. > > This requires the controller to have a mechanism to corrolate > > all these > > call-legs at its end. > > > > b) Mandate that all the call-legs share the same Call-ID. The > > 'From' field > > in each INVITE sent to the CS (from the controller) must > > then be tagged. > > The CS could use the Call-ID to corrolate all these call-legs > > and the tag in > > the From to help distinguish one from the other. > > > > Is there a reason to prefer one over the other? Is there a > > third option that > > I have missed? Is there a preferred/ accepted mechanism to > > accomplish this > > and is this documented somewhere? > > > > Thanks, > > Aparna > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip Jonathan: How would a SIP Conference server register with an inbound proxy to accept such adhoc calls "*-adhoc@conferences.com"? As I understand the registration process, the conference server would issue a Register with From and To headers representing some name at the proxy address, and a Contact which specifies some name at the conference servers address. A call comes into the inbound proxy, and is sent to the URI found in the Contact. The name in this URI is FIXED and so it cannot be used to reference a previously unknown conference. What I would like to be able to do is to receive Invites with a URI like: SIP:JohnSmith@conferences.com. All calls arriving with this URI would go into the adhoc conference "JohnSmith". I don't necessarily want to know about John Smith ahead of time. One idea I had was to register with the proxy as adhoc@conferences.com, and then expect to see an Invite with a URI like: SIP:adhoc:JohnSmith@conference.com, using the password field of the URI to specify the actual conference name. Is this an appropriate use of this field? Are there any other ways that I can get this information? Thanks Doug Harbert. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 11 19:25:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA23720 for ; Wed, 11 Oct 2000 19:25:03 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C65BF4433A; Wed, 11 Oct 2000 18:25:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 9F73844339 for ; Wed, 11 Oct 2000 18:24:39 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id TAA29276; Wed, 11 Oct 2000 19:24:42 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <4WS2XJLS>; Wed, 11 Oct 2000 19:18:57 -0400 Message-ID: From: Jonathan Rosenberg To: "'Doug Harbert'" , Jonathan Rosenberg Cc: "'Aparna.Vemuri@Level3.com'" , "'sip@lists.bell-labs.com'" Subject: RE: [SIP] Conferencing MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 11 Oct 2000 19:18:57 -0400 > -----Original Message----- > From: Doug Harbert [mailto:dough@voyanttech.com] > Sent: Wednesday, October 11, 2000 7:23 PM > To: Jonathan Rosenberg > Cc: 'Aparna.Vemuri@Level3.com'; 'sip@lists.bell-labs.com' > Subject: Re: [SIP] Conferencing > > > Jonathan: > How would a SIP Conference server register with an inbound > proxy to accept > such adhoc calls "*-adhoc@conferences.com"? Why would it? REGISTER is not the solution to the worlds problems. It solves one specific case of dynamic address bindings, typically for end systems. Thats it. It most definitely does not solve this problem. Most other routing needs to be configured based on the architecture of your network, or through a more powerful inter and intra-domain routing protocol (i.e., TRIP). Even with such routing protocols, there still needs to be configuration at the edges and in the policy in the servers about which routes to accept. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 11 19:32:33 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA23872 for ; Wed, 11 Oct 2000 19:32:31 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id ED07E4433A; Wed, 11 Oct 2000 18:32:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 9A17744339 for ; Wed, 11 Oct 2000 18:31:13 -0400 (EDT) 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 TAA24465; Wed, 11 Oct 2000 19:27:11 -0400 (EDT) Message-ID: <39E4F750.FA630A96@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Doug Harbert Cc: Jonathan Rosenberg , "'Aparna.Vemuri@Level3.com'" , "'sip@lists.bell-labs.com'" Subject: Re: [SIP] Conferencing References: <39E4F64D.310EEEB@voyanttech.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 11 Oct 2000 19:27:12 -0400 Content-Transfer-Encoding: 7bit If you're willing to have something like foo@conferences.company.com, the company.com server just forwards everything for @conferences.example.com to the conference server. A normal proxy server should do this automatically, even if you need to do some internal/external DNS acrobatics. (Normally, calls for foo@conferences.company.com would never see the company.com proxy server.) Note that not every call *has* to go through a proxy server. This is only a problem if the conference server and regular users share the same name space, which is probably not a particularly good idea if you want to avoid somebody registering the conferencing dough@voyanttech.com and all your calls going to the conference server. You could restrict names in various ways (e.g., no user can have names with adhoc-*), but it seems preferable to do hierachical naming that expresses this intent much cleaner. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 11 19:40:17 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA23990 for ; Wed, 11 Oct 2000 19:40:17 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 392E14433A; Wed, 11 Oct 2000 18:40:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from aphrodite.systems.cfer.com (me.voyanttech.com [63.89.131.5]) by lists.bell-labs.com (Postfix) with ESMTP id 91E3D44339 for ; Wed, 11 Oct 2000 18:39:21 -0400 (EDT) Received: from voyanttech.com (dough-pc.voyanttech.com [192.168.58.41]) by aphrodite.systems.cfer.com (8.8.8+Sun/8.8.8) with ESMTP id RAA02616; Wed, 11 Oct 2000 17:38:04 -0600 (MDT) Message-ID: <39E4FB2C.B6297B65@voyanttech.com> From: Doug Harbert X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: Aparna.Vemuri@level3.com Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Conferencing References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 11 Oct 2000 17:43:40 -0600 Content-Transfer-Encoding: 7bit Aparna.Vemuri@level3.com wrote: > Doug, > Pl. see my comments below. > -Aparna > > -----Original Message----- > From: Doug Harbert [ mailto:dough@voyanttech.com > ] > Sent: Wednesday, October 11, 2000 10:54 AM > To: Vemuri, Aparna > Cc: sip@lists.bell-labs.com > Subject: Re: [SIP] Conferencing > > Aparna.Vemuri@level3.com wrote: > > > Hello. > > I have a question about SIP-based conferencing. Let us assume the > existence > > of a SIP UA that performs conferencing. SIP UAs that want to join a > > conference send SIP INVITEs to the conference server to conference them > in, > > i.e. for an n-party conference, the CS will receive n INVITEs. I believe > > there has to be a need for corrolation and disambiguation of the > different > > call-legs at the conference server. For a dial-in conference such as this, > I > > think the easiest (and the most intuitive) way to corrolate all these n > > INVITEs (that have different Call-IDs) is via the dialed number/ > > conference-ID (i.e. the "To" field). > > > > However, if all these different call-legs were initiated by a third-party > > entity (called the controller) that sent these INVITEs on behalf of the > > actual participants, how should the corrolation and disambiguation of > > call-legs be performed at the conference server? > > > > I think there are two options: > > a) Same as before. Have each one of the INVITEs have different Call-IDs > and > > have the conferencing SIP UA corrolate them based on the "To" field. > > This requires the controller to have a mechanism to corrolate all these > > call-legs at its end. > > > > b) Mandate that all the call-legs share the same Call-ID. The 'From' field > > in each INVITE sent to the CS (from the controller) must then be tagged. > > The CS could use the Call-ID to corrolate all these call-legs and the tag > in > > the From to help distinguish one from the other. > > > > Is there a reason to prefer one over the other? Is there a third option > that > > I have missed? Is there a preferred/ accepted mechanism to accomplish this > > and is this documented somewhere? > > > > Thanks, > > Aparna > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > > Aparna: > In either case, the conference controller must have some mechanism to > correlate all of these calls and place them into the appropriate conference. > > In my opinion, supplying the conference identification in the request > URI > provides more flexibility for the SIP conference UA, and for the conference > participants. I don't know how much control the third party conference > controller assumes here, but participants may wish to access the conference > via > other means, for example, using the web to monitor the conference and dial > out > additional participants. It seems more intuitive to specify the name of the > conference rather than a Call-ID and tag. > > The question that I have regarding the model in which all calls in a > conference have the same Call-ID but are distinguished by tags on the FROM > header is this: How do I know whether an INVITE represents a new call, or is > simply an existing call which was forked by some proxy? > > Aparna says: > 1. A call-leg is defined by a combination of the Call-ID, the To and the > >From (including any tags). The process for determining whether a request is > new or not involves a three step process described in section 11.5 of the > spec (and I believe it involves a comparison of the To and the From > (including the tags) and the Call-ID.) My understanding is that a mismatch > in the To and the From (tags included) should be interpreted as a new > call-leg. > > 2. The tag in the From MUST be present when there are two instances of a > user sharing a SIP address making call invitations with the same Call-ID. > Our case is similar to this in that the controller issues INVITEs on behalf > of all the participants. > > 3. The proxy copies the To, From, Call-ID and Contact tags from the original > request. The proxy does not modify the tags in any way. It adds a branch > parameter to the Via field. > Aparna Aparna: I think I see what you are saying. I was confused by this statement in the draft-ietf-sip-rfc2543bis-01 document in section 6.24 From. "The distinction between call and call leg matters in calls with multiple responses to a forked request". As long as the tags are generated by the UA originating the calls, and not modified by intermediat proxies, then a unique combination of Call-Id, To and From headers will uniquely identify a call leg. Thanks Doug Harbert _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 11 20:06:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA24556 for ; Wed, 11 Oct 2000 20:06:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C3D56443FF; Wed, 11 Oct 2000 19:06:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mailsrv02.multitude.com (mailsrv02.firetalk.com [204.178.116.251]) by lists.bell-labs.com (Postfix) with ESMTP id 77FFC44339 for ; Wed, 11 Oct 2000 19:05:03 -0400 (EDT) Received: from sbarber2k (s242.firetalk.com [204.178.116.242]) by mailsrv02.multitude.com (Rockliffe SMTPRA 3.4.2) with SMTP id ; Wed, 11 Oct 2000 17:02:51 -0700 From: "Simon Barber" To: , Subject: RE: [SIP] From header to ISUP CgPN mapping Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_000E_01C033A5.9FC5E1A0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 11 Oct 2000 17:06:40 -0700 This is a multi-part message in MIME format. ------=_NextPart_000_000E_01C033A5.9FC5E1A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit This scenario is an excellent example of why we might want to allow multiple From: headers, just as RFC822 allows for e-mail. A user could include both his sip address, and a tel: url as from headers. Why are multiple From: lines not allowed in SIP, and where would it cause problems? (to allow backwards compatability we could specify an Also-From: header for multiple entries). equally why are multiple To: lines not allowed - so users can see that several people were invited to a particular call? currently it is possible to invite several people separately, invite a group list (group@domain), but not possible, like with e-mail, to invite several people and have them all see who else was invited. Proposed: An Also-To: header and an Also-From: header. These are intended for display by the final UA, and possibly used to direct a reply call - just like e-mail. Simon Barber > -----Original Message----- > From: sip-admin@lists.bell-labs.com > [mailto:sip-admin@lists.bell-labs.com]On Behalf Of clive.dellard@bt.com > Sent: Wednesday, October 11, 2000 9:17 AM > To: sip@lists.bell-labs.com > Subject: [SIP] From header to ISUP CgPN mapping > > > In the call flows document draft-ietf-sip-call-flows-01.txt, scenario 4.1.1, > the message detail and text show User A using a SIP telephone number rather > than a SIP address in the From header. The text at the beginning of section > 4 also says "that User A still uses his/her SIP URL in the Contact header, > since the call could be redirected back to the SIP network." > This implies that User A has pre-knowledge that the call is going to route > to the PSTN and has the ability to chose the address to be used in the From > header. This is maybe reasonable when calling a telephone number but what if > User A makes a call to a SIP address and the called user has say forwarded > their calls to a telephone number. If User A used a SIP address in the From > header there would be no calling telephone number available when the call > hits a gateway. > Is there some way in which both the calling SIP address and SIP telephone > number can be carried in an INVITE so that a Gateway (or even a Proxy?) > could choose the appropriate calling identity to use? > > Regards, > > Clive Dellard > 3G Networks > > BTexaCT > > > > * PP 2C59, Angel Centre, > 403 St. John Street, > LONDON, EC1V 4PL. > > * Office +44 20 7843 7084 > > * Mobile +44 7711 045507 > * +44 20 7843 6557 > mailto:clive.dellard@bt.com > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > ------=_NextPart_000_000E_01C033A5.9FC5E1A0 Content-Type: text/x-vcard; name="Simon Barber.vcf" Content-Disposition: attachment; filename="Simon Barber.vcf" Content-Transfer-Encoding: quoted-printable BEGIN:VCARD VERSION:2.1 N:Barber;Simon FN:Simon Barber ORG:Firetalk Communications, Inc. TEL;WORK;VOICE:(650) 636-1924 TEL;CELL;VOICE:(650) 743-1919 ADR;WORK:;;5000 Shoreline Court, Suite 200;South San = Francisco;CA;94080;United States of America LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:5000 Shoreline Court, Suite = 200=3D0D=3D0ASouth San Francisco, CA 94080=3D0D=3D0AUnit=3D ed States of America URL:http://www.firetalk.com URL:http://www.firetalk.com EMAIL;PREF;INTERNET:simon@firetalk.com REV:20000914T193921Z END:VCARD ------=_NextPart_000_000E_01C033A5.9FC5E1A0-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 11 21:48:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA26650 for ; Wed, 11 Oct 2000 21:48:05 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 424A34433A; Wed, 11 Oct 2000 20:48:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sj_exchange.sj.nuera.com (h-207-20-110-62.ncal.verio.net [207.20.110.62]) by lists.bell-labs.com (Postfix) with ESMTP id 0F0ED44339 for ; Wed, 11 Oct 2000 20:47:03 -0400 (EDT) Received: by exchange.sj.nuera.com with Internet Mail Service (5.5.2650.21) id <4C7KR300>; Wed, 11 Oct 2000 18:46:59 -0700 Message-ID: <350860CC5B2AD311991D0008C7F7EEAAA02653@exchange.sj.nuera.com> From: "Emami-Nouri, Mohsen" To: "'Christian Huitema'" , "Emami-Nouri, Mohsen" , "'Frederic Huve'" , Michel Eilat Cc: SIPbell-labs Subject: RE: [SIP] Phone number in SIP MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 11 Oct 2000 18:46:57 -0700 -----Original Message----- From: Christian Huitema [mailto:huitema@microsoft.com] Sent: Wednesday, October 11, 2000 2:23 PM To: 'Emami-Nouri, Mohsen'; 'Frederic Huve'; Michel Eilat Cc: SIPbell-labs Subject: RE: [SIP] Phone number in SIP Actually, TRIP solves a different problem, that of finding the adequate gateway to reach a phone number from the Internet. In the example, we would first use ENUM or a local DB to try to find a sip URL that corresponds to the phone number; when we find an URL by using ENUM, the found URL could be a gateway's one. why TRIP is to find gateways and ENUM to find UA (?) if there is none, we would use TRIP to find an adequate gateway. > -----Original Message----- > From: Emami-Nouri, Mohsen [mailto:memami@nuera.com] > Sent: Wednesday, October 11, 2000 1:54 PM > To: Christian Huitema; 'Frederic Huve'; Michel Eilat > Cc: SIPbell-labs > Subject: RE: [SIP] Phone number in SIP > > > I think TRIP is the other possibility. It is not as elegant > as ENUM, but it > addresses the routing information update well. > > -----Original Message----- > From: Christian Huitema [mailto:huitema@microsoft.com] > Sent: Wednesday, October 11, 2000 11:07 AM > To: 'Frederic Huve'; Michel Eilat > Cc: SIPbell-labs > Subject: RE: [SIP] Phone number in SIP > > > Assume that the gateway receiving the call learns the dialed > number, e.g. > through caller-id, through ISDN signalling, or through SS7. > There are at > least two ways to perform the translation between this phone > nuber and a > destination address: you can either use ENUM, and look for a > mapping from > the dialed number to the sip service, or you can use a local database, > somehow managed by the gateway (or by the call agent that controls the > gateway.) The local database makes a lot of sense, since > there must be some > relation between the called number and the gateway service, > otherwise the > call would not be routed to the gateway in the first place. The local > database could indeed use the ENUM technology. > > If the gateway is reached through a generic number, or > through a service > selection procedure such as the "10xxx" prefixes in the US, > then using ENUM > makes a lot of sense. > > -- Christian Huitema > > > -----Original Message----- > > From: Frederic Huve [mailto:fred@mylos.grenoble.hp.com] > > Sent: Wednesday, October 11, 2000 8:45 AM > > To: Michel Eilat > > Cc: SIPbell-labs > > Subject: Re: [SIP] Phone number in SIP > > > > > > Michel, > > > > I think that you're missing a point, a SIP proxy have to take > > place between > > the PSTN-SIP GW and the SIP end point, this SIP proxy via > > some location logic > > translates the E164 to the SIP URL. > > see draft-johnston-sip-call-flows-00.txt (especially section 5). > > > > Fred. > > > > Michel Eilat wrote: > > > > > Hello all, > > > > > > Let's imagine that a call need to be made from a POTS > > telephone to a SIP > > > endpoint through a PSTN-SIP GW. From the POTS, one will > > dial for example > > > 1234. How is the GW suppose to complete the SIP address > > form the phone > > > number. What procedure must the GW undergo ? > > > > > > Sorry if it is off interset - new to SIP > > > > > > Michel Eilat > > > > > > Audiocodes LTD > > > 4 Hahoresh St, > > > P.O.Box 14 Yehud 56470 > > > Israel > > > > > > Direct: +972-3-5394160 > > > Fax: +972-3-5394040 > > > Email: michel.eilat@audiocodes.com > > > Web Site: http://www.audiocodes.com > > > > > > _______________________________________________ > > > SIP mailing list > > > SIP@lists.bell-labs.com > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > -- > > Frederic HUVE 5,Avenue Raymond > Chanas - Eybens > > R&D Engineer 38053 Grenoble Cedex > 9 - FRANCE > > Telecom Infrastructure Division Tel +33 (0)4 76 14 47 43 > > Hewlett-Packard Fax +33 (0)4 76 14 14 88 > > > > > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 11 22:32:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA28112 for ; Wed, 11 Oct 2000 22:32:00 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2C2B24433A; Wed, 11 Oct 2000 21:32:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from dnspri.npac.com (dnspri.npac.com [208.143.33.66]) by lists.bell-labs.com (Postfix) with ESMTP id 44EF444339 for ; Wed, 11 Oct 2000 21:31:43 -0400 (EDT) Received: by dnspri.npac.com; id VAA12185; Wed, 11 Oct 2000 21:31:39 -0500 (CDT) Received: from unknown(208.143.39.132) by dnspri.npac.com via smap (V5.0) id xma012179; Wed, 11 Oct 00 21:31:24 -0500 Received: by chi02.npac.com with Internet Mail Service (5.5.2650.21) id ; Wed, 11 Oct 2000 21:30:03 -0500 Message-ID: From: James Yu To: "'Bobby Sardana'" Cc: SIPbell-labs Subject: RE: [SIP] Phone number in SIP MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 11 Oct 2000 21:27:49 -0500 ENUM offers a generic process that maps an E.164 number to a list of NAPTR RRs (URLs). The use of ENUM for each application must be defined for each application (e.g., SIP and voice messaging). James > -----Original Message----- > From: Bobby Sardana [mailto:bobby.sardana@mobilerain.com] > Sent: Wednesday, October 11, 2000 4:11 PM > To: Jean-Francois Mule > Cc: James Yu; Michel Eilat; SIPbell-labs; 'Frederic Huve' > Subject: Re: [SIP] Phone number in SIP > > > Greetings: > > An I-D: > > http://www.ietf.org/internet-drafts/draft-lind-enum-callflows-00.txt > > does describe the use of ENUM and SIP. I was wondering what > the new I-D, as > mentioned by James Yu, will reflect? > > Regards, > > Bobby.Sardana@mobilerain.com > > Jean-Francois Mule wrote: > > > The second method combining James & Christian' suggestions > is more elegant: > > pstn-sip gw --> PROXY: use of ENUM or any other location > services like LDAP > > directory, look-up in local DB to translate abbreviated > number into a > > "routable" one. > > > > Jean-Francois. > > > > James Yu wrote: > > > -----Original Message----- > > > From: James Yu [mailto:james.yu@neustar.com] > > ... snip > > > I'll mention one possibility - use ENUM (Telephone Number > > > Mapping: phone > > > number in ... URL out). The GW can initiate the ENUM > > > process to retrieve > > > all the NAPTR RRs associated with that phone number and > > > selects the SIP > > > URL(s) to route the call, or the GW can route the call to > a SIP proxy > > > server, which then initiates the ENUM process. An I-D on how > > > to use ENUM to > > > support SIP services will be out soon. > > > > > > James > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 11 22:44:00 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA28529 for ; Wed, 11 Oct 2000 22:44:00 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C594F44410; Wed, 11 Oct 2000 21:44:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 9B56C44339 for ; Wed, 11 Oct 2000 21:43:52 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id WAA00254; Wed, 11 Oct 2000 22:45:43 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <4WS2XJRV>; Wed, 11 Oct 2000 22:39:58 -0400 Message-ID: From: Jonathan Rosenberg To: "'zeeshan razzaque'" , "'sip@lists.bell-labs.com'" Cc: Jonathan Rosenberg Subject: RE: [SIP] Gateway Question MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 11 Oct 2000 22:39:57 -0400 > -----Original Message----- > From: zeeshan razzaque [mailto:zrazzaque@yahoo.com] > Sent: Tuesday, October 10, 2000 8:29 AM > To: sip@lists.bell-labs.com > Cc: jdrosen@dynamicsoft.com > Subject: [SIP] Gateway Question > > > Hi, > Well I continue from where I left. I asked how the > Gateways register themselves and I was told to use > TRIP instead of REGISTER. What is the current status > of TRIP. Who sponsors it and is it widely enough used? TRIP itself is nearly complete. There are a few implementations. However, the subject here is TRIP-GW. This is just a proposal at this point. > What is the method 'in vogue' for SIP Gateway > Registration? Right now it is being done through static configuration of routes in proxies. > > Secondly, if my Gateway has a concurrent capacity of > say a 100 connections, does it register 100 different > UAs for that? Or is there any other SIP support for > it? There is no register. Thats the point. TRIP-GW does this differently. > > Now the default port for SIP listener is 5060. If the > gateway spawns a 100 or more(or less for that matter) > UAs, when INVITES arrive at the Gateway, is the > gateway supposed to send 200 OK and put the UA SIP URL > in the CONTACT header or does it send a 300 REDIRECT > response. In other words should it act as a big > brother or the Redirect Server. Is it mandated by SIP > in nay way or is it an implementation detail not > handled by SIP? You seem to have some model that there is a separate UA process for each port on a gateway. This is not how it generally works. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 11 22:49:14 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA28549 for ; Wed, 11 Oct 2000 22:49:13 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2252B4441E; Wed, 11 Oct 2000 21:49:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id BA8EC44339 for ; Wed, 11 Oct 2000 21:48:00 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id WAA00267; Wed, 11 Oct 2000 22:50:02 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <4WS2XJRY>; Wed, 11 Oct 2000 22:44:17 -0400 Message-ID: From: Jonathan Rosenberg To: "'Gonzalo Camarillo'" , Jonathan Rosenberg Cc: "'sip'" Subject: RE: [SIP] Feedback on manyfolks MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 11 Oct 2000 22:44:16 -0400 Its just thats its more options, more complexities ontop of a thing which is growing more and more complex. We need to remove options, not add them. I don't see what they need is for the negotiation. We need to justify the existence of it, not the elimination of it. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > Sent: Tuesday, October 10, 2000 10:46 AM > To: Jonathan Rosenberg > Cc: 'sip' > Subject: Re: [SIP] Feedback on manyfolks > > > Hi, > > Certainly we are not talking about tons of messages. However, in this > case I would rather let the confim be negotiated. The negotiation is > rather simple. > > The UAC can request: > 1) No COMET > 2) one COMET UAC->UAS > 3) one COMET UAC- 4) two COMETs > > The UAS should accept what the UAC requests, and possibly request more > (e.g. two COMETs when the UAC just requested one). > > I believe this is not a complicated mechanism. It is just a > deterministic two-way handshake. > > Best regards, > > Gonzalo > > > > Jonathan Rosenberg wrote: > > > > This seems reasonable to me, and needed, as Gonzalo points out. > > > > My only issue is whether all this stuff should be optional > at all. Wouldn't > > it be easier if both sides always sent COMET, period? All > this negotiation > > stuff is a pain. We're not talking tons of messages here. > Can't we keep it > > simple? > > > > -Jonathan R. > > > > --- > > Jonathan D. Rosenberg 72 Eagle Rock Ave. > > Chief Scientist First Floor > > dynamicsoft East Hanover, NJ 07936 > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > > http://www.dynamicsoft.com > > > > > -----Original Message----- > > > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > > Sent: Monday, October 09, 2000 2:33 AM > > > To: sip > > > Subject: [SIP] Feedback on manyfolks > > > > > > > > > Hi, > > > > > > Here you have a new I-D that contains feedback on the > manyfolks draft. > > > > > > http://search.ietf.org/internet-drafts/draft-camarillo-manyfol > > > ks-confirm-00.txt > > > > > > " > > > Abstract > > > > > > This document describes certain functionality that is > > > missing in the > > > current "Integration of Resource Management and SIP" > [1] (a.k.a. > > > manyfolks draft). An extension to add this functionality is > > > outlined. > > > > > > This functionality is needed in general to provide richer > > > signalling > > > capabilities and can be employed in several scenarios. > This draft > > > describes its use in third party call control applications. > > > > > > If this extension is accepted it is foreseen that this > draft would > > > be merged with [1]. > > > " > > > > > > Best regards, > > > > > > Gonzalo > > > -- > > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > > Telecom R&D Fax : +358 9 299 30 52 > > > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > > > Finland http://www.hut.fi/~gonzalo > > > > > > _______________________________________________ > > > SIP mailing list > > > SIP@lists.bell-labs.com > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > -- > Gonzalo Camarillo Phone : +358 9 299 33 71 > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > Telecom R&D Fax : +358 9 299 30 52 > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > Finland http://www.hut.fi/~gonzalo > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 11 22:55:46 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA28605 for ; Wed, 11 Oct 2000 22:55:46 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6677E44425; Wed, 11 Oct 2000 21:50:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id BEAD644339 for ; Wed, 11 Oct 2000 21:49:33 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id WAA00250; Wed, 11 Oct 2000 22:43:56 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <4WS2XJR4>; Wed, 11 Oct 2000 22:38:11 -0400 Message-ID: From: Jonathan Rosenberg To: "'Emami-Nouri, Mohsen'" , "'Christian Huitema'" , "'Frederic Huve'" , "'Michel Eilat'" Cc: "'SIPbell-labs'" Subject: RE: [SIP] Phone number in SIP MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 11 Oct 2000 22:38:10 -0400 > -----Original Message----- > From: Emami-Nouri, Mohsen [mailto:memami@nuera.com] > Sent: Wednesday, October 11, 2000 9:47 PM > To: 'Christian Huitema'; Emami-Nouri, Mohsen; 'Frederic Huve'; Michel > Eilat > Cc: SIPbell-labs > Subject: RE: [SIP] Phone number in SIP > > > > > -----Original Message----- > From: Christian Huitema [mailto:huitema@microsoft.com] > Sent: Wednesday, October 11, 2000 2:23 PM > To: 'Emami-Nouri, Mohsen'; 'Frederic Huve'; Michel Eilat > Cc: SIPbell-labs > Subject: RE: [SIP] Phone number in SIP > > > Actually, TRIP solves a different problem, that of finding > the adequate > gateway to reach a phone number from the Internet. In the > example, we would > first use ENUM or a local DB to try to find a sip URL that > corresponds to > the phone number; > > when we find an URL by using ENUM, the found URL could be a > gateway's one. > why TRIP is to find gateways and ENUM to find UA (?) Sigh. If only I had a dime for every time this issue has come up. The TRIP framework discusses this issue in some detail: http://www.ietf.org/rfc/rfc2871.txt Anyway, to summarize, enum is a worldwide global database. When you look up a number, you always get the same answer back. Routing to gateways is much more an issue of policy, with local inputs and rules that are different for each provider. Enum solves a NAME TO ADDRESS mapping problem, and TRIP solves an ADDRESS TO ROUTE problem. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 11 23:34:00 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA29206 for ; Wed, 11 Oct 2000 23:34:00 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E8E594433A; Wed, 11 Oct 2000 22:34:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mars.hss.co.in (unknown [202.54.26.197]) by lists.bell-labs.com (Postfix) with ESMTP id 4693C44339 for ; Wed, 11 Oct 2000 22:33:16 -0400 (EDT) Received: from sampark.hss.hns.com (sampark [139.85.229.22]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id e9C3XhC09492; Thu, 12 Oct 2000 09:03:44 +0530 (IST) Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 65256976.0013DDEB ; Thu, 12 Oct 2000 09:06:59 +0530 X-Lotus-FromDomain: HSSBLR From: archow@hss.hns.com To: egoine@iname.com Cc: sip@lists.bell-labs.com Message-ID: <65256976.0013DC07.00@sampark.hss.hns.com> Subject: Re: [SIP] Call redirected (302) to more expensive destination. Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 12 Oct 2000 09:06:54 +0530 I would say automatic call-redirection on a 302 response is something that the endclient can always decide to accept/reject. This seems to be an endpoint descision related issue - since the redirection comes back to him. Matheiu>(Someone that doesn't want to talk to you could easily redirect all your Matheiu> calls to an expensive destination, or something like that) In the case of 302, the client shouls decide in consultation with the user whether to reissue an INVITE to the new destination. That should be all. I doubt if should at all handle things like if the user missed seeing the address of the redirected call. Regds Arjun "Mathieu Gervais" on 10/12/2000 03:47:56 AM Please respond to egoine@iname.com To: sip@lists.bell-labs.com cc: Subject: [SIP] Call redirected (302) to more expensive destination. Hi, Scenario : Caller A calls Callee B, but B User Agent redirects, with a 302, Caller A to another destination which is (way) more expensive for A. Because 302 is handled kind of automatically, the user A is not really asked if he still wants to try to reach B (at higher cost). (Someone that doesn't want to talk to you could easily redirect all your calls to an expensive destination, or something like that) Does this scenario makes sense? If yes, what do people think about this problem? I guess that the user agent of A can inform him where it is getting redirected, and give him a little delay to cancel the call before doing automatic redirection, but what if A does not look at the "screen", or just does not have an idea that it's going to be a more expensive address to contact? thanks, Mathieu _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. Share information about yourself, create your own public profile at http://profiles.msn.com. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Oct 12 01:35:15 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA04266 for ; Thu, 12 Oct 2000 01:35:09 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D11344433A; Thu, 12 Oct 2000 00:35:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 9887F44339 for ; Thu, 12 Oct 2000 00:34:57 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA00698; Thu, 12 Oct 2000 01:36:56 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <4WS2XJ4B>; Thu, 12 Oct 2000 01:31:11 -0400 Message-ID: From: Jonathan Rosenberg To: "'Simon Barber'" , "'clive.dellard@bt.com'" , "'sip@lists.bell-labs.com'" Subject: RE: [SIP] From header to ISUP CgPN mapping MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 12 Oct 2000 01:31:09 -0400 > -----Original Message----- > From: Simon Barber [mailto:simon@firetalk.com] > Sent: Wednesday, October 11, 2000 8:07 PM > To: clive.dellard@bt.com; sip@lists.bell-labs.com > Subject: RE: [SIP] From header to ISUP CgPN mapping > > > This scenario is an excellent example of why we might want to > allow multiple From: > headers, just as RFC822 allows for e-mail. A user could > include both his sip address, > and a tel: url as from headers. I don't see why thats needed. In my previous posting on this thread I have explained why this is not a requirement for gateways at all. Even email doesn't have such a concept. > equally why are multiple To: lines not allowed - so users can > see that several people > were invited to a particular call? So we are talking about multiparty conferencing... thats a different issue. For centralized conferences using a bridge, you'll know through RTCP. For fully distributed, you'll know since you have a point to point signaling relationship with each. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Oct 12 01:41:42 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA05032 for ; Thu, 12 Oct 2000 01:41:39 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 378C14442C; Thu, 12 Oct 2000 00:39:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lists.bell-labs.com (Postfix) with ESMTP id 2C2674442C for ; Thu, 12 Oct 2000 00:38:00 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id e9C5bpZ04561; Thu, 12 Oct 2000 07:37:51 +0200 (MEST) Received: from lmf.ericsson.se (E005004B57CE1.lmf.ericsson.se [131.160.30.148]) by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id IAA21774; Thu, 12 Oct 2000 08:37:50 +0300 (EET DST) Message-ID: <39E54E1C.F7FA1120@lmf.ericsson.se> 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: Jonathan Rosenberg Cc: "'sip'" Subject: Re: [SIP] Feedback on manyfolks References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 12 Oct 2000 08:37:32 +0300 Content-Transfer-Encoding: 7bit Hi, I agree. This is getting pretty complex. Anyway, for this specific matter we have three choices: 1) COMET is always mandatory in both directions. It does not matter if the preconditions are mandatory or optional. 2) COMET is mandatory just when the preconditions are mandatory. 3) COMET is just sent when requested by any of the parties. This would be the mechanism used so far (with the extension defined in draft-camarillo-manyfolks-confirm-00.txt) Approach number 1 is the simplest. After doing whatever in order to fulfil the preconditions a COMET is sent. Number 2 is also pretty simple. If the preconditions were mandatory, the session is stopped until the COMET is sent. If the preconditions were optional the session establishment goes on, so no COMET is sent. The gain of approach number 3 is that it saves some messages. However, as you pointed out, they are not a lot. In the most common situation it would save 2 messages (1 RTT). This is when A calls B in a two-party session where there is just one COMET from A towards B. The COMET from B to A is not normally needed since B just begins alerting the user once the preconditions are met. So, we have a little more complexity for a little gain. My only concern is the amonut of signalling messages that we already have for establishing a session using preconditions (PRACKs, COMETs). A RTT for a workstation in an ethernet is not a big deal, but for a terminal using a cellular access begins to be more important. Anyway, I do not have a religious position here, so any of the 3 solutions is alright for me. Let's pick one and go on resolving different issues. Opinions? Regards, Gonzalo Jonathan Rosenberg wrote: > > Its just thats its more options, more complexities ontop of a thing which is > growing more and more complex. We need to remove options, not add them. I > don't see what they need is for the negotiation. We need to justify the > existence of it, not the elimination of it. > > -Jonathan R. > > --- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > > -----Original Message----- > > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > Sent: Tuesday, October 10, 2000 10:46 AM > > To: Jonathan Rosenberg > > Cc: 'sip' > > Subject: Re: [SIP] Feedback on manyfolks > > > > > > Hi, > > > > Certainly we are not talking about tons of messages. However, in this > > case I would rather let the confim be negotiated. The negotiation is > > rather simple. > > > > The UAC can request: > > 1) No COMET > > 2) one COMET UAC->UAS > > 3) one COMET UAC- > 4) two COMETs > > > > The UAS should accept what the UAC requests, and possibly request more > > (e.g. two COMETs when the UAC just requested one). > > > > I believe this is not a complicated mechanism. It is just a > > deterministic two-way handshake. > > > > Best regards, > > > > Gonzalo > > > > > > > > Jonathan Rosenberg wrote: > > > > > > This seems reasonable to me, and needed, as Gonzalo points out. > > > > > > My only issue is whether all this stuff should be optional > > at all. Wouldn't > > > it be easier if both sides always sent COMET, period? All > > this negotiation > > > stuff is a pain. We're not talking tons of messages here. > > Can't we keep it > > > simple? > > > > > > -Jonathan R. > > > > > > --- > > > Jonathan D. Rosenberg 72 Eagle Rock Ave. > > > Chief Scientist First Floor > > > dynamicsoft East Hanover, NJ 07936 > > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > > > http://www.dynamicsoft.com > > > > > > > -----Original Message----- > > > > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > > > Sent: Monday, October 09, 2000 2:33 AM > > > > To: sip > > > > Subject: [SIP] Feedback on manyfolks > > > > > > > > > > > > Hi, > > > > > > > > Here you have a new I-D that contains feedback on the > > manyfolks draft. > > > > > > > > http://search.ietf.org/internet-drafts/draft-camarillo-manyfol > > > > ks-confirm-00.txt > > > > > > > > " > > > > Abstract > > > > > > > > This document describes certain functionality that is > > > > missing in the > > > > current "Integration of Resource Management and SIP" > > [1] (a.k.a. > > > > manyfolks draft). An extension to add this functionality is > > > > outlined. > > > > > > > > This functionality is needed in general to provide richer > > > > signalling > > > > capabilities and can be employed in several scenarios. > > This draft > > > > describes its use in third party call control applications. > > > > > > > > If this extension is accepted it is foreseen that this > > draft would > > > > be merged with [1]. > > > > " > > > > > > > > Best regards, > > > > > > > > Gonzalo > > > > -- > > > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > > > Telecom R&D Fax : +358 9 299 30 52 > > > > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > > > > Finland http://www.hut.fi/~gonzalo > > > > > > > > _______________________________________________ > > > > SIP mailing list > > > > SIP@lists.bell-labs.com > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > -- > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > Telecom R&D Fax : +358 9 299 30 52 > > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > > Finland http://www.hut.fi/~gonzalo > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland http://www.hut.fi/~gonzalo _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Oct 12 01:50:28 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA06279 for ; Thu, 12 Oct 2000 01:50:28 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id EB10C44430; Thu, 12 Oct 2000 00:49:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 6DBB94442B for ; Thu, 12 Oct 2000 00:48:55 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA00747; Thu, 12 Oct 2000 01:50:54 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <4WS2XJ4L>; Thu, 12 Oct 2000 01:45:09 -0400 Message-ID: From: Jonathan Rosenberg To: "'egoine@iname.com'" , "'sip@lists.bell-labs.com'" Subject: RE: [SIP] Call redirected (302) to more expensive destination. MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 12 Oct 2000 01:45:08 -0400 > -----Original Message----- > From: Mathieu Gervais [mailto:egoine_@hotmail.com] > Sent: Wednesday, October 11, 2000 6:18 PM > To: sip@lists.bell-labs.com > Subject: [SIP] Call redirected (302) to more expensive destination. > > > Hi, > > Scenario : > > Caller A calls Callee B, but B User Agent redirects, with > a 302, Caller A > to another destination which is (way) more expensive for A. > Because 302 is > handled kind of automatically, the user A is not really asked > if he still > wants to try to reach B (at higher cost). > > (Someone that doesn't want to talk to you could easily > redirect all your > calls to an expensive destination, or something like that) > > Does this scenario makes sense? If yes, what do people think > about this > problem? Its only going to be a problem in cases where there is recursion; that is, where proxies in the network act on redirect responses and try the addresses listed in the Contact headers. When there is no recursion, the originating UA will see exactly where they have been redirected to, and so its no problem if the GUI can show such a thing. It could still be a problem for standalone phones with no UI, gateways, and other such PSTNish devices. The caller preferences spec: http://www.ietf.org/internet-drafts/draft-ietf-sip-callerprefs-02.txt has a way to allow an originating UA to request that there be no recursion: Request-Disposition: no-recurse which can help solve this problem to some degree. Its still an issue for UIs that can't show redirections. Such devices should probably consider redirects to phone numbers as call failures. Even that doesn't completely solve the problem, since there is nothing, in theory, that would prevent a proxy somewhere along the line from proxying a request to a destination that is some far away phone number. In practice, I doubt this would happen. Gateways don't just accept random calls, terminate them, and send a bill off to someone. Typically, termination services are arranged on a bilateral basis. This will require a proxy at the interface between them to do accouting and authorization. So, a call routed from a caller to domain A, which then forwards the call to a number in Zimbabwe, would be routed by domain A through this proxy and be counted amongst the calls billed to domain A. Serves as a good incentive not to do such bad things. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Oct 12 01:53:53 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA06654 for ; Thu, 12 Oct 2000 01:53:52 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0838444438; Thu, 12 Oct 2000 00:52:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lists.bell-labs.com (Postfix) with ESMTP id 12E0744437 for ; Thu, 12 Oct 2000 00:51:10 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id e9C5ojt24779; Thu, 12 Oct 2000 07:50:45 +0200 (MEST) Received: from lmf.ericsson.se (E005004B57CE1.lmf.ericsson.se [131.160.30.148]) by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id IAA22497; Thu, 12 Oct 2000 08:50:43 +0300 (EET DST) Message-ID: <39E55120.4C00165F@lmf.ericsson.se> 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: "Culpepper, Bert" , Rohan Mahy , Jonathan Rosenberg , sip@lists.bell-labs.com, Henning Schulzrinne , mmusic Subject: Re: [SIP] draft-camarillo-sip-sdp-00.txt References: <39E17C56.35D50F99@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 12 Oct 2000 08:50:24 +0300 Content-Transfer-Encoding: 7bit Hi, I already checked with the guys of the AVT WG and we reached some conclusions on this matter. The issue was what to do when RTP has to be sent to different ports based on the codec used at any moment. The conclusion is that two RTP streams will be used. Right below I attach a small review of the thread and one open issue regarding the fid attribute. Feedback is appreciated, ************ Hi, Henning Schulzrinne wrote: > > Gonzalo Camarillo wrote: > > > > > > > Yes, that is one of the concerns people have - RTCP. Anyway, this 3rd > > party developed RTP library is just one among many examples. There are > > other scenarios where this feature might be useful. For instance, when > > the DTMF tones have to be received in a different device than the voice. > > That is solvable in a far cleaner manner by having two voice sessions, > one for regular audio and one for DTMF. The same applies to other > scenarios. To the end system, this is just like mixing several sources. > Implementing this gets you mixing and conferencing for free, so this is > a Good Thing. I am happy with this solution. However, I would like to signal it properly to the other end. That is, I receive the following description (in an INVITE for instance). v=0 o=John 289085535 289085535 IN IP4 first.example.com t=0 0 c=IN IP4 111.111.111.111 m=audio 20000 RTP/AVP 0 m=audio 20002 RTP/AVP 8 This means that I will receive two media streams. The first one on port number 20000 will use PCM u-law. The second one will arrive on port number 20002 and will be using PCM A-law. Actually I might receive media from both media streams simultaneously. One of the media streams might contain the voice of the singer and the other the background (public, guitars, ...) of the concert. I would like to differentiate this case from the following one. Now I want to have a conversation with somebody. I want just to transmit my voice. However, sometimes I will use PCM u-law and others PCM A-law. The receiver wants to receive (due to any reason) different codecs on different port numbers. As we have discussed previously in this thread, we will establish two media streams. But I want the receiver to know that I will never transmit simultaneouly in both media streams. I will transmit using one OR the other. I would like my session description to look like: v=0 o=John 289085535 289085535 IN IP4 first.example.com t=0 0 c=IN IP4 111.111.111.111 m=audio 20000 RTP/AVP 0 a=fid:1 m=audio 20002 RTP/AVP 8 a=fid:1 If an implementation does not understand the fid attribute it will try to mix the audio streams. Since one is "empty" all the time, doing this is not really a big deal. Thus, backwards compatibility is not a concern. Do you have any concerns with this approach? RTP and RTCP remain untouched. Actually, this discussion began being very much RTP related, but now we are moving to MMUSIC or SIP probably... Best regards, Gonzalo ************ -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland http://www.hut.fi/~gonzalo _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Oct 12 02:31:00 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA13330 for ; Thu, 12 Oct 2000 02:31:00 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 39D524433A; Thu, 12 Oct 2000 01:31:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mars.hss.co.in (unknown [202.54.26.197]) by lists.bell-labs.com (Postfix) with ESMTP id 3BCD744339 for ; Thu, 12 Oct 2000 01:30:35 -0400 (EDT) Received: from sampark.hss.hns.com (sampark [139.85.229.22]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id e9C6V0C15064 for ; Thu, 12 Oct 2000 12:01:05 +0530 (IST) Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 65256976.00237940 ; Thu, 12 Oct 2000 11:57:28 +0530 X-Lotus-FromDomain: HSSBLR From: archow@hss.hns.com To: sip@lists.bell-labs.com Message-ID: <65256976.002377E8.00@sampark.hss.hns.com> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [SIP] SIP IMPP draft and Jabber like XML body Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 12 Oct 2000 11:57:24 +0530 Hi, I have a question wrt SIP based IMPP. While reading the drafts, I noticed the use of XML while doing SUBSCRIBE and NOTIFY to specify various options. In the im draft which discusses MESSAGE, it is mentioned that it can contain any MIME body and leaves it at that with some examples of text/plain. I also saw the Jabber IM draft which defines a set of XML tags which do similar stuff to SIP headers as well as lots of other tags for body rendering. Does anything stop me from using an XML based body in MESSAGE derived from Jabber ? In particular, I liked the ability to specify Voice XML based sections as well as text sections, which also includes typical HTML type body rendering to provide a more attractive chat screen. Is there any work on defining such a body set for SIP/impp or can I just take the relevant sections from Jabber tags ? Does this break the sip-impp model in any way (I dont think so at first read). Thanks Arjun -- Arjun Roychowdhury @ Hughes Software Systems _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Oct 12 02:36:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA13374 for ; Thu, 12 Oct 2000 02:36:00 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E7A5C4433A; Thu, 12 Oct 2000 01:36:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mailsrv02.multitude.com (mailsrv02.firetalk.com [204.178.116.251]) by lists.bell-labs.com (Postfix) with ESMTP id 950C644339 for ; Thu, 12 Oct 2000 01:35:15 -0400 (EDT) Received: from sbarber2k (s242.firetalk.com [204.178.116.242]) by mailsrv02.multitude.com (Rockliffe SMTPRA 3.4.2) with SMTP id ; Wed, 11 Oct 2000 23:33:03 -0700 From: "Simon Barber" To: "Jonathan Rosenberg" , , Subject: RE: [SIP] From header to ISUP CgPN mapping Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0000_01C033DC.21E7B970" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 11 Oct 2000 23:36:52 -0700 This is a multi-part message in MIME format. ------=_NextPart_000_0000_01C033DC.21E7B970 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Jonathan: > Simon: > > This scenario is an excellent example of why we might want to > > allow multiple From: > > headers, just as RFC822 allows for e-mail. A user could > > include both his sip address, > > and a tel: url as from headers. > > I don't see why thats needed. In my previous posting on this thread I have > explained why this is not a requirement for gateways at all. Even email > doesn't have such a concept. Email does have this conecpt - go check RFC822. Even Microsoft Outlook Express supports it (although Outlook doesn't). It's useful for indicating a message was co-authored by 2 people, or that replies should go back to 2 people (example from RFC822). Since many people will have 2 contact addresses (E164 + SIP) it would be a very good way to convey both of these with messages. > > > equally why are multiple To: lines not allowed - so users can > > see that several people > > were invited to a particular call? > > So we are talking about multiparty conferencing... thats a different issue. > For centralized conferences using a bridge, you'll know through RTCP. For > fully distributed, you'll know since you have a point to point signaling > relationship with each. You only know through RTCP once the connection is established - the key to headers is that you can see them before you accept the call (just like e-mail programs show headers before you read a message). I might choose not to accept a call from my boss, if I see he invited a whole bunch of other people as well. Equally if I don't take the call only the headers can be logged by my UA - I want to know that the call I missed from my boss was a conference call including a whole bunch of people. I also want to be able to call them all back by clicking "reply to all" on my logfile entry. Since this information only affects the display of call requests and reply functionality I don't see the difficulty in implementing this. What problems can you see? (I havn't though about the implications for comparing requests to see if they are the same). Simon Barber ------=_NextPart_000_0000_01C033DC.21E7B970 Content-Type: text/x-vcard; name="Simon Barber.vcf" Content-Disposition: attachment; filename="Simon Barber.vcf" Content-Transfer-Encoding: quoted-printable BEGIN:VCARD VERSION:2.1 N:Barber;Simon FN:Simon Barber ORG:Firetalk Communications, Inc. TEL;WORK;VOICE:(650) 636-1924 TEL;CELL;VOICE:(650) 743-1919 ADR;WORK:;;5000 Shoreline Court, Suite 200;South San = Francisco;CA;94080;United States of America LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:5000 Shoreline Court, Suite = 200=3D0D=3D0ASouth San Francisco, CA 94080=3D0D=3D0AUnit=3D ed States of America URL:http://www.firetalk.com URL:http://www.firetalk.com EMAIL;PREF;INTERNET:simon@firetalk.com REV:20000914T193921Z END:VCARD ------=_NextPart_000_0000_01C033DC.21E7B970-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Oct 12 03:40:59 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA13713 for ; Thu, 12 Oct 2000 03:40:59 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id BB03E4433A; Thu, 12 Oct 2000 02:41:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sumo.vocaltec.co.il (sumo.vocaltec.co.il [199.203.72.1]) by lists.bell-labs.com (Postfix) with ESMTP id D07AA44339 for ; Thu, 12 Oct 2000 02:40:34 -0400 (EDT) Received: from ilnimo.vocaltec.co.il (ilnimo.vocaltec.co.il [194.90.71.135]) by sumo.vocaltec.co.il (8.9.3/8.9.3) with ESMTP id JAA02650 for ; Thu, 12 Oct 2000 09:40:26 +0200 (IST) From: Joshua_Fox@vocaltec.com To: sip@lists.bell-labs.com X-Mailer: Lotus Notes Release 5.0.3 March 21, 2000 Message-ID: X-MIMETrack: Serialize by Router on ILNimo/Vocaltec_Comm(Release 5.0.3 (Intl)|21 March 2000) at 10/12/2000 09:40:02 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [SIP] call flow: Two different media types in parallel Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 12 Oct 2000 09:40:03 +0200 Thanks to SIP-list readers for answering my questions, which I hope are not too newbie-ish. Here is a call flow question. I did not see this discussed in the FAQ or call-flow examples, but if I missed it, could you please point me to the right URL. Say that two humans--the omnipresent Alice and Bob of cryptography fame--have two SIP-enabled UA's each. The UA's may be two apps running on one computer, or an app on a computer and on a handheld embedded-SIP device. The two devices communicate on different media--say one is audio-only and the other video-only, or one is audio-video and the other text-chat. Part of this call flow is that each person uses two independent SIP implementations--this is not one SIP UA controlling two media types, but rather two SIP UA's controlling two media types. Alice wants to push one and only one button and initiate simultaneous parallel channels on two separate media. What is the correct call flow? Does Alice's UA1 INVITE three other UA's--Alice's UA2, Bob's UA1, and Bob's UA2--to a four-way session (using SDP to distinguish the two channels)? If this is a case where Alice's UA1 and Alice's UA2 can communicate easily using a non-SIP protocol--say they are two apps on the same computer, and inter-process communication is possible--should that be done first, rather than attempting a SIP 4-way session? If so, then should the same thing be done of the other side--only one of Bob's UA's is initially invited, and this UA then INVITEs or otherwise brings Bob's other UA into the session? Or should Alice's initial INVITE from her UA1 be forked to both of Bob's UA's (a forking proxy typically forks to find which one of several choices is valid, but it could be asked to return more than one) and if so, what about Alice's UA2? In any of these cases, does Alice's UA1 have to be "told" about her UA2, or should a automated discovery process be built using REGISTER? I guess that both of each person's UAs would have the same SIP URL. We could take the question further and ask what call-flow to use when one of the apps is not SIP-enabled, but rather uses one of the other protocols which can be translated to/from SIP with a gateway. This is a rather wide question, and no doubt many implementations are possible. I'd like to see what has been written about these possibilities. Joshua Fox _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Oct 12 08:50:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA24086 for ; Thu, 12 Oct 2000 08:50:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id DCEE24433A; Thu, 12 Oct 2000 07:50:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cvis29.marconicomms.com (cvis29.marconicomms.com [195.99.244.61]) by lists.bell-labs.com (Postfix) with ESMTP id 0A65944339 for ; Thu, 12 Oct 2000 07:49:04 -0400 (EDT) Received: from cvis01.gpt.co.uk (unverified) by cvis29.marconicomms.com (Content Technologies SMTPRS 4.1.5) with ESMTP id ; Thu, 12 Oct 2000 13:48:49 +0100 Received: from marconicomms.com by cvis01.gpt.co.uk with SMTP (8.8.8+Sun/cvms-28) id NAA15601; Thu, 12 Oct 2000 13:48:48 +0100 (BST) Received: by marconicomms.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 80256976.004651FB ; Thu, 12 Oct 2000 13:48:05 +0100 X-Lotus-FromDomain: MCMAIN@MCEXT From: "Robin Escolme" To: Henning Schulzrinne Cc: sip@lists.bell-labs.com Message-ID: <80256976.00464A83.00@marconicomms.com> Subject: Re: [SIP] New draft on SIP registration Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 12 Oct 2000 13:47:42 +0100 Hi, I have the following questions/comments; >Assumptions > >We assume that each terminal is configured with a permanent user > address, a SIP URI, such as alice@wonderland.com. This identifier may >be embedded in the communications device, established via local login >into a shared computer or carried in some form of token, such as >SIM, smartcard, iButton or magnetic swipe card. I assume you are refering to 'personal communication' devices, such as a laptop PC, or a cellphone, when configuring with a permanent user address. For a shared device - eg, a deskphone, or shared computer, the examples of swipe card, smart card, etc imply the terminal assumes the address of the user - ie, the holder of the swipe card, for the period of the registration. This then is a temporary address as far as the terminal is concerned. Further to this, does not each terminal have its own identity - ie, host name? For example, 'termA.visited.net', etc. This can then be used within a contact address. >We define a traveling user or visitor as a SIP end point that is >visiting a domain other than the domain indicated in its SIP URI. The use of end point implies the terminal is mobile, as well as the user. Or is the swipe card referred to as an end point? This would make sense since the owner of the swipe card is mobile by viurtue of the fact that he has a swipe card. My assumption is that you are referring to personal mobility, where the person uses a swipe card (or similar) to register his identity at different terminals. >Home registration only: In this model, the visiting user simply > acquires a local IP address in the visited network and > sends a registration with a Contact header indicating that > address. > > REGISTER sip:wonderland.com SIP/2.0 > To: > From: > Contact: sip:alice@128.59.16.1 > > It makes no difference here whether the visited network > provides SIP services or not. An outbound proxy can be > used, but it simply forwards the REGISTER request based on > its request URI. > This approach works only if the visited network does not > use a firewall. Surely each terminal is configured with a host id. This can be supplied as the contact address rather than the absolute IP address, then there will be no problem with the use of firewalls. The contact address might be Contact: sip:alice@termA.visited.net >Outbound proxy intercept: Here, the outbound proxy intercepts > the registration request and changes the Contact address to > its own address. It has to create a new temporary user > identifier that allows it to identify incoming requests for > that visiting user. Can you give an example of the contact address in this case. Would it be something like Contact: sip:alice@Proxy1.visited.net I don't understand the need for a temporary user identity. The To: field in any INVITE will contain alice@wonderland.com - why isn't this sufficient to identify the user? (I am assuming the proxy server in visited.net can index a record using alice@wonderland.com). If the canonical name is used, how is it signaled to the home registrar - in the contact address? (But then the proxy server is not identified). Thanks, Robin Escolme _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Oct 12 10:37:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA26974 for ; Thu, 12 Oct 2000 10:37:00 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D272F4433A; Thu, 12 Oct 2000 09:37:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from jindo.cisco.com (jindo.cisco.com [171.69.11.73]) by lists.bell-labs.com (Postfix) with ESMTP id 148BF44339 for ; Thu, 12 Oct 2000 09:22:34 -0400 (EDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [171.71.147.106]) by jindo.cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id HAA13841; Thu, 12 Oct 2000 07:22:06 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id HAA09794; Thu, 12 Oct 2000 07:22:06 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14821.51470.600000.694429@thomasm-u1.cisco.com> To: Gonzalo Camarillo Cc: "Culpepper, Bert" , Rohan Mahy , Jonathan Rosenberg , sip@lists.bell-labs.com, Henning Schulzrinne , mmusic Subject: Re: [SIP] draft-camarillo-sip-sdp-00.txt In-Reply-To: <39E55120.4C00165F@lmf.ericsson.se> References: <39E17C56.35D50F99@lmf.ericsson.se> <39E55120.4C00165F@lmf.ericsson.se> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 12 Oct 2000 07:22:06 -0700 (PDT) Content-Transfer-Encoding: 7bit Gonzalo Camarillo writes: > I would like my session description to look like: > > v=0 > o=John 289085535 289085535 IN IP4 first.example.com > t=0 0 > c=IN IP4 111.111.111.111 > m=audio 20000 RTP/AVP 0 > a=fid:1 > m=audio 20002 RTP/AVP 8 > a=fid:1 > > If an implementation does not understand the fid attribute it will try > to mix the audio streams. Since one is "empty" all the time, doing this > is not really a big deal. Thus, backwards compatibility is not a > concern. > > Do you have any concerns with this approach? The main problem I see is with the interaction with QoS reservations. Namely, that you'd expect the receiver to book reservations for both flows. Doing: m=audio 20000 RTP/AVP 0 8 on the other hand only implies that you book the ceil() of both flows. Why is it so advantageous to segregate these into two streams? The implicit coupling you're after seems like it's not well handled by SDP right now, and I'd bet that this would be better taken up as a working item for SDPng (if not already there) because my understanding is that explicit audio synch with video is also problematic in SDP right now, which is sort of similar. Mike _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Oct 12 10:50:59 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA27847 for ; Thu, 12 Oct 2000 10:50:58 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2B0A74433A; Thu, 12 Oct 2000 09:51:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 166D244339 for ; Thu, 12 Oct 2000 09:50:26 -0400 (EDT) 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 KAA13219; Thu, 12 Oct 2000 10:49:45 -0400 (EDT) Message-ID: <39E5CB18.AC1C5AF@cs.columbia.edu> From: Henning Schulzrinne X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Simon Barber Cc: Jonathan Rosenberg , clive.dellard@bt.com, sip@lists.bell-labs.com Subject: Re: [SIP] From header to ISUP CgPN mapping References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 12 Oct 2000 10:30:48 -0400 Content-Transfer-Encoding: 7bit Since To and From are used to match call legs, they can't be replicated. (Besides minor problems like breaking every single existing SIP implementation...) Unlike for email, which can easily be copied, SIP call legs need a single destination. SMTP, after all, also does two transactions if you put in two different To fields. > Since this information only affects the display of call requests and reply > functionality I don't see the difficulty in implementing this. What problems can you > see? (I havn't though about the implications for comparing requests to see if they > are the same). That's one of the complications. SIP is not email, so doing a plain carry-over of headers is not likely to work well. Adding informational headers that carry no protocol implications is relatively harmless. For example, "Reply-To" might be a way to indicate addresses for possible return calls. > > Simon Barber _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Oct 12 11:54:08 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA00641 for ; Thu, 12 Oct 2000 11:54:07 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id CD9C24433A; Thu, 12 Oct 2000 10:54:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 1319744339 for ; Thu, 12 Oct 2000 10:53:19 -0400 (EDT) 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 LAA16932; Thu, 12 Oct 2000 11:53:11 -0400 (EDT) Message-ID: <39E5E0B3.B5E38B48@cs.columbia.edu> From: Henning Schulzrinne X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Robin Escolme Cc: sip@lists.bell-labs.com Subject: Re: [SIP] New draft on SIP registration References: <80256976.00464A83.00@marconicomms.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 12 Oct 2000 12:02:59 -0400 Content-Transfer-Encoding: 7bit > I assume you are refering to 'personal communication' devices, such as a laptop > PC, or a cellphone, when configuring with a permanent user address. For a shared > device - eg, a deskphone, or shared computer, the examples of swipe card, smart > card, etc imply the terminal assumes the address of the user - ie, the holder of > the swipe card, for the period of the registration. This then is a temporary > address as far as the terminal is concerned. Yes. > > Further to this, does not each terminal have its own identity - ie, host name? > For example, 'termA.visited.net', etc. This can then be used within a contact > address. I added this, but it is a host address, not a user@host. Also, this identifier is temporary and might change when connecting to different networks. It may also not be globally reachable. > > >We define a traveling user or visitor as a SIP end point that is > >visiting a domain other than the domain indicated in its SIP URI. > > The use of end point implies the terminal is mobile, as well as the user. Yes, the terminal or identity is moved to a different network. Could be a laptop or a "payphone" with a swipe card reader. In both cases, my identity (hgs@cs.columbia.edu) shows up outside my local network (cs.columbia.edu). I will try to clarify this in the next revision. > Or is > the swipe card referred to as an end point? This would make sense since the > owner of the swipe card is mobile by viurtue of the fact that he has a swipe > card. My assumption is that you are referring to personal mobility, where the > person uses a swipe card (or similar) to register his identity at different > terminals. Yes, that's it. > > Surely each terminal is configured with a host id. This can be supplied as the > contact address rather than the absolute IP address, then there will be no > problem with the use of firewalls. The contact address might be > > Contact: sip:alice@termA.visited.net Not true. Ever tried to connect to a host inside a firewall from the outside? > > >Outbound proxy intercept: Here, the outbound proxy intercepts > > the registration request and changes the Contact address to > > its own address. It has to create a new temporary user > > identifier that allows it to identify incoming requests for > > that visiting user. > > Can you give an example of the contact address in this case. Would it be > something like > > Contact: sip:alice@Proxy1.visited.net No: Contact: sip:alice%40home.net@proxy.visited.net Since there could be lots of Alice's visiting at the same time. > > I don't understand the need for a temporary user identity. The To: field in any > INVITE will contain alice@wonderland.com - why isn't this sufficient to identify > the user? (I am assuming the proxy server in visited.net can index a record > using alice@wonderland.com). If the canonical name is used, how is it signaled > to the home registrar - in the contact address? (But then the proxy server is > not identified). The problem is that > > Thanks, > > Robin Escolme _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Oct 12 11:57:58 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA00792 for ; Thu, 12 Oct 2000 11:57:56 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id EA21E44404; Thu, 12 Oct 2000 10:55:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cisco.com (bounty.cisco.com [161.44.3.204]) by lists.bell-labs.com (Postfix) with ESMTP id 2C783443F2 for ; Thu, 12 Oct 2000 10:54:45 -0400 (EDT) Received: from cisco.com (blanc.cisco.com [161.44.3.203]) by cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id LAA25203; Thu, 12 Oct 2000 11:53:55 -0400 (EDT) Message-ID: <39E5DE8A.A3251A62@cisco.com> From: Bryan Byerly X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "Culpepper, Bert" Cc: stlevy@cisco.com, jryang@cisco.com, SIP List Subject: Re: [SIP] draft-levy-sip-diversion-00.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 12 Oct 2000 11:53:47 -0400 Content-Transfer-Encoding: 7bit "Culpepper, Bert" wrote: > Hi, > > Some comments on your draft. I believe the following are typos. > > 7.1.4: Invite from P1->B should be INV Bob@B not INV Carol@B > > 7.3.2 Invite from A->C should be INVITE Carol@C not INVITE Bob@C, also > should be Diversion: Bob@B not Diversion: Carol@B > > 7.5.2 The 180 response is shown from D->C shouldn't it be from C->P2? > > 9.1 [9] Message desc. is SIP UAC to SIP proxy server 1, should be SIP UAC to > SIP UAS1 > > 9.1 In the Alice calls for roses call flow message descriptions 6, 7, & 8 > also don't match your MSC. ACK is not shown on MSC. Good catch on all of these! These will be corrected in the next version of the I-D. > These are minor, or I'm not understanding something and maybe a better > explanation is needed in the ID :-) > > When reading 9.2 and looking at the MSC I thought the voicemail had enough > information to identify the correct mailbox (from the To header) if the UAC > only replaced the Request-URI with the Contact and left the To header > unchanged. This seems like proper SIP behavior. After reading the message > contents I see that is the case in your example. There are two reasons that the To: header is insufficient to provide Diversion information: 1) The To: header may contain a private URL. 2) Even if the To: header contains a public URL, when there are multiple Diversions, the To header would not reflect the information on all the Diversions that occurred. For example, the third-party application service provider may (typically) want to see information on the final Diversion that occurred (instead of the first Diversion). Here's a SIP username style example of (1) using a night service: Assume that 2 pizza delivery companies, PapaJohns and Dominos, both contract with the third-party night service company, NightServ.com. PapaJohns contracts with NightService.com to provide night service for pizza@papajohns.com. Dominos contracts with NightService.com to provide night service for pizza@dominos.com. The Diversion header is inserted by the PapaJohn/Domino's proxy on call forward time-of-day to nightserv.com. Now, when Alice sends "INVITE pizza@proxy.ispA.com", her proxy could resolve to "pizza@papajohns.com". However, when Bob sends "INVITE pizza@proxy.ispB.com", his proxy could resolve to "pizza@dominos.com". Specifically notice that the contents of the To: header (pizza@proxy.ispA.com or pizza@proxy.ispB.com) did not provide sufficient information to the third-party night service provider to be able to respond intelligently with "Hello, this is PapaJohns" or "Hello, this is Dominos". Here's a PSTN style example of (1) using a third-party voicemail service: A third-party voicemail server may provide voicemail service for 111-555-1234 and 222-555-1234. When Alice calls "INVITE 1234@proxy.ispA.com", proxy.ispA.com expands the number to 111-555-1234. When Bob calls "INVITE 1234@proxy.ispB.com", proxy.ispB.com expands the number to 222-555-1234. Notice that, on Call Forward No Answer, the To: header (555-1234@proxy.ispA.com or 555-1234@proxy.ispB.com) does not contain sufficient information to forward to the appropriate voice mailbox. When a request (INVITE) arrives at a SIP entity, only the Request-URI (not the To: header) is "guaranteed" to be locally understood by that entity. (If the Request-URI is not understood, the PDU would be 404ed). Thus, in general, the To: header is only useful for determining uniqueness of a transaction (as part of the four-tuple: To:, From:, Call-ID, CSeq:) and is not useful for triggering called feature logic. In the general case, the Request-URI (and not the To: header) should be used to trigger called feature logic. That's why the Diversion header copies the contents of the Request-URI when the Diversion occurred. Thanks again for your help! Bryan > However, SIP today does > not provide the redirecting reason, which I assume is part of your > motivation for this new header. I will be interested to see how this > proposal is received since it can enhance a SIP application's functionality > and addresses an area of PSTN-IP interworking not otherwise covered by > existing work. > > Regards, > Bert > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Oct 12 12:17:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA01303 for ; Thu, 12 Oct 2000 12:17:02 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 176D644354; Thu, 12 Oct 2000 11:17:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from uqam.ca (anis.telecom.uqam.ca [132.208.250.6]) by lists.bell-labs.com (Postfix) with ESMTP id B6AB544339 for ; Thu, 12 Oct 2000 11:16:04 -0400 (EDT) Received: from C10824 ([132.208.135.68]) by uqam.ca (8.10.1/8.10.0) with SMTP id e9CGFxv00603 for ; Thu, 12 Oct 2000 12:15:59 -0400 (EDT) Message-ID: <003601c03468$2d835a00$4487d084@info> From: "Philippe Renaud" To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0033_01C03446.A6502840" 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 Subject: [SIP] Sniffer for RTP ? Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 12 Oct 2000 12:19:20 -0400 C'est un message de format MIME en plusieurs parties. ------=_NextPart_000_0033_01C03446.A6502840 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Does anyone know a good sniffer for RTP packets ? Thanks Philippe Renaud renaud@info.uqam.ca ------=_NextPart_000_0033_01C03446.A6502840 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Does anyone know a good sniffer for RTP = packets=20 ?
 
Thanks


Philippe Renaud
renaud@info.uqam.ca

------=_NextPart_000_0033_01C03446.A6502840-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Oct 12 12:20:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA01380 for ; Thu, 12 Oct 2000 12:20:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A572344410; Thu, 12 Oct 2000 11:20:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from newman.frascone.com (frascone.com [216.62.83.25]) by lists.bell-labs.com (Postfix) with ESMTP id A099544339 for ; Thu, 12 Oct 2000 11:19:57 -0400 (EDT) Received: (from chaos@localhost) by newman.frascone.com (8.9.3/8.9.3) id KAA21805; Thu, 12 Oct 2000 10:49:51 -0500 From: David Frascone To: Philippe Renaud Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Sniffer for RTP ? Message-ID: <20001012104950.J21055@newman.frascone.com> Mail-Followup-To: Philippe Renaud , sip@lists.bell-labs.com References: <003601c03468$2d835a00$4487d084@info> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: <003601c03468$2d835a00$4487d084@info>; from renaud@info.uqam.ca on Thu, Oct 12, 2000 at 12:19:20PM -0400 X-encrypt-payload: no Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 12 Oct 2000 10:49:50 -0500 Ethereal. http://www.ethereal.com On Thu, Oct 12, 2000 at 12:19:20PM -0400, Philippe Renaud wrote: > Does anyone know a good sniffer for RTP packets ? > > Thanks > > > Philippe Renaud > renaud@info.uqam.ca > > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Oct 12 12:56:17 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA02132 for ; Thu, 12 Oct 2000 12:56:15 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id F421C443F1; Thu, 12 Oct 2000 11:56:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from hotmail.com (f16.pav1.hotmail.com [64.4.31.16]) by lists.bell-labs.com (Postfix) with ESMTP id AEC8C44354 for ; Thu, 12 Oct 2000 11:55:32 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 12 Oct 2000 09:55:26 -0700 Received: from 164.164.6.34 by pv1fd.pav1.hotmail.msn.com with HTTP; Thu, 12 Oct 2000 16:55:26 GMT X-Originating-IP: [164.164.6.34] From: "Rakesh Jain" To: sip@lists.bell-labs.com Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 12 Oct 2000 16:55:26.0508 (UTC) FILETIME=[382F56C0:01C0346D] Subject: [SIP] some doubts.... Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 12 Oct 2000 16:55:26 GMT Hi, I am having some doubts in RFC2543, under section 6-12 CALL-ID, The statement given in this section is : “If the user is already a member of the conference and the conference parameters contained in the session description have not changed, a callee user agent server MAY silently accept the call, regardless of the Call-ID.“ In this case, will Call-ID in second call be same as existing Call-ID or it can differ With the existing Call-ID. What I understtod from the sentence is it can be same or Different also. Am I right? It will be very helpful, if somebody explain me with example. I am sorry, if not making any sense. Please refer me some pointer So i can get more clarity on this... Thanks in advance.. Rakesh jain _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. Share information about yourself, create your own public profile at http://profiles.msn.com. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Oct 12 13:21:10 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA02703 for ; Thu, 12 Oct 2000 13:21:09 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C2AFA4433A; Thu, 12 Oct 2000 12:21:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from rwcxch02.clarent.com (unknown [208.205.112.25]) by lists.bell-labs.com (Postfix) with ESMTP id C8DF844339 for ; Thu, 12 Oct 2000 12:20:32 -0400 (EDT) Received: by rwcxch02.clarent.com with Internet Mail Service (5.5.2650.21) id <4V3FLY99>; Thu, 12 Oct 2000 10:18:35 -0700 Message-ID: <6374EFC78443D41197DD00508B5C35DD0152774E@rwcxch02.clarent.com> From: Jean-Francois Mule To: Philippe Renaud , sip@lists.bell-labs.com Subject: RE: [SIP] Sniffer for RTP ? MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C03470.728627B0" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 12 Oct 2000 10:18:32 -0700 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_01C03470.728627B0 Content-Type: text/plain; charset="iso-8859-1" Philippe, Look at the open source network protocol analyzer: www.ethereal.com Jean-Francois. -----Original Message----- From: Philippe Renaud [mailto:renaud@info.uqam.ca] Sent: Thursday, October 12, 2000 9:19 AM To: sip@lists.bell-labs.com Subject: [SIP] Sniffer for RTP ? Does anyone know a good sniffer for RTP packets ? Thanks Philippe Renaud renaud@info.uqam.ca ------_=_NextPart_001_01C03470.728627B0 Content-Type: text/html; charset="iso-8859-1"
Philippe,
Look at the open source network protocol analyzer:  www.ethereal.com
Jean-Francois.
-----Original Message-----
From: Philippe Renaud [mailto:renaud@info.uqam.ca]
Sent: Thursday, October 12, 2000 9:19 AM
To: sip@lists.bell-labs.com
Subject: [SIP] Sniffer for RTP ?

Does anyone know a good sniffer for RTP packets ?
 
Thanks


Philippe Renaud
renaud@info.uqam.ca

------_=_NextPart_001_01C03470.728627B0-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Oct 12 13:25:11 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA02826 for ; Thu, 12 Oct 2000 13:25:11 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2C23544421; Thu, 12 Oct 2000 12:25:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cisco.com (bounty.cisco.com [161.44.3.204]) by lists.bell-labs.com (Postfix) with ESMTP id 545AA44339 for ; Thu, 12 Oct 2000 12:24:16 -0400 (EDT) Received: from cisco.com (blanc.cisco.com [161.44.3.203]) by cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id NAA00516; Thu, 12 Oct 2000 13:23:44 -0400 (EDT) Message-ID: <39E5F397.B6156C67@cisco.com> From: Bryan Byerly X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "Culpepper, Bert" Cc: stlevy@cisco.com, jryang@cisco.com, SIP List Subject: Re: [SIP] draft-levy-sip-diversion-00.txt References: <39E5DE8A.A3251A62@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 12 Oct 2000 13:23:35 -0400 Content-Transfer-Encoding: 7bit Corrected typo in explanation below. Should be 1234@proxy.ispA.com instead of 555-1234@proxy.ispA.com. cheers, Bryan Bryan Byerly wrote: > "Culpepper, Bert" wrote: > > > Hi, > > > > Some comments on your draft. I believe the following are typos. > > > > 7.1.4: Invite from P1->B should be INV Bob@B not INV Carol@B > > > > 7.3.2 Invite from A->C should be INVITE Carol@C not INVITE Bob@C, also > > should be Diversion: Bob@B not Diversion: Carol@B > > > > 7.5.2 The 180 response is shown from D->C shouldn't it be from C->P2? > > > > 9.1 [9] Message desc. is SIP UAC to SIP proxy server 1, should be SIP UAC to > > SIP UAS1 > > > > 9.1 In the Alice calls for roses call flow message descriptions 6, 7, & 8 > > also don't match your MSC. ACK is not shown on MSC. > > Good catch on all of these! These will be corrected in the next version of the > > I-D. > > > These are minor, or I'm not understanding something and maybe a better > > explanation is needed in the ID :-) > > > > When reading 9.2 and looking at the MSC I thought the voicemail had enough > > information to identify the correct mailbox (from the To header) if the UAC > > only replaced the Request-URI with the Contact and left the To header > > unchanged. This seems like proper SIP behavior. After reading the message > > contents I see that is the case in your example. > > There are two reasons that the To: header is insufficient to provide Diversion > information: > 1) The To: header may contain a private URL. > 2) Even if the To: header contains a public URL, when there are multiple > Diversions, the To header would not reflect the information on all the > Diversions that occurred. For example, the third-party application service > provider may (typically) want to see information on the final Diversion that > occurred (instead of the first Diversion). > > Here's a SIP username style example of (1) using a night service: > Assume that 2 pizza delivery companies, PapaJohns and Dominos, both contract > with the third-party night service company, NightServ.com. PapaJohns contracts > with NightService.com to provide night service for pizza@papajohns.com. > Dominos contracts with NightService.com to provide night service for > pizza@dominos.com. The Diversion header is inserted by the PapaJohn/Domino's > proxy on call forward time-of-day to nightserv.com. > > Now, when Alice sends "INVITE pizza@proxy.ispA.com", her proxy could resolve to > > "pizza@papajohns.com". However, when Bob sends "INVITE pizza@proxy.ispB.com", > his proxy could resolve to "pizza@dominos.com". Specifically notice that the > contents of the To: header (pizza@proxy.ispA.com or pizza@proxy.ispB.com) did > not provide sufficient information to the third-party night service provider to > > be able to respond intelligently with "Hello, this is PapaJohns" or "Hello, > this is Dominos". > > Here's a PSTN style example of (1) using a third-party voicemail service: > A third-party voicemail server may provide voicemail service for 111-555-1234 > and 222-555-1234. When Alice calls "INVITE 1234@proxy.ispA.com", > proxy.ispA.com expands the number to 111-555-1234. When Bob calls > "INVITE 1234@proxy.ispB.com", proxy.ispB.com expands the number to > 222-555-1234. Notice that, on Call Forward No Answer, the To: header > (1234@proxy.ispA.com or 1234@proxy.ispB.com) does not contain > > sufficient information to forward to the appropriate voice mailbox. > > When a request (INVITE) arrives at a SIP entity, only the Request-URI (not the > To: header) is "guaranteed" to be locally understood by that entity. (If the > Request-URI is not understood, the PDU would be 404ed). Thus, in general, the > To: header is only useful for determining uniqueness of a transaction (as part > of the four-tuple: To:, From:, Call-ID, CSeq:) and is not useful for triggering > > called feature logic. In the general case, the Request-URI (and not the > To: header) should be used to trigger called feature logic. That's why the > Diversion header copies the contents of the Request-URI when the Diversion > occurred. > > Thanks again for your help! > Bryan > > > However, SIP today does > > not provide the redirecting reason, which I assume is part of your > > motivation for this new header. I will be interested to see how this > > proposal is received since it can enhance a SIP application's functionality > > and addresses an area of PSTN-IP interworking not otherwise covered by > > existing work. > > > > Regards, > > Bert > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Oct 12 15:09:00 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA04239 for ; Thu, 12 Oct 2000 15:09:00 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2078D4433B; Thu, 12 Oct 2000 14:09:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mailsrv02.multitude.com (mailsrv02.firetalk.com [204.178.116.251]) by lists.bell-labs.com (Postfix) with ESMTP id 7748644339 for ; Thu, 12 Oct 2000 14:08:10 -0400 (EDT) Received: from sbarber2k (s242.firetalk.com [204.178.116.242]) by mailsrv02.multitude.com (Rockliffe SMTPRA 3.4.2) with SMTP id ; Thu, 12 Oct 2000 12:05:58 -0700 From: "Simon Barber" To: "Henning Schulzrinne" Cc: "Jonathan Rosenberg" , , Subject: RE: [SIP] From header to ISUP CgPN mapping Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_002A_01C03445.51003610" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <39E5CB18.AC1C5AF@cs.columbia.edu> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 12 Oct 2000 12:09:48 -0700 This is a multi-part message in MIME format. ------=_NextPart_000_002A_01C03445.51003610 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Henning: > Since To and From are used to match call legs, they can't be replicated. > (Besides minor problems like breaking every single existing SIP > implementation...) Unlike for email, which can easily be copied, SIP > call legs need a single destination. SMTP, after all, also does two > transactions if you put in two different To fields. > > > > > Since this information only affects the display of call requests and reply > > functionality I don't see the difficulty in implementing this. What > problems can you > > see? (I havn't though about the implications for comparing requests to > see if they > > are the same). > > That's one of the complications. > > SIP is not email, so doing a plain carry-over of headers is not likely > to work well. > > Adding informational headers that carry no protocol implications is > relatively harmless. For example, "Reply-To" might be a way to indicate > addresses for possible return calls. The Also-To: header would be purely informational - it would indicate to the UAS what other UASs had been invited. The meaning of Reply-To: is different from From: - and this difference could be just as useful for IMs and voice calls as it is for e-mail. IMs in particular, due to their close similarity to e-mail, should retain the same features users are used to with e-mail. My question is why should users lose this functionality for either IMs or voice calls? Simon Barber ------=_NextPart_000_002A_01C03445.51003610 Content-Type: text/x-vcard; name="Simon Barber.vcf" Content-Disposition: attachment; filename="Simon Barber.vcf" Content-Transfer-Encoding: quoted-printable BEGIN:VCARD VERSION:2.1 N:Barber;Simon FN:Simon Barber ORG:Firetalk Communications, Inc. TEL;WORK;VOICE:(650) 636-1924 TEL;CELL;VOICE:(650) 743-1919 ADR;WORK:;;5000 Shoreline Court, Suite 200;South San = Francisco;CA;94080;United States of America LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:5000 Shoreline Court, Suite = 200=3D0D=3D0ASouth San Francisco, CA 94080=3D0D=3D0AUnit=3D ed States of America URL:http://www.firetalk.com URL:http://www.firetalk.com EMAIL;PREF;INTERNET:simon@firetalk.com REV:20000914T193921Z END:VCARD ------=_NextPart_000_002A_01C03445.51003610-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Oct 12 17:17:19 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA06150 for ; Thu, 12 Oct 2000 17:17:12 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B89C14433A; Thu, 12 Oct 2000 16:17:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ivigate.intervoice.com (ivigate.intervoice.com [208.200.21.196]) by lists.bell-labs.com (Postfix) with ESMTP id B71CC44339 for ; Thu, 12 Oct 2000 16:16:52 -0400 (EDT) Received: from itmail-ict1.wichita.brite.com (itmail-ict1.wichita.brite.com [151.214.5.174]) by ivigate.intervoice.com (Build 98 8.9.3/NT-8.9.3) with ESMTP id QAA00407; Thu, 12 Oct 2000 16:15:07 -0500 Received: by itmail-ict1-imc.wichita.brite.com with Internet Mail Service (5.5.2448.0) id ; Thu, 12 Oct 2000 16:08:31 -0500 Message-ID: From: "Culpepper, Bert" To: Michael Thomas , Gonzalo Camarillo Cc: Rohan Mahy , Jonathan Rosenberg , sip@lists.bell-labs.com, Henning Schulzrinne , mmusic Subject: RE: [SIP] draft-camarillo-sip-sdp-00.txt MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 12 Oct 2000 16:08:27 -0500 Hi: I've only followed this thread on the SIP list and read the recent discussion on the AVT WG list, I've probably missed some related discussion in other WGs. It appears to me, and as Gonzalo pointed out, separate RTP streams are OK. The session description below describes two RTP streams with only one active at any point in time (I believe the semantics of the fid attribute shown indicate that I can choose to send only one) vs. a single RTP stream with either of two encoding schemes. However, as a SIP UA and having received that session description I know to send the two encodings separately if I want to make the other endpoint happy. (And only one at a time if I support the fid attribute.) It does seem reasonable that it might complicate QoS, but I expect the benefit of the separate media streams is justified when used. Anyway, segregating media streams (where exact synchronization isn't needed and RTP is good enough) enables certain efficiencies when providing telecommunications and like services in an IP network. This is only one advantage I suspect. Regards, Bert > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: Thursday, October 12, 2000 10:22 AM > To: Gonzalo Camarillo > Cc: Culpepper, Bert; Rohan Mahy; Jonathan Rosenberg; > sip@lists.bell-labs.com; Henning Schulzrinne; mmusic > Subject: Re: [SIP] draft-camarillo-sip-sdp-00.txt > > > Gonzalo Camarillo writes: > > I would like my session description to look like: > > > > v=0 > > o=John 289085535 289085535 IN IP4 first.example.com > > t=0 0 > > c=IN IP4 111.111.111.111 > > m=audio 20000 RTP/AVP 0 > > a=fid:1 > > m=audio 20002 RTP/AVP 8 > > a=fid:1 > > > > If an implementation does not understand the fid attribute it will try > > to mix the audio streams. Since one is "empty" all the time, doing this > > is not really a big deal. Thus, backwards compatibility is not a > > concern. > > > > Do you have any concerns with this approach? > > The main problem I see is with the interaction with > QoS reservations. Namely, that you'd expect the receiver > to book reservations for both flows. Doing: > > m=audio 20000 RTP/AVP 0 8 > > on the other hand only implies that you book the ceil() > of both flows. > > Why is it so advantageous to segregate these into two > streams? The implicit coupling you're after seems like > it's not well handled by SDP right now, and I'd bet > that this would be better taken up as a working item > for SDPng (if not already there) because my understanding > is that explicit audio synch with video is also problematic in > SDP right now, which is sort of similar. > > Mike > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Oct 12 19:50:35 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA08069 for ; Thu, 12 Oct 2000 19:50:24 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B5FBD44339; Thu, 12 Oct 2000 18:50:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from jittlov.qualcomm.com (jittlov.qualcomm.com [129.46.50.79]) by lists.bell-labs.com (Postfix) with ESMTP id 2DFE244336 for ; Thu, 12 Oct 2000 18:49:56 -0400 (EDT) Received: from harleeng.qualcomm.com (harleeng.qualcomm.com [129.46.172.108]) by jittlov.qualcomm.com (8.9.3/8.9.3/1.0) with ESMTP id QAA14191 for ; Thu, 12 Oct 2000 16:49:51 -0700 (PDT) Message-Id: <4.3.1.0.20001012163855.00c39950@jittlov.qualcomm.com> X-Sender: harleeng@jittlov.qualcomm.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 To: sip@lists.bell-labs.com From: Harleen Gill Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [SIP] ACK for 401 responses Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 12 Oct 2000 16:49:37 -0700 In Section "15.1.2 The Authorization Request Header" the following statement creates some confusion of whether an ACK message should be sent by the UAC when a 401 response is received: "Not generating nonces avoids the additional set of request, 401 response and possibly ACK messages and reduces delay by one round-trip time. " The use of the word "possibly" suggests that ACKs may or may not be sent when a 401 response is received. What is the recommended SIP procedure? _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Oct 12 19:56:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA08208 for ; Thu, 12 Oct 2000 19:56:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 88E4044339; Thu, 12 Oct 2000 18:56:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 6526D44336 for ; Thu, 12 Oct 2000 18:55:49 -0400 (EDT) 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 TAA21972; Thu, 12 Oct 2000 19:55:28 -0400 (EDT) Message-ID: <39E64F71.A8DFDDC7@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Harleen Gill Cc: sip@lists.bell-labs.com Subject: Re: [SIP] ACK for 401 responses References: <4.3.1.0.20001012163855.00c39950@jittlov.qualcomm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 12 Oct 2000 19:55:29 -0400 Content-Transfer-Encoding: 7bit Harleen Gill wrote: > > In Section "15.1.2 The Authorization Request Header" the following > statement creates some confusion of whether an ACK message should be sent > by the UAC when a 401 response is received: > > "Not generating nonces avoids the additional set of request, 401 response > and possibly ACK messages and reduces delay by one round-trip time. " > > The use of the word "possibly" suggests that ACKs may or may not be sent > when a 401 response is received. What is the recommended SIP procedure? > INVITE transactions generate ACKs, but OPTIONS and other requests don't, thus the "possibly". -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Oct 13 04:31:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA01210 for ; Fri, 13 Oct 2000 04:31:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3F9F44433A; Fri, 13 Oct 2000 03:31:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lists.bell-labs.com (Postfix) with ESMTP id 10F0644339 for ; Fri, 13 Oct 2000 03:30:26 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id e9D8UBZ02592; Fri, 13 Oct 2000 10:30:12 +0200 (MEST) Received: from lmf.ericsson.se (E005004B57CE1.lmf.ericsson.se [131.160.30.148]) by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id LAA12740; Fri, 13 Oct 2000 11:30:07 +0300 (EET DST) Message-ID: <39E6C80D.4E614098@lmf.ericsson.se> 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: "Culpepper, Bert" Cc: Michael Thomas , Rohan Mahy , Jonathan Rosenberg , sip@lists.bell-labs.com, Henning Schulzrinne , mmusic Subject: Re: [SIP] draft-camarillo-sip-sdp-00.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 13 Oct 2000 11:30:05 +0300 Content-Transfer-Encoding: 7bit Hi, I will try to summarize the discussions so far: The issue I am looking at is: "What happens when I need to receive a single media stream in different ports (or even different IP addresses) depending on the codec used at any moment". A media stream here is, for instance, the audio transmitted in a regular telephone call. With this issue in mind, it is good to know scenarios where this can happen and, of course, possible solutions. There are multiple scenarios where we can have this situation. -The device receiving voice is not the same as the device that handles DTMF tones. Thus, the media stream will have to be sent to the device handling voice when the RTP packets contain PCM voice (for instance) and to the device handling DTFM tones when they carry tones. -I need to use a transcoder because I have a cheap client that does not support all the audio codecs in the world. I want to receive PCM in my IP address, but I would like to receive GSM in the IP address of the transcoder. The transcoder will take care of sending the stream to my IP address once it has been transcoded. -Cellular terminals that have to configure radio bearers with specific codec information because some optimizations are applied. They want to receive media on different ports depending on the codec used. Folks have pointed out more scenarios where this might happen. The first solution I thought of was to send a single RTP stream to different ports (or different IP addresses). As the AVT guys pointed out, this would cause lots of problems. Mainly related to RTCP. Everybody agreed that a much better solution was to establish different RTP sessions. If different RTP sessions are established, this issue is transparent to RTP and RTCP. They are thus not affected. SDP backwards compatibility was also an issue, so a solution that does not break existing implementations has to be found. The fid (flow identifier) attribute I was describing in my previous mail would just be an identifier for the flow. That is, we might have several RTP streams, but all of them are related, because we are dealing with just one flow. So, an application receiving this parameter would know that all the m lines in the SDP with the same fid attribute (a=fid:12, for instance) are related. I believe this is useful information for the application. If an application does not understand the fid attribute, everything works properly. The only issue is that the application is not aware of this relation between m lines. Regarding Mike's question, this was already presented as input for SDPng in the last IETF. I am now after a solution for SDP. I agree that SDPng will solve all these issues. The quesion is: when? Everybody working on it is currently pretty busy. Best regards, Gonzalo "Culpepper, Bert" wrote: > > Hi: > > I've only followed this thread on the SIP list and read the recent > discussion on the AVT WG list, I've probably missed some related discussion > in other WGs. It appears to me, and as Gonzalo pointed out, separate RTP > streams are OK. The session description below describes two RTP streams > with only one active at any point in time (I believe the semantics of the > fid attribute shown indicate that I can choose to send only one) vs. a > single RTP stream with either of two encoding schemes. However, as a SIP UA > and having received that session description I know to send the two > encodings separately if I want to make the other endpoint happy. (And only > one at a time if I support the fid attribute.) It does seem reasonable that > it might complicate QoS, but I expect the benefit of the separate media > streams is justified when used. > > Anyway, segregating media streams (where exact synchronization isn't needed > and RTP is good enough) enables certain efficiencies when providing > telecommunications and like services in an IP network. This is only one > advantage I suspect. > > Regards, > Bert > > > -----Original Message----- > > From: Michael Thomas [mailto:mat@cisco.com] > > Sent: Thursday, October 12, 2000 10:22 AM > > To: Gonzalo Camarillo > > Cc: Culpepper, Bert; Rohan Mahy; Jonathan Rosenberg; > > sip@lists.bell-labs.com; Henning Schulzrinne; mmusic > > Subject: Re: [SIP] draft-camarillo-sip-sdp-00.txt > > > > > > Gonzalo Camarillo writes: > > > I would like my session description to look like: > > > > > > v=0 > > > o=John 289085535 289085535 IN IP4 first.example.com > > > t=0 0 > > > c=IN IP4 111.111.111.111 > > > m=audio 20000 RTP/AVP 0 > > > a=fid:1 > > > m=audio 20002 RTP/AVP 8 > > > a=fid:1 > > > > > > If an implementation does not understand the fid attribute it will try > > > to mix the audio streams. Since one is "empty" all the time, doing this > > > is not really a big deal. Thus, backwards compatibility is not a > > > concern. > > > > > > Do you have any concerns with this approach? > > > > The main problem I see is with the interaction with > > QoS reservations. Namely, that you'd expect the receiver > > to book reservations for both flows. Doing: > > > > m=audio 20000 RTP/AVP 0 8 > > > > on the other hand only implies that you book the ceil() > > of both flows. > > > > Why is it so advantageous to segregate these into two > > streams? The implicit coupling you're after seems like > > it's not well handled by SDP right now, and I'd bet > > that this would be better taken up as a working item > > for SDPng (if not already there) because my understanding > > is that explicit audio synch with video is also problematic in > > SDP right now, which is sort of similar. > > > > Mike > > -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland http://www.hut.fi/~gonzalo _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Oct 13 04:39:00 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA01292 for ; Fri, 13 Oct 2000 04:39:00 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5FC8C44339; Fri, 13 Oct 2000 03:39:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from drago1.ubiquity.net (unknown [194.202.146.92]) by lists.bell-labs.com (Postfix) with SMTP id 6D9C344336 for ; Fri, 13 Oct 2000 03:38:54 -0400 (EDT) Received: from gecko.ubiquity.co.uk by drago1.ubiquity.net via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 13 Oct 2000 08:39:20 UT Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id JAA15489; Fri, 13 Oct 2000 09:37:07 +0100 (BST) Message-ID: <39E6C9B4.76E1F1E8@ubiquity.net> From: Neil Deason Organization: Ubiquity Software Corporation Limited X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: sip-implementors@cs.columbia.edu, sip@lists.bell-labs.com References: <4.3.1.0.20001012163855.00c39950@jittlov.qualcomm.com> <39E64F71.A8DFDDC7@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] Incorrect behaviour when using a local outbound proxy Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 13 Oct 2000 09:37:08 +0100 Content-Transfer-Encoding: 7bit In testing labs I am seeing a worrying number of UA implementations making the same mistake of sending requests to a Proxy where the Request-URI is in the form sip:user@. I think some of the confusion may be traced back to early SIP message flows which showed this behaviour. I urge implementers to rectify this situation as we are seeing this cause a great deal of confusion to the first commercial adopters of SIP technology. These people are not SIP protocol experts and just expect this technology to work. It is often seen when using a local out bound proxy. The situation is that the UA takes a configuration parameter for the local proxy. You can then dial by keying in just the user part of a SIP URL. The UA then builds a complete URL by adding the Proxy's address and sends the message to the proxy. The Proxy then receives an INVITE of the form sip:user@proxy-ip - according to the protocol spec the Proxy will route this request to the server at the given IP address. This is obviously itself so an illegal loop is created. A simple solution would appear to be to configure these UAs with a 'default dial domain' and for it to build URLs using this not the Proxy's address. Cheers, Neil. -- Ubiquity Software Corporation, UK http://www.ubiquity.net _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Oct 13 05:48:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA01742 for ; Fri, 13 Oct 2000 05:48:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A785B44339; Fri, 13 Oct 2000 04:48:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from marvin.axion.bt.co.uk (marvin.axion.bt.co.uk [132.146.16.82]) by lists.bell-labs.com (Postfix) with ESMTP id 1929844336 for ; Fri, 13 Oct 2000 04:47:26 -0400 (EDT) Received: from cryndent01.mww.bt.com by marvin (local) with ESMTP; Fri, 13 Oct 2000 10:46:35 +0100 Received: by cryndent01.mww.bt.com with Internet Mail Service (5.5.2651.88) id <4H57QBL3>; Fri, 13 Oct 2000 10:46:19 +0100 Message-ID: From: clive.dellard@bt.com To: jdrosen@dynamicsoft.com Cc: sip@lists.bell-labs.com, simon@firetalk.com Subject: RE: [SIP] From header to ISUP CgPN mapping MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.88) Content-Type: text/plain Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 13 Oct 2000 10:46:26 +0100 I agree with what you say, however, if you consider a call originating from a SIP device (telephone or softphone) that ends up going through a gateway to the PSTN then it is a different story. Neither the user or the UAC can know where a call will end up, therefore the ability to be able to provide both SIP address and SIP Telephone number would be useful to providing a complete service as then an appropriate calling address is available wherever the call ends up. In the scenario I described the gateway could chose the Telephone number (ok I know there are verification issues but that's another story). Something like Simon's idea of an "ALSO-FROM" seems a good idea to me (this is similar to "two number delivery" in the ISDN CLIP service) older versions would just ignore the ALSO-FROM and it wouldn't affect the significance of the FROM and TO headers. Clive > -----Original Message----- > From: Jonathan Rosenberg [SMTP:jdrosen@dynamicsoft.com] > Sent: Wednesday, October 11, 2000 7:41 PM > To: 'clive.dellard@bt.com'; 'sip@lists.bell-labs.com' > Subject: RE: [SIP] From header to ISUP CgPN mapping > > > > > > -----Original Message----- > > From: clive.dellard@bt.com [mailto:clive.dellard@bt.com] > > Sent: Wednesday, October 11, 2000 12:17 PM > > To: sip@lists.bell-labs.com > > Subject: [SIP] From header to ISUP CgPN mapping > > > > > > In the call flows document draft-ietf-sip-call-flows-01.txt, > > scenario 4.1.1, > > the message detail and text show User A using a SIP telephone > > number rather > > than a SIP address in the From header. The text at the > > beginning of section > > 4 also says "that User A still uses his/her SIP URL in the > > Contact header, > > since the call could be redirected back to the SIP network." > > This implies that User A has pre-knowledge that the call is > > going to route > > to the PSTN and has the ability to chose the address to be > > used in the From > > header. > > No. > > The From header is the logical identity of the user making the call. Since > the call is coming through a gateway, that user is some user on a PSTN > terminal somewhere. The identity in this case can either be a tel URL, or > a > SIP URL at the domain of the originating network. > > The Contact is used for signaling addressing. Its not a logical > identifier. > It answers the question "where should I send SIP messages to for the rest > of > this call". The SIP spec says this is supposed to be a SIP URL preferably > with a complete hostname, so that there are no ambiguities about where to > send requests. > > Neither of these have anything to do with knowing where the call is going. > > -Jonathan R. > > --- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Oct 13 06:05:00 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA01849 for ; Fri, 13 Oct 2000 06:05:00 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B746B4434E; Fri, 13 Oct 2000 05:05:03 -0400 (EDT) Delivered-To: sip@share.research.bell-labs.com Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by lists.bell-labs.com (Postfix) with SMTP id DF46044349 for ; Fri, 13 Oct 2000 05:04:04 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by dirty; Fri Oct 13 06:03:48 EDT 2000 Received: by lists.bell-labs.com (Postfix) id DD83E44380; Fri, 13 Oct 2000 05:50:38 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from uk0006exch001h.wins.lucent.com (uk0006exch001h.uk.lucent.com [135.86.160.150]) by lists.bell-labs.com (Postfix) with ESMTP id 4393D4437D for ; Fri, 13 Oct 2000 05:50:38 -0400 (EDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id <4Y63ZKJ0>; Fri, 13 Oct 2000 10:35:11 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB06ABAED@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: SIP discussion list , egoine@iname.com Subject: RE: [SIP] Call redirected (302) to more expensive destination. MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 13 Oct 2000 10:35:10 +0100 Redirecting the session to a different endpoint does not necessarily make a call forwarding service. If you look at the ISDN call forwarding service descriptions (see ITU-T Recommendation I.254.2 for example or the equivalent ETSI publication available at www.etsi.fr in ETS 300 199) then you will see that a forwarding service (for the ISDN) is made up of the redirection, plus appropriate notifications to the calling, forwarding and forwarded-to users about the forwarding (including details of any repeated forwardings), plus a control on the maximum number of forwardings. In ISDN there is also an understanding that the forwarding party pays the extra cost of the forwarding. While I am not suggesting that a SIP forwarding service should necessarily emulate all the above, they were all introduced for service reasons rather than technical reasons. The charging constraint has meant that public network forwarding services have been by forward-switching (onward routeing of the call) rather than by redirection (returing the call to the source and reestablishing it) which is what can be performed in private ISDNs. While SIP could implement this charging constraint in the same manner as the ISDN, i.e. by having a proxy retained on behalf of the forwarding user which accumulates the additional charging details not accruing to the calling user, other models could be envisaged, e.g. where the a proxy is retained on behalf of the forwarding user, but the invite for the forwarding leg is forked from an earlier proxy in the path. I am uncertain whether this could be performed with the existing SIP. You will probably have to look elsewhere than the IETF to identify how implementors will handle charging in conjunction with SIP. Keith Drage Keith Drage Lucent Technologies Tel: +44 1793 776249 Email: drage@lucent.com > ---------- > From: Mathieu Gervais[SMTP:egoine_@hotmail.com] > Reply To: egoine@iname.com > Sent: 11 October 2000 23:17 > To: sip@lists.bell-labs.com > Subject: [SIP] Call redirected (302) to more expensive destination. > > Hi, > > Scenario : > > Caller A calls Callee B, but B User Agent redirects, with a 302, Caller > A > to another destination which is (way) more expensive for A. Because 302 is > > handled kind of automatically, the user A is not really asked if he still > wants to try to reach B (at higher cost). > > (Someone that doesn't want to talk to you could easily redirect all your > calls to an expensive destination, or something like that) > > Does this scenario makes sense? If yes, what do people think about this > problem? > > I guess that the user agent of A can inform him where it is getting > redirected, and give him a little delay to cancel the call before doing > automatic redirection, but what if A does not look at the "screen", or > just > does not have an idea that it's going to be a more expensive address to > contact? > > thanks, > > Mathieu > > > _________________________________________________________________________ > Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. > > Share information about yourself, create your own public profile at > http://profiles.msn.com. > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Oct 13 06:52:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA02428 for ; Fri, 13 Oct 2000 06:52:02 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5D74C44339; Fri, 13 Oct 2000 05:52:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 1F5F744337 for ; Fri, 13 Oct 2000 05:51:42 -0400 (EDT) Received: from dynamicsoft.com (useraa84.ie.uudial.com [212.120.133.85]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id GAA13353 for ; Fri, 13 Oct 2000 06:53:45 -0400 (EDT) Message-ID: <39E6E93C.7958683D@dynamicsoft.com> From: Chris Harris Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] JAIN SIP Specification Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 13 Oct 2000 11:51:40 +0100 Content-Transfer-Encoding: 7bit Dear SIP WG, The JAIN SIP Specification is available from today for Public Review on the Java website. It can be found at http://java.sun.com/aboutJava/communityprocess/review/jsr032/index.html. The Public Review will close on 28th November. Regards, Chris Haris _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Oct 13 09:14:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA04988 for ; Fri, 13 Oct 2000 09:14:02 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5C2CD44339; Fri, 13 Oct 2000 08:13:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from broadsoft.com (broadsoft.com [161.58.239.68]) by lists.bell-labs.com (Postfix) with ESMTP id 6A39444337 for ; Fri, 13 Oct 2000 08:12:38 -0400 (EDT) Received: from tate ([216.181.56.35]) by broadsoft.com (8.8.8) id JAA45931; Fri, 13 Oct 2000 09:12:22 -0400 (EDT) Message-ID: <093301c03517$64a838c0$3202a8c0@broadsoft.com> From: "Brett Tate" To: "Neil Deason" , , References: <4.3.1.0.20001012163855.00c39950@jittlov.qualcomm.com> <39E64F71.A8DFDDC7@cs.columbia.edu> <39E6C9B4.76E1F1E8@ubiquity.net> Subject: Re: [SIP] Incorrect behaviour when using a local outbound proxy 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: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 13 Oct 2000 09:13:35 -0400 Content-Transfer-Encoding: 7bit > In testing labs I am seeing a worrying number of UA > implementations making the same mistake of sending requests > to a Proxy where the Request-URI is in the form > sip:user@. I think some of the confusion may > be traced back to early SIP message flows which showed this > behaviour. I urge implementers to rectify this situation as > we are seeing this cause a great deal of confusion to > the first commercial adopters of SIP technology. These people > are not SIP protocol experts and just expect this technology > to work. > > It is often seen when using a local out bound proxy. The > situation is that the UA takes a configuration parameter > for the local proxy. You can then dial by keying in just the > user part of a SIP URL. The UA then builds a complete URL by > adding the Proxy's address and sends the message to the proxy. > The Proxy then receives an INVITE of the form > sip:user@proxy-ip - according to the protocol spec the Proxy > will route this request to the server at the given IP address. > This is obviously itself so an illegal loop is created. A An outbound proxy for userA can be configured to translate upon a received outgoing message from known userA however it wishes. UserA dialing *69 on a phone can be sent to outbound proxy with Request-URI of *69@outboundProxy-Ip. Assuming the outbound proxy knows userA, it can change the Request-URI into the last "known" user@host that called userA. > simple solution would appear to be to configure these UAs with > a 'default dial domain' and for it to build URLs using this > not the Proxy's address. I agree that default dial domain can be used and does more explicitly inform the proxy that the request was intended to be processed like an outbound-proxy instead of a regular proxy. However I don't see that it should be required unless the outbound proxy has problems with spiraling. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Oct 13 09:34:19 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA05328 for ; Fri, 13 Oct 2000 09:34:19 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C46864435C; Fri, 13 Oct 2000 08:34:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cisco.com (blanc.cisco.com [161.44.3.203]) by lists.bell-labs.com (Postfix) with ESMTP id 0708D44337 for ; Fri, 13 Oct 2000 08:33:02 -0400 (EDT) Received: (from ddaiker@localhost) by cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.8.8) id JAA22563; Fri, 13 Oct 2000 09:32:05 -0400 (EDT) From: David Daiker Message-Id: <200010131332.JAA22563@cisco.com> Subject: Re: [SIP] Incorrect behaviour when using a local outbound proxy To: ndeason@ubiquity.net (Neil Deason) Cc: sip-implementors@cs.columbia.edu, sip@lists.bell-labs.com In-Reply-To: <39E6C9B4.76E1F1E8@ubiquity.net> from "Neil Deason" at Oct 13, 2000 09:37:08 AM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 13 Oct 2000 09:32:05 -0400 (EDT) Content-Transfer-Encoding: 7bit > > In testing labs I am seeing a worrying number of UA > implementations making the same mistake of sending requests > to a Proxy where the Request-URI is in the form > sip:user@. I think some of the confusion may > be traced back to early SIP message flows which showed this > behaviour. I urge implementers to rectify this situation as > we are seeing this cause a great deal of confusion to > the first commercial adopters of SIP technology. These people > are not SIP protocol experts and just expect this technology > to work. > > It is often seen when using a local out bound proxy. The > situation is that the UA takes a configuration parameter > for the local proxy. You can then dial by keying in just the > user part of a SIP URL. The UA then builds a complete URL by > adding the Proxy's address and sends the message to the proxy. > The Proxy then receives an INVITE of the form > sip:user@proxy-ip - according to the protocol spec the Proxy > will route this request to the server at the given IP address. > This is obviously itself so an illegal loop is created. A I disagree, if the uri points to proxyA, that only implies that proxyA has access to a location service that can forward this request (at least 1 hop closer) to 'user' > simple solution would appear to be to configure these UAs with > a 'default dial domain' and for it to build URLs using this > not the Proxy's address. Sure, but since the proxy is probably linked to the local domain anyway, I think it's more realistic to configure the proxy with a 'default dial domain' than force it on every UA that happens to wander in. After all, isn't that what proxies are for ? Otherwise, the UA might as well send the invite directly to the destination. david > Cheers, > Neil. > -- > Ubiquity Software Corporation, UK http://www.ubiquity.net > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Oct 13 09:39:06 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA05383 for ; Fri, 13 Oct 2000 09:39:05 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 41B7544362; Fri, 13 Oct 2000 08:39:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cisco.com (bounty.cisco.com [161.44.3.204]) by lists.bell-labs.com (Postfix) with ESMTP id 32DEB44337 for ; Fri, 13 Oct 2000 08:38:18 -0400 (EDT) Received: from cisco.com (blanc.cisco.com [161.44.3.203]) by cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id JAA14284; Fri, 13 Oct 2000 09:38:02 -0400 (EDT) Message-ID: <39E71031.24B0F97E@cisco.com> From: Bryan Byerly X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "Drage, Keith (Keith)" Cc: SIP discussion list , egoine@iname.com, byerly@cisco.com Subject: Re: [SIP] Call redirected (302) to more expensive destination. References: <475FF955A05DD411980D00508B6D5FB06ABAED@en0033exch001u.uk.lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 13 Oct 2000 09:37:53 -0400 Content-Transfer-Encoding: 7bit The Diversion Indication in SIP I-D addresses some of these issues. See: http://www.ietf.org/internet-drafts/draft-levy-sip-diversion-00.txt cheers, Bryan "Drage, Keith (Keith)" wrote: > Redirecting the session to a different endpoint does not necessarily make a > call forwarding service. If you look at the ISDN call forwarding service > descriptions (see ITU-T Recommendation I.254.2 for example or the equivalent > ETSI publication available at www.etsi.fr in ETS 300 199) then you will see > that a forwarding service (for the ISDN) is made up of the redirection, plus > appropriate notifications to the calling, forwarding and forwarded-to users > about the forwarding (including details of any repeated forwardings), plus a > control on the maximum number of forwardings. In ISDN there is also an > understanding that the forwarding party pays the extra cost of the > forwarding. > > While I am not suggesting that a SIP forwarding service should necessarily > emulate all the above, they were all introduced for service reasons rather > than technical reasons. The charging constraint has meant that public > network forwarding services have been by forward-switching (onward routeing > of the call) rather than by redirection (returing the call to the source and > reestablishing it) which is what can be performed in private ISDNs. > > While SIP could implement this charging constraint in the same manner as the > ISDN, i.e. by having a proxy retained on behalf of the forwarding user which > accumulates the additional charging details not accruing to the calling > user, other models could be envisaged, e.g. where the a proxy is retained on > behalf of the forwarding user, but the invite for the forwarding leg is > forked from an earlier proxy in the path. I am uncertain whether this could > be performed with the existing SIP. > > You will probably have to look elsewhere than the IETF to identify how > implementors will handle charging in conjunction with SIP. > > Keith Drage > > Keith Drage > Lucent Technologies > Tel: +44 1793 776249 > Email: drage@lucent.com > > > ---------- > > From: Mathieu Gervais[SMTP:egoine_@hotmail.com] > > Reply To: egoine@iname.com > > Sent: 11 October 2000 23:17 > > To: sip@lists.bell-labs.com > > Subject: [SIP] Call redirected (302) to more expensive destination. > > > > Hi, > > > > Scenario : > > > > Caller A calls Callee B, but B User Agent redirects, with a 302, Caller > > A > > to another destination which is (way) more expensive for A. Because 302 is > > > > handled kind of automatically, the user A is not really asked if he still > > wants to try to reach B (at higher cost). > > > > (Someone that doesn't want to talk to you could easily redirect all your > > calls to an expensive destination, or something like that) > > > > Does this scenario makes sense? If yes, what do people think about this > > problem? > > > > I guess that the user agent of A can inform him where it is getting > > redirected, and give him a little delay to cancel the call before doing > > automatic redirection, but what if A does not look at the "screen", or > > just > > does not have an idea that it's going to be a more expensive address to > > contact? > > > > thanks, > > > > Mathieu > > > > > > _________________________________________________________________________ > > Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. > > > > Share information about yourself, create your own public profile at > > http://profiles.msn.com. > > > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Oct 13 09:54:10 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA05764 for ; Fri, 13 Oct 2000 09:54:09 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6D14A4436C; Fri, 13 Oct 2000 08:54:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from china.com (TCE-E-7-182-13.bta.net.cn [202.106.182.13]) by lists.bell-labs.com (Postfix) with SMTP id 2178144337 for ; Fri, 13 Oct 2000 05:36:14 -0400 (EDT) Received: from china.com([10.1.7.102]) by china.com(JetMail 2.5.3.0) with SMTP id jm439e74664; Fri, 13 Oct 2000 10:34:08 -0000 Content-Type: text/plain Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Message-ID: From: fordtrueman@china.com To: SIP@lists.bell-labs.com X-Priority: 3 Subject: [SIP] Discussion about RFC2543 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 13 Oct 2000 18:34:07 +0800 (CST) Content-Transfer-Encoding: 8bit Dear All: I want to discuss one question. In RFC2543 bis02 on content-Length, which says"If a server receives a UDP request with a Content-Length, but the value is larger than the size of the body sent in the request, the client SHOULD generate a 400 class response.", I think this maybe wrong, the server receives a request, the response should be generated by server, how can the response generated by client. What's more, I read 4xx response,there is no response can corresponds this item? Could someone give me some explanation? Thank you very much! Yours: Ford ---------------------------------------------- ÖлªÍø»ýÉÍÖ®ÂÃ,´ó½±ÈÎÄúÓ®£¡ http://points4u.china.com ²Î¼ÓÍøÉÏÅÄÂô£¬ÃûÈËÇ©ÃûÎïÆ·ÈÎÄãÕù! http://auction4u.china.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Oct 13 10:04:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA06186 for ; Fri, 13 Oct 2000 10:04:02 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5E1A244375; Fri, 13 Oct 2000 09:04:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 3748244337 for ; Fri, 13 Oct 2000 09:03:38 -0400 (EDT) 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 KAA03657; Fri, 13 Oct 2000 10:03:26 -0400 (EDT) Message-ID: <39E7187B.AA24D0EE@cs.columbia.edu> From: Henning Schulzrinne X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: fordtrueman@china.com Cc: SIP@lists.bell-labs.com Subject: Re: [SIP] Discussion about RFC2543 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 13 Oct 2000 10:13:15 -0400 Content-Transfer-Encoding: 7bit Yes, that was a typo. Thanks. fordtrueman@china.com wrote: > > Dear All: > I want to discuss one question. > In RFC2543 bis02 on content-Length, which says"If a server receives a UDP request with a Content-Length, but the value is larger than the size of the body sent in the request, the client SHOULD generate a 400 class response.", I think this maybe wrong, the server receives a request, the response should be > generated by server, how can the response generated by client. What's more, > I read 4xx response,there is no response can corresponds this item? Could someone give me some explanation? > Thank you very much! > Yours: Ford _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Oct 13 10:49:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA06940 for ; Fri, 13 Oct 2000 10:49:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E3EC444339; Fri, 13 Oct 2000 09:49:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from drago1.ubiquity.net (unknown [194.202.146.92]) by lists.bell-labs.com (Postfix) with SMTP id 3326F44337 for ; Fri, 13 Oct 2000 09:48:09 -0400 (EDT) Received: from gecko.ubiquity.co.uk by drago1.ubiquity.net via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 13 Oct 2000 14:48:35 UT Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id PAA13555; Fri, 13 Oct 2000 15:46:21 +0100 (BST) Message-ID: <39E7203C.CC6B6382@ubiquity.net> From: Neil Deason Organization: Ubiquity Software Corporation Limited X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Brett Tate Cc: sip-implementors@cs.columbia.edu, sip@lists.bell-labs.com Subject: Re: [SIP] Incorrect behaviour when using a local outbound proxy References: <4.3.1.0.20001012163855.00c39950@jittlov.qualcomm.com> <39E64F71.A8DFDDC7@cs.columbia.edu> <39E6C9B4.76E1F1E8@ubiquity.net> <093301c03517$64a838c0$3202a8c0@broadsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 13 Oct 2000 15:46:20 +0100 Content-Transfer-Encoding: 7bit Brett Tate wrote: > > > In testing labs I am seeing a worrying number of UA > > implementations making the same mistake of sending requests > > to a Proxy where the Request-URI is in the form > > sip:user@. I think some of the confusion may > > be traced back to early SIP message flows which showed this > > behaviour. I urge implementers to rectify this situation as > > we are seeing this cause a great deal of confusion to > > the first commercial adopters of SIP technology. These people > > are not SIP protocol experts and just expect this technology > > to work. > > > > It is often seen when using a local out bound proxy. The > > situation is that the UA takes a configuration parameter > > for the local proxy. You can then dial by keying in just the > > user part of a SIP URL. The UA then builds a complete URL by > > adding the Proxy's address and sends the message to the proxy. > > The Proxy then receives an INVITE of the form > > sip:user@proxy-ip - according to the protocol spec the Proxy > > will route this request to the server at the given IP address. > > This is obviously itself so an illegal loop is created. A > > An outbound proxy for userA can be configured > to translate upon a received outgoing message > from known userA however it wishes. UserA > dialing *69 on a phone can be sent to outbound > proxy with Request-URI of *69@outboundProxy-Ip. > Assuming the outbound proxy knows userA, it can > change the Request-URI into the last "known" > user@host that called userA. According to the SIP spec sip:*69@outboundProxy-Ip does not map onto the last incoming caller's sip URL this is specialised logic. It may exist but a truly interoperable UA must still be able to work if it doesn't. The point I was really trying to make is that a UA should not write Request-URIs out to be the destination of where they are being sent in the hostport when using a local outbound proxy. Say I want to dial sip:jsmith@another-domain.com but the UA configured with a local outbound proxy setting of proxy.this-domain.com actually sends the INVITE out as:- INVITE sip:jsmith@proxy.this-domain.com SIP/2.0 To: sip:jsmith@another-domain.com From: sip:PoorUser@this-domain.com .... This will either result in a 404 response, possibly 482 if the Proxy sends on to itself, or go to the wrong jsmith. If a UA can only send out INVITEs with Request-URIs like this it is broken. Cheers, Neil. -- Ubiquity Software Corporation, UK http://www.ubiquity.net _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Oct 13 11:23:25 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA07613 for ; Fri, 13 Oct 2000 11:23:25 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9942644339; Fri, 13 Oct 2000 10:23:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from wodc7mr4.ffx.ops.us.uu.net (paleoalterdial.UU.NET [192.48.96.22]) by lists.bell-labs.com (Postfix) with ESMTP id A6C3C44339 for ; Fri, 13 Oct 2000 09:52:58 -0400 (EDT) Received: from SAGAR by wodc7mr4.ffx.ops.us.uu.net with SMTP (peer crosschecked as: [63.119.86.3]) id QQjksx16776 for ; Fri, 13 Oct 2000 14:52:54 GMT From: "Umesh Sirsiwal" To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: <093301c03517$64a838c0$3202a8c0@broadsoft.com> Importance: Normal Subject: [SIP] SIP proxy and NAPTs Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 13 Oct 2000 10:53:29 -0400 Content-Transfer-Encoding: 8bit I have a simple question regarding SIP and NAPT. The following is taken from SIP draft. In this specification, proxies inspect source IP address, and if that is different then the address in via filed they add a received attribute, however they do not do a similar thing with the source port number. I do not understand why? If they can do that SIP will trverse transparently across NAPTs as well... -Umesh A host behind a network address translator (NAT) or firewall may not be able to insert a network address into the Via header that can be reached by the next hop beyond the NAT. Use of the received attribute allows SIP requests to traverse NAT's which only modify the source IP address. NAT's which modify port numbers, called Network Address Port Translators (NAPTs) will not properly pass SIP when transported on UDP, so that an application-layer gateway is Handley/Schulzrinne/Schooler/Rosenberg [Page 75] Internet Draft SIP August 6, 2000 required. When run over TCP, SIP stands a better chance of traversing NAPTs, since its behavior is similar to HTTP in this case, albeit using different ports. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Oct 13 11:39:31 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA07916 for ; Fri, 13 Oct 2000 11:39:31 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1868044381; Fri, 13 Oct 2000 10:39:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from drago1.ubiquity.net (unknown [194.202.146.92]) by lists.bell-labs.com (Postfix) with SMTP id 1557444337 for ; Fri, 13 Oct 2000 10:38:54 -0400 (EDT) Received: from gecko.ubiquity.co.uk by drago1.ubiquity.net via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 13 Oct 2000 15:39:20 UT Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id QAA00997; Fri, 13 Oct 2000 16:37:11 +0100 (BST) From: "Jo Hornsby" To: "Umesh Sirsiwal" , Subject: RE: [SIP] SIP proxy and NAPTs Message-ID: <001901c0352b$7392f2d0$4e34c3c1@ubiquity.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 13 Oct 2000 16:37:10 +0100 Content-Transfer-Encoding: 7bit > I have a simple question regarding SIP and NAPT. The following is > taken from SIP draft. In this specification, proxies inspect source > IP address, and if that is different then the address in via filed they > add a received attribute, however they do not do a similar thing with > the source port number. I do not understand why? If they can do that > SIP will trverse transparently across NAPTs as well... This has been discussed on the List a number of times. Basically, it is not reasonable to assume that a client sends on the same port that it listens on; indeed, for common IP stacks, this would rule out being able to detect ICMP errors when utilising UDP as a transport, for example. Thus, the source port is quite unlikely to be helpful. There are other issues, but this is probably the most pressing. HTH, - Jo. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Oct 13 12:32:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA08860 for ; Fri, 13 Oct 2000 12:32:03 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3434F44337; Fri, 13 Oct 2000 11:32:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from broadsoft.com (broadsoft.com [161.58.239.68]) by lists.bell-labs.com (Postfix) with ESMTP id 6AC6444336 for ; Fri, 13 Oct 2000 11:31:11 -0400 (EDT) Received: from tate ([216.181.56.35]) by broadsoft.com (8.8.8) id MAA71035; Fri, 13 Oct 2000 12:31:05 -0400 (EDT) Message-ID: <097101c03533$2739d680$3202a8c0@broadsoft.com> From: "Brett Tate" To: "Neil Deason" Cc: , References: <4.3.1.0.20001012163855.00c39950@jittlov.qualcomm.com> <39E64F71.A8DFDDC7@cs.columbia.edu> <39E6C9B4.76E1F1E8@ubiquity.net> <093301c03517$64a838c0$3202a8c0@broadsoft.com> <39E7203C.CC6B6382@ubiquity.net> Subject: Re: [SIP] Incorrect behaviour when using a local outbound proxy 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: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 13 Oct 2000 12:32:18 -0400 Content-Transfer-Encoding: 7bit > > > In testing labs I am seeing a worrying number of UA > > > implementations making the same mistake of sending requests > > > to a Proxy where the Request-URI is in the form > > > sip:user@. I think some of the confusion may > > > be traced back to early SIP message flows which showed this > > > behaviour. I urge implementers to rectify this situation as > > > we are seeing this cause a great deal of confusion to > > > the first commercial adopters of SIP technology. These people > > > are not SIP protocol experts and just expect this technology > > > to work. > > > > > > It is often seen when using a local out bound proxy. The > > > situation is that the UA takes a configuration parameter > > > for the local proxy. You can then dial by keying in just the > > > user part of a SIP URL. The UA then builds a complete URL by > > > adding the Proxy's address and sends the message to the proxy. > > > The Proxy then receives an INVITE of the form > > > sip:user@proxy-ip - according to the protocol spec the Proxy > > > will route this request to the server at the given IP address. > > > This is obviously itself so an illegal loop is created. A > > > > An outbound proxy for userA can be configured > > to translate upon a received outgoing message > > from known userA however it wishes. UserA > > dialing *69 on a phone can be sent to outbound > > proxy with Request-URI of *69@outboundProxy-Ip. > > Assuming the outbound proxy knows userA, it can > > change the Request-URI into the last "known" > > user@host that called userA. > > According to the SIP spec sip:*69@outboundProxy-Ip > does not map onto the last incoming caller's sip URL > this is specialised logic. It may exist but a truly > interoperable UA must still be able to work if it > doesn't. > > The point I was really trying to make is that a UA > should not write Request-URIs out to be the destination > of where they are being sent in the hostport when using > a local outbound proxy. > > Say I want to dial sip:jsmith@another-domain.com but > the UA configured with a local outbound proxy setting > of proxy.this-domain.com actually sends the INVITE > out as:- > > INVITE sip:jsmith@proxy.this-domain.com SIP/2.0 > To: sip:jsmith@another-domain.com > From: sip:PoorUser@this-domain.com > .... > A proxy receiving the above request assumes that the user is trying to reach the Request-URI. By becoming aware the need to act as an outbound proxy, the Request-URI can be changed by the outbound proxy. When any proxy or user agent receives the initial INVITE, the user@hostport of "To" should only really mean what was supposedly dialed/entered to reach you (and call-leg identification). If the user agent was trying to reach sip:jsmith@another-domain.com, it should be in the Request-URI. And the message should be sent to proxy.this-domain.com if it wants to use it as an outbound proxy. Note: Recent threads on outbound proxies also define the use "Route" to allow for an outbound proxy chain. However I don't think that discussion has been finalized. > This will either result in a 404 response, possibly > 482 if the Proxy sends on to itself, or go to the > wrong jsmith. If a UA can only send out INVITEs > with Request-URIs like this it is broken. > > Cheers, > Neil. > -- > Ubiquity Software Corporation, UK http://www.ubiquity.net > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Oct 13 17:06:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA11877 for ; Fri, 13 Oct 2000 17:06:00 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E7F944433B; Fri, 13 Oct 2000 16:06:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ivigate.intervoice.com (ivigate.intervoice.com [208.200.21.196]) by lists.bell-labs.com (Postfix) with ESMTP id 1E67444336 for ; Fri, 13 Oct 2000 16:05:25 -0400 (EDT) Received: from itmail-ict1.wichita.brite.com (itmail-ict1.wichita.brite.com [151.214.5.174]) by ivigate.intervoice.com (Build 98 8.9.3/NT-8.9.3) with ESMTP id QAA12855; Fri, 13 Oct 2000 16:06:37 -0500 Received: by itmail-ict1-imc.wichita.brite.com with Internet Mail Service (5.5.2448.0) id ; Fri, 13 Oct 2000 16:00:31 -0500 Message-ID: From: "Culpepper, Bert" To: Bryan Byerly Cc: stlevy@cisco.com, jryang@cisco.com, SIP List Subject: RE: [SIP] draft-levy-sip-diversion-00.txt MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 13 Oct 2000 16:00:19 -0500 Thank you for your response. My comments are below. > -----Original Message----- > From: Bryan Byerly [mailto:byerly@cisco.com] > Sent: Friday, October 13, 2000 4:28 PM > To: Culpepper, Bert > Cc: stlevy@cisco.com; jryang@cisco.com; byerly@cisco.com > Subject: Re: [SIP] draft-levy-sip-diversion-00.txt > > > "Culpepper, Bert" wrote: > > > Hi: > > > > This is just a "sanity check" on my part. A SIP UA can > > send an INVITE to proxy server (host) independent of the > > host specified in the Request-URI. The proxy would > > forward this message on according to its policies. If you > > consider the proxy server provides no additional > > functionality than that defined in the SIP RFC, the UA > > would use the 10-digit DN in your voice mail example in > > both the Request-URI and To: header. > > True. Although I'm not sure how the UAC in the example above knew to > call the > voicemail server directly. Was the intent of the UAC: "I want to call > Bob's > voicemail?", or "I want to call Bob"? In my scenario here the UAC wanted to call Bob and Bob's UA forwarded the call to voicemail. Here's the forwarding intelligence is in Bob's UA. > > > If a call is > > forwarded to voice mail, I'd expect the forwarding > > UA/proxy to modify the Request-URI to be that of the > > voice mail service but leave the To: header unchanged. > > Yes, per RFC2543, the To: header should remain unchanged. > > > A SIP UA receiving the forwarded session can determine > > its for voice mail by the Request-URI and identify the > > mailbox from the To: header. > > There is a subset of all possible calls for which the above approach will > work. Specifically, > a) calls that have not been diverted multiple times > AND > b) calls which originated at the UAC with a global URL. I agree, in the case of multiple redirections the Diversion information is needed if the session is to end up in mailbox of the last diverting UA (or proxy on behalf of the UA). Thanks, Bert > > > However, the proxy servers in these examples are > > providing additional features to their users. Such as > > "4-digit dialing". Encountering this kind of service is to be > > expected in some networks, therefore the need for the > > Diversion information. Do you agree? > > Yes. Exactly. > > This is a good discussion. Do you mind forwarding this to the main > SIP list? > > thanks for your help, > Bryan > > > Thanks, > > Bert > > > > -----Original Message----- > > From: Bryan Byerly [mailto:byerly@cisco.com] > > Sent: Thursday, October 12, 2000 1:24 PM > > To: Culpepper, Bert > > Cc: stlevy@cisco.com; jryang@cisco.com; SIP List > > Subject: Re: [SIP] draft-levy-sip-diversion-00.txt > > > > > There are two reasons that the To: header is insufficient to provide > > > Diversion information: > > > 1) The To: header may contain a private URL. > > > 2) Even if the To: header contains a public URL, when there are multiple > > > Diversions, the To header would not reflect the information on all the > > > Diversions that occurred. For example, the third-party application service > > > provider may (typically) want to see information on the final Diversion that > > > occurred (instead of the first Diversion). > > > > > > Here's a SIP username style example of (1) using a night service: > > > Assume that 2 pizza delivery companies, PapaJohns and Dominos, both > > > contract with the third-party night service company, NightServ.com. PapaJohns > > > contracts with NightService.com to provide night service for > > > pizza@papajohns.com. > > > Dominos contracts with NightService.com to provide night service for > > > pizza@dominos.com. The Diversion header is inserted by the PapaJohn/Domino's > > > proxy on call forward time-of-day to nightserv.com. > > > > > > Now, when Alice sends "INVITE pizza@proxy.ispA.com", her proxy could > > > resolve to > > > > > > "pizza@papajohns.com". However, when Bob sends "INVITE > > > pizza@proxy.ispB.com", > > > his proxy could resolve to "pizza@dominos.com". Specifically notice that the > > > contents of the To: header (pizza@proxy.ispA.com or pizza@proxy.ispB.com) > > > did not provide sufficient information to the third-party night service provider to > > > > > > be able to respond intelligently with "Hello, this is PapaJohns" or "Hello, > > > this is Dominos". > > > > > > Here's a PSTN style example of (1) using a third-party voicemail service: > > > A third-party voicemail server may provide voicemail service for 111-555-1234 > > > and 222-555-1234. When Alice calls "INVITE 1234@proxy.ispA.com", > > > proxy.ispA.com expands the number to 111-555-1234. When Bob calls > > > "INVITE 1234@proxy.ispB.com", proxy.ispB.com expands the number to > > > 222-555-1234. Notice that, on Call Forward No Answer, the To: header > > > > > > (1234@proxy.ispA.com or 1234@proxy.ispB.com) does not contain > > > > > > sufficient information to forward to the appropriate voice mailbox. > > > > > > When a request (INVITE) arrives at a SIP entity, only the Request-URI (not the > > > To: header) is "guaranteed" to be locally understood by that entity. (If the > > > Request-URI is not understood, the PDU would be 404ed). Thus, in general, the > > > To: header is only useful for determining uniqueness of a transaction (as part > > > of the four-tuple: To:, From:, Call-ID, CSeq:) and is not useful for triggering > > > > > > called feature logic. In the general case, the Request-URI (and not the > > > To: header) should be used to trigger called feature logic. That's why the > > > Diversion header copies the contents of the Request-URI when the Diversion > > > occurred. > > > > > > Thanks again for your help! > > > Bryan > > > > > > _______________________________________________ > > > SIP mailing list > > > SIP@lists.bell-labs.com > > > http://lists.bell-labs.com/mailman/listinfo/sip > > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Oct 13 17:22:11 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA12092 for ; Fri, 13 Oct 2000 17:22:08 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E279144354; Fri, 13 Oct 2000 16:22:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 17C2244336 for ; Fri, 13 Oct 2000 16:22:00 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id RAA19722; Fri, 13 Oct 2000 17:23:42 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <4WS2XM98>; Fri, 13 Oct 2000 17:17:54 -0400 Message-ID: From: Jonathan Rosenberg To: "'Brett Tate'" , "'Neil Deason'" Cc: "'sip-implementors@cs.columbia.edu'" , "'sip@lists.bell-labs.com'" Subject: RE: [SIP] Incorrect behaviour when using a local outbound proxy MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 13 Oct 2000 17:17:46 -0400 > -----Original Message----- > From: Brett Tate [mailto:brett@broadsoft.com] > Sent: Friday, October 13, 2000 12:32 PM > To: Neil Deason > Cc: sip-implementors@cs.columbia.edu; sip@lists.bell-labs.com > Subject: Re: [SIP] Incorrect behaviour when using a local > outbound proxy > > > > > > In testing labs I am seeing a worrying number of UA > > > > implementations making the same mistake of sending requests > > > > to a Proxy where the Request-URI is in the form > > > > sip:user@. I think some of the confusion may > > > > be traced back to early SIP message flows which showed this > > > > behaviour. I urge implementers to rectify this situation as > > > > we are seeing this cause a great deal of confusion to > > > > the first commercial adopters of SIP technology. These people > > > > are not SIP protocol experts and just expect this technology > > > > to work. > > > > > > > > It is often seen when using a local out bound proxy. The > > > > situation is that the UA takes a configuration parameter > > > > for the local proxy. You can then dial by keying in just the > > > > user part of a SIP URL. The UA then builds a complete URL by > > > > adding the Proxy's address and sends the message to the proxy. > > > > The Proxy then receives an INVITE of the form > > > > sip:user@proxy-ip - according to the protocol spec the Proxy > > > > will route this request to the server at the given IP address. > > > > This is obviously itself so an illegal loop is created. A > > > > > > An outbound proxy for userA can be configured > > > to translate upon a received outgoing message > > > from known userA however it wishes. UserA > > > dialing *69 on a phone can be sent to outbound > > > proxy with Request-URI of *69@outboundProxy-Ip. > > > Assuming the outbound proxy knows userA, it can > > > change the Request-URI into the last "known" > > > user@host that called userA. > > > > According to the SIP spec sip:*69@outboundProxy-Ip > > does not map onto the last incoming caller's sip URL > > this is specialised logic. It may exist but a truly > > interoperable UA must still be able to work if it > > doesn't. > > > > The point I was really trying to make is that a UA > > should not write Request-URIs out to be the destination > > of where they are being sent in the hostport when using > > a local outbound proxy. > > > > Say I want to dial sip:jsmith@another-domain.com but > > the UA configured with a local outbound proxy setting > > of proxy.this-domain.com actually sends the INVITE > > out as:- > > > > INVITE sip:jsmith@proxy.this-domain.com SIP/2.0 > > To: sip:jsmith@another-domain.com > > From: sip:PoorUser@this-domain.com > > .... > > > > A proxy receiving the above request assumes > that the user is trying to reach the Request-URI. > By becoming aware the need to act as an > outbound proxy, the Request-URI can be changed > by the outbound proxy. When any proxy or user > agent receives the initial INVITE, the user@hostport > of "To" should only really mean what was supposedly > dialed/entered to reach you (and call-leg identification). > > If the user agent was trying to reach > sip:jsmith@another-domain.com, > it should be in the Request-URI. And the > message should be sent to > proxy.this-domain.com if it wants to use it > as an outbound proxy. There are two cases here that are being intermixed. In case one, the originating UA wants to reach a user with a specific username AND domain name, and that domain name is totally outside the network of the originating UA. For example, if I want to reach joe@foo.com, and I'm within bar.com. In case two, I'm on a gateway and I dial a number. There is not really a destination domain associated with this number. What should it be? In case one, it is absolutely INCORRECT to modify the request URI to be my local domain. When sending the request to my local proxy, it would look like: INVITE sip:joe@foo.com SIP/2.0 and then be sent NOT to foo.com, but to my local proxy. Changing the request URI to bar.com to reach the local proxy is an error; user joe is not within that namespace. However, in case two, the destination number can rightly be considered to be within the domain of the orginating caller. Thats because it knows how to reach phone numbers. Remember, just because a proxy for bar.com gets a request with a URI thats some-name@bar.com, does not mean a user some-name must have registered with a REGISTER. It means that the proxy for bar.com knows what to do with the user some-name. Its perfectly fine for this proxy to treat numbers in the user part of its domain as telephone numbers, especially if they are indicated as such with user=phone, and then route them to a gateway with some phone routing database. So, in that case, if I'm in bar.com, and I dial a number - 5551212, its reasonable to send that to my own proxy with the URI 5551212@bar.com. In this case its not even really a local-outbound proxy anymore. Using the IP address of the proxy is also OK IFF the proxy is configured to know that requests with that given IP address represent "its domain of ownership". Using the domain name is better for lots of reasons, though, including SRV usage. Whether this is allowed is a matter of configuration. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sat Oct 14 01:17:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA19359 for ; Sat, 14 Oct 2000 01:17:02 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4C6F844339; Sat, 14 Oct 2000 00:17:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cybertron.div8.net (el05-24-131-150-91.ce.mediaone.net [24.131.150.91]) by lists.bell-labs.com (Postfix) with ESMTP id C63AA44336 for ; Fri, 13 Oct 2000 18:26:24 -0400 (EDT) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for sip@lists.bell-labs.com; Fri, 13 Oct 2000 18:26:19 -0500 (CDT) From: Billy Biggs To: Jonathan Rosenberg Cc: SIP Mailing List Message-ID: <20001013182619.A15316@div8.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i In-Reply-To: ; from jdrosen@dynamicsoft.com on Tue, Oct 10, 2000 at 01:58:29AM -0400 Subject: [SIP] More on Mid-Call Redirects Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 13 Oct 2000 18:26:19 -0500 Jonathan Rosenberg (jdrosen@dynamicsoft.com): > > If I get redirected (say a 302) on a re-INVITE or BYE request on > > an active call-leg end, and the call-leg has a Route, what do I > > do? > > This should really never happen. I don't think there is any happy > solution in this case. Is there a specific scenario you were thinking > of? The text in the description of a 305 response seems to imply that it will happen mid-call ("The recipient is expected to repeat _this_ _single_request_ via the proxy"). This scares me. I think it should also be specified in the bis draft that clients MUST NOT list the address of a redirect server in a 200 response to an INVITE. The current text says that clients MUST put the address they are most directly reachable at, but indicates that this may be a proxy if they are behind a firewall. I'd argue that clients might be tempted to put in URIs that they have successfully registered at as their Contact in order to help promote address safety if they are behind a NAT. But if this registration is at a redirect server, things will break. Another scenario is if a proxy gets reconfigured mid-call to be a redirect server, and this proxy is in the route. I really really really do not want to have to map Routes and Contact addresses to CSeq numbers. Is the solution to just hope this never ever happens? -- Billy Biggs, 3Com Email: Billy_Biggs@3com.com http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sat Oct 14 10:27:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA03498 for ; Sat, 14 Oct 2000 10:27:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5237B44345; Sat, 14 Oct 2000 09:27:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from wiproecmx2.wipro.com (wiproecmx2.wipro.com [164.164.31.6]) by lists.bell-labs.com (Postfix) with ESMTP id 7F9CF44336 for ; Sat, 14 Oct 2000 09:26:08 -0400 (EDT) Received: from ecvwall1.wipro.com (ecvwall1.wipro.com [192.168.181.23]) by wiproecmx2.wipro.com (8.9.3/8.9.3) with SMTP id UAA18769 for ; Sat, 14 Oct 2000 20:05:12 GMT Received: from wslexch.wipsys.soft.net ([192.219.223.59]) by kmglmail.mail.wipro.com (Netscape Messaging Server 3.6) with ESMTP id AAA3968; Sat, 14 Oct 2000 19:55:50 +0530 Received: by wslexch.mail.wipro.com with Internet Mail Service (5.5.2650.21) id <4YBMY0G1>; Sat, 14 Oct 2000 19:57:26 +0530 Message-ID: <53BA505BEC72D21194400000E216A24403620FBF@wslexch.mail.wipro.com> From: Subramania Sivaram To: sip@lists.bell-labs.com, Henning Schulzrinne , Jonathan Rosenberg MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Subject: [SIP] draft-ietf-sip-rfc2543bis-01.txt: General questions Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sat, 14 Oct 2000 19:57:25 +0530 While reading the above doc, I had the following questions. [I am sorry if these are very basic, owing to my rather short association with this working group.] - What is maddr & when/ why would it exist in a SIP URI ?? - Section 4.2.6: What exactly are multicast registrations & why are they sent to "all SIP servers" multicast address ?? - Sec 4.2.6, Page 32 There is a sentence which says "a traveler sip:alice@acme.com (To) might register under the Request-URI sip:atlanta.hiayh.org , with the former as the To header field and the latter as the Request-URI." When a request is sent to the SIP proxy at acme.com (for alice@acme.com), how does it know to forward it to sip:atlanta.hiayh.org ?? In general, how does one SIP proxy know which is the next proxy to send to (in other words how is the proxy sequence determined) ?? - Sec 6.34.2, There is a sentence which reads "Since the URIs contained in the Record-Route header fields are not useful for the reverse request path..." Why is this the case ?? - Can any request be forked ?? e.g. a BYE on a premature disconnect from the caller (only INVITE seems to be used in most examples). - What are the possible uses of a SIP proxy ?? As a registrar, a firewall, what else ?? I believe it can be used for implementing features e.g. ACD, but most features seem to exist at the UA (is this correct ??). Lastly, a general comment. I find that procedures (behaviour of an entity like a proxy or a UAS etc.- its processing of requests and responses) is spread over the complete document, which makes it quite difficult to understand, especially because the document is quite large. e.g. the behaviour of a proxy on receipt of ACK is presented in Sec 4.2.2 ACK in detail, as well as in different parts of Sec 12. In general, processing details are distributed between Sections 1, 4, 10, portions of 6, 10, 11, 12 (leaving out security). Are there any plans to re-organise the document in the future, so that all procedures are in one place (more like ITU-T standards, which I feel are easier to read) ?? Thanks, Sivaram. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sat Oct 14 14:51:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA04724 for ; Sat, 14 Oct 2000 14:51:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6088B4435C; Sat, 14 Oct 2000 13:51:03 -0400 (EDT) Delivered-To: sip@share.research.bell-labs.com Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by lists.bell-labs.com (Postfix) with SMTP id C49A044336 for ; Sat, 14 Oct 2000 12:42:05 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Sat Oct 14 13:41:54 EDT 2000 Received: by lists.bell-labs.com (Postfix) id AD1EC44380; Sat, 14 Oct 2000 13:28:44 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ans.ih.lucent.com (ans.ih.lucent.com [135.2.78.5]) by lists.bell-labs.com (Postfix) with SMTP id 520184437D for ; Sat, 14 Oct 2000 13:28:44 -0400 (EDT) Received: by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id MAA21859; Sat, 14 Oct 2000 12:28:29 -0500 Cc: Vijay Gurbani Received: from lucent.com by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id MAA21856; Sat, 14 Oct 2000 12:28:23 -0500 Message-ID: <39E897B7.9E2A6B96@lucent.com> From: "Vijay K. Gurbani" Reply-To: vkg@lucent.com Organization: Intelligent Network/Messaging Systems & Internet Software Group X-Mailer: Mozilla 4.61 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com, sip-implementors@cs.columbia.edu Original-CC: Vijay Gurbani Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] CANCEL/200 OK/BYE Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sat, 14 Oct 2000 12:28:23 -0500 Content-Transfer-Encoding: 7bit All: The bis RFC says that when an INVITE is to be terminated (either by the UAC timing out after sending 7 requests out or by the caller associated with the UAC hanging up) a BYE or CANCEL request may be sent; it recommends sending both. I know the reason BYE is preferred is if CANCEL and 200 OK "cross each other on the wire". But what if they don't? Why send the BYE if after sending a CANCEL, the UAC gets a 487 Request Terminated (which it will have to ACK, of course). There are two cases (let's assume a lossless network with in-order delivery of packets): Case 1: CANCEL and 200 OK DO NOT "cross each other on the wire": UAC INVITE-------> <----------- 100 Trying <----------- 180 Ringing CANCEL ------> <----------- 487 Request Terminated ACK----------> <------------ 200 OK (CSeq: xxx CANCEL) As far as I can see, no need to send BYE here. (Last 4 exchanges are as per the behavior of a UAS when it gets a CANCEL and has NOT send a final response -- Section 4.2.5 "CANCEL") Case 2: CANCEL and 200 OK DO "cross each other on the wire": UAC INVITE-------> <----------- 100 Trying <----------- 180 Ringing CANCEL-----> <------ 200 OK (CSeq: xxx INVITE) ACK ---------> BYE ---------> <------------- 200 OK (CSeq: xxx BYE) Clearly, here, the CANCEL has no effect on the state machine of the UAS since it has already sent out the final response. The UAC, on receiving the 200 OK notes that this is OK'ing an INVITE, thus the CANCEL it send out has no meaning. It ACKs the 200 OK and THEN sends a BYE. So, it looks to me as if a CANCEL results in a 487 Request Terminated, a BYE may not be sent. Is that accurate? Comments? What are other implementors implementing? If, as the RFC suggests, both a CANCEL and BYE were to be sent, then some timing issues arise in a real-world network which is lossless. These timing issues may be crucial for stateful proxies, with their need to maintain state for 32 seconds after sending an ACK to a non-200 response. Assume that the UACs discussed in cases 1 and 2 above were branches of a forking proxy. Then, in case 1, sending a BYE after getting a 200 OK to a CANCEL seems redundant; and in case 2, should the proxy wait 32 seconds after sending the ACK (to ensure that it got there) before sending the BYE? 32 seconds seems to be a lot of time to wait before tearing the call down. Comments? Thanks, - vijay -- Vijay K. Gurbani vkg@lucent.com vkg@research.bell-labs.com vkg@acm.org Internet Software Group/Intelligent Network and Messaging Systems Lucent Technologies/Bell Labs Innovations, 263 Shuman Blvd, Rm 1A-413 Naperville, Illinois 60566 Voice: +1 630 224 0216 Fax: +1 630 713 0184 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sun Oct 15 14:33:59 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA09655 for ; Sun, 15 Oct 2000 14:33:59 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id CDE6C44344; Sun, 15 Oct 2000 13:34:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from guardian1.tlv.radvision.com (unknown [212.143.185.30]) by lists.bell-labs.com (Postfix) with ESMTP id 56CB44433A for ; Sun, 15 Oct 2000 13:33:54 -0400 (EDT) Received: from nt-mail.tlv.radvision.com ([172.20.2.100]) by guardian1.tlv.radvision.com (Post.Office MTA v3.5.3 release 223 ID# 0-0U10L2S100V35) with ESMTP id com; Sun, 15 Oct 2000 21:32:39 +0200 Received: by NT-MAIL with Internet Mail Service (5.5.2650.21) id <48RJ5TC0>; Sun, 15 Oct 2000 20:34:03 +0200 Message-ID: From: Itamar Gilad To: "'Chris Harris'" , sip@lists.bell-labs.com, "'SIPForum list'" Subject: RE: [SIP] JAIN SIP Specification MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sun, 15 Oct 2000 20:34:02 +0200 Hi Chris, a few comments: Requirement 3.3.1.2 (JAIN SIP Events) names only SIP messages as SIP events. RFC2543 specifies that a TCP connection-close event should sometimes be interpreted as reception of CANCEL, which might qualify it as an event for the purposes of JAIN. This seems to be a very comprehensive API. I didn't count, but I estimate you have over 500 methods listed (many of which throw exceptions) in dozens of classes. This is only the part of the API that deals with SIP messages. In real life a SIP stack needs to export APIs also for calls, transactions, SDP and more. Implementing such an extensive API on a system with limited resources may not be feasible in the near future. Also, it's very likely that many SIP-capable devices will not require the entire scope of the specified API as they may not use all message types and headers. Any thoughts on generating a specification for a minimal/mid-level JAIN API implementation, perhaps in the spirit of RFC2543 appendix A? Regards, Itamar Gilad > -----Original Message----- > From: Chris Harris [mailto:charris@dynamicsoft.com] > Sent: Fri, October 13, 2000 12:52 PM > To: sip@lists.bell-labs.com > Subject: [SIP] JAIN SIP Specification > > > Dear SIP WG, > > The JAIN SIP Specification is available from today for Public > Review on > the Java website. It can be found at > http://java.sun.com/aboutJava/communityprocess/review/jsr032/i ndex.html. The Public Review will close on 28th November. Regards, Chris Haris _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sun Oct 15 19:07:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA11062 for ; Sun, 15 Oct 2000 19:06:59 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id F01814433D; Sun, 15 Oct 2000 18:07:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 77D754433A for ; Sun, 15 Oct 2000 18:06:14 -0400 (EDT) Received: from dynamicsoft.com ([212.120.151.44]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id TAA00839; Sun, 15 Oct 2000 19:08:12 -0400 (EDT) Message-ID: <39EA3865.D689E620@dynamicsoft.com> From: Chris Harris Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Itamar Gilad Cc: sip@lists.bell-labs.com, "'SIPForum list'" Subject: Re: [SIP] JAIN SIP Specification References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 16 Oct 2000 00:06:13 +0100 Content-Transfer-Encoding: 7bit Hello Itamar, Thanks for the comments. I have included responses below. Regards, Chris Itamar Gilad wrote: > Hi Chris, > > a few comments: > > Requirement 3.3.1.2 (JAIN SIP Events) names only SIP messages as SIP events. > RFC2543 specifies that a TCP connection-close event should sometimes be > interpreted as reception of CANCEL, which might qualify it as an event for > the purposes of JAIN. The JAIN SIP API is independent of the underlying transport, and if something happens at the transport level, such as your example, then it would be up to the JAIN SIP implementation to interpret the underlying event, and generate an appropriate SIP message to send to JAIN SIP applications. > > > This seems to be a very comprehensive API. I didn't count, but I estimate > you have over 500 methods listed (many of which throw exceptions) in dozens > of classes. This is only the part of the API that deals with SIP messages. > In real life a SIP stack needs to export APIs also for calls, transactions, > SDP and more. Implementing such an extensive API on a system with limited > resources may not be feasible in the near future. Also, it's very likely > that many SIP-capable devices will not require the entire scope of the > specified API as they may not use all message types and headers. Any > thoughts on generating a specification for a minimal/mid-level JAIN API > implementation, perhaps in the spirit of RFC2543 appendix A? Yes - it is true that there are many classes and methods. This is for the benefit of the API user - it removes the need for users to parse the standard headers, reduces the risk of users using incorrect header values, and ensures greater application portability. The API certainly could have been defined with just one generic Header and Message class, but that would that be a very helpful SIP API? The JAIN SIP API does not permit applications to have direct access to transactions. An application is given a transaction id as a reference by the JainSipProvider, and it can use the reference to invoke send methods on the JainSipProvider - but the Provider has control over transactions and may throw an exception if an application attempts to do something it doesn't like. There is no notion of call control in this API - it is intended only as a Java interface to SIP. Within the JAIN framework, call control is handled by JCC (Java Call Control) which is an Application Level API - the JAIN SIP API needs to fit beneath this call control API. There have been several requests for a higher level API for SIP-specific services, but whether this will be within the JAIN framework is not clear. This high level API could sit on top of the current API - or could be used instead - making it a candidate for the minimal/mid-level JAIN API you suggest. I would be very interested to hear suggestions from people about this. As for SDP, I have created classes for JAIN SDP which can be used across all the JAIN Protocol API's, but their use is not mandated by the JAIN SIP API - the body is simply an Object (whose toString() method will be called). In hindsight, the SDP classes should probably have been included in the Javadoc and jar-file, but since these classes are within the scope of more than just this API, I postponed their inclusion. > > > Regards, > > Itamar Gilad > > > -----Original Message----- > > From: Chris Harris [mailto:charris@dynamicsoft.com] > > Sent: Fri, October 13, 2000 12:52 PM > > To: sip@lists.bell-labs.com > > Subject: [SIP] JAIN SIP Specification > > > > > > Dear SIP WG, > > > > The JAIN SIP Specification is available from today for Public > > Review on > > the Java website. It can be found at > > http://java.sun.com/aboutJava/communityprocess/review/jsr032/i > ndex.html. > > The Public Review will close on 28th November. > > Regards, > Chris Haris > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sun Oct 15 23:43:00 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA14638 for ; Sun, 15 Oct 2000 23:43:00 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 034BE4433D; Sun, 15 Oct 2000 22:43:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mars.hss.co.in (unknown [202.54.26.197]) by lists.bell-labs.com (Postfix) with ESMTP id BD56D4433A for ; Sun, 15 Oct 2000 22:42:13 -0400 (EDT) Received: from sampark.hss.hns.com (sampark [139.85.229.22]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id e9G3gHC01542; Mon, 16 Oct 2000 09:12:19 +0530 (IST) Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 6525697A.00132D75 ; Mon, 16 Oct 2000 08:59:28 +0530 X-Lotus-FromDomain: HSSBLR From: archow@hss.hns.com To: Chris Harris Cc: Itamar Gilad , sip@lists.bell-labs.com, "'SIPForum list'" Message-ID: <6525697A.00132CDF.00@sampark.hss.hns.com> Subject: Re: [SIP] JAIN SIP Specification Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 16 Oct 2000 08:59:25 +0530 > The JAIN SIP API does not permit applications to have direct access to > transactions. An application is given a transaction id as a reference by the > JainSipProvider, and it can use the reference to invoke send methods on the > JainSipProvider - but the Provider has control over transactions and may throw > an exception if an application attempts to do something it doesn't like. Chris, at this point , another question comes to mind: What if my application does not need to keep transaction state ? If I were to write a JAIN SIP wrapper on a core stack, I dont mind forming a transaction id in JainSipProvider, but does it also need me to correlate the transaction with other future messages ? This may not be in the scope of my application, which may not be interested in even keeping transaction state. Regds Arjun -- Arjun Roychowdhury @ Hughes Software Systems _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sun Oct 15 23:50:00 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA14781 for ; Sun, 15 Oct 2000 23:50:00 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 77D114433D; Sun, 15 Oct 2000 22:50:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mars.hss.co.in (unknown [202.54.26.197]) by lists.bell-labs.com (Postfix) with ESMTP id 1A54D4433A for ; Sun, 15 Oct 2000 22:49:22 -0400 (EDT) Received: from sampark.hss.hns.com (sampark [139.85.229.22]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id e9G3nlC01761; Mon, 16 Oct 2000 09:19:47 +0530 (IST) Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 6525697A.0011D49E ; Mon, 16 Oct 2000 08:44:45 +0530 X-Lotus-FromDomain: HSSBLR From: archow@hss.hns.com To: discussion@sipforum.org Cc: sip@lists.bell-labs.com, "'SIPForum list'" Message-ID: <6525697A.0011D47E.00@sampark.hss.hns.com> Subject: Re: [SIPFORUM] Re: [SIP] JAIN SIP Specification Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 16 Oct 2000 08:44:44 +0530 Chris, as you correctly stated, I would not be the last (nor the first) to ask about any abstraction for the current API set. I suggest you add a *small* section to the Introduction of JAIN-SIP explicitly higlighting its scope and the justification of why there is no CC in the current state. This would quell the most obvious question that comes to everyone's mind, avoiding repetitive explanation . Regds Arjun -- Arjun Roychowdhury @ Hughes Software Systems Chris Harris on 10/16/2000 04:36:13 AM Please respond to discussion@sipforum.org To: Itamar Gilad cc: sip@lists.bell-labs.com, "'SIPForum list'" Subject: [SIPFORUM] Re: [SIP] JAIN SIP Specification Hello Itamar, Thanks for the comments. I have included responses below. Regards, Chris Itamar Gilad wrote: > Hi Chris, > > a few comments: > > Requirement 3.3.1.2 (JAIN SIP Events) names only SIP messages as SIP events. > RFC2543 specifies that a TCP connection-close event should sometimes be > interpreted as reception of CANCEL, which might qualify it as an event for > the purposes of JAIN. The JAIN SIP API is independent of the underlying transport, and if something happens at the transport level, such as your example, then it would be up to the JAIN SIP implementation to interpret the underlying event, and generate an appropriate SIP message to send to JAIN SIP applications. > > > This seems to be a very comprehensive API. I didn't count, but I estimate > you have over 500 methods listed (many of which throw exceptions) in dozens > of classes. This is only the part of the API that deals with SIP messages. > In real life a SIP stack needs to export APIs also for calls, transactions, > SDP and more. Implementing such an extensive API on a system with limited > resources may not be feasible in the near future. Also, it's very likely > that many SIP-capable devices will not require the entire scope of the > specified API as they may not use all message types and headers. Any > thoughts on generating a specification for a minimal/mid-level JAIN API > implementation, perhaps in the spirit of RFC2543 appendix A? Yes - it is true that there are many classes and methods. This is for the benefit of the API user - it removes the need for users to parse the standard headers, reduces the risk of users using incorrect header values, and ensures greater application portability. The API certainly could have been defined with just one generic Header and Message class, but that would that be a very helpful SIP API? The JAIN SIP API does not permit applications to have direct access to transactions. An application is given a transaction id as a reference by the JainSipProvider, and it can use the reference to invoke send methods on the JainSipProvider - but the Provider has control over transactions and may throw an exception if an application attempts to do something it doesn't like. There is no notion of call control in this API - it is intended only as a Java interface to SIP. Within the JAIN framework, call control is handled by JCC (Java Call Control) which is an Application Level API - the JAIN SIP API needs to fit beneath this call control API. There have been several requests for a higher level API for SIP-specific services, but whether this will be within the JAIN framework is not clear. This high level API could sit on top of the current API - or could be used instead - making it a candidate for the minimal/mid-level JAIN API you suggest. I would be very interested to hear suggestions from people about this. As for SDP, I have created classes for JAIN SDP which can be used across all the JAIN Protocol API's, but their use is not mandated by the JAIN SIP API - the body is simply an Object (whose toString() method will be called). In hindsight, the SDP classes should probably have been included in the Javadoc and jar-file, but since these classes are within the scope of more than just this API, I postponed their inclusion. > > > Regards, > > Itamar Gilad > > > -----Original Message----- > > From: Chris Harris [mailto:charris@dynamicsoft.com] > > Sent: Fri, October 13, 2000 12:52 PM > > To: sip@lists.bell-labs.com > > Subject: [SIP] JAIN SIP Specification > > > > > > Dear SIP WG, > > > > The JAIN SIP Specification is available from today for Public > > Review on > > the Java website. It can be found at > > http://java.sun.com/aboutJava/communityprocess/review/jsr032/i > ndex.html. > > The Public Review will close on 28th November. > > Regards, > Chris Haris > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 16 00:17:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA14970 for ; Mon, 16 Oct 2000 00:17:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2CCE84433D; Sun, 15 Oct 2000 23:17:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id EE0FB4433A for ; Sun, 15 Oct 2000 23:16:03 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA01335; Mon, 16 Oct 2000 00:12:15 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <4WS2XNW5>; Mon, 16 Oct 2000 00:06:22 -0400 Message-ID: From: Jonathan Rosenberg To: "'vkg@lucent.com'" , "'sip@lists.bell-labs.com'" , "'sip-implementors@cs.columbia.edu'" Subject: RE: [SIP] CANCEL/200 OK/BYE MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 16 Oct 2000 00:06:21 -0400 > -----Original Message----- > From: Vijay K. Gurbani [mailto:vkg@lucent.com] > Sent: Saturday, October 14, 2000 1:28 PM > To: sip@lists.bell-labs.com; sip-implementors@cs.columbia.edu > Cc: Vijay Gurbani > Subject: [SIP] CANCEL/200 OK/BYE > > > All: > > The bis RFC says that when an INVITE is to be terminated > (either by the > UAC timing out after sending 7 requests out or by the caller > associated > with the UAC hanging up) a BYE or CANCEL request may be sent; it > recommends sending both. > > I know the reason BYE is preferred is if CANCEL and 200 OK "cross each > other on the wire". But what if they don't? Why send the > BYE if after > sending a CANCEL, the UAC gets a 487 Request Terminated (which it will > have to ACK, of course). There are two cases (let's assume a lossless > network with in-order delivery of packets): > > Case 1: CANCEL and 200 OK DO NOT "cross each other on the wire": > > UAC > INVITE-------> > <----------- 100 Trying > <----------- 180 Ringing > CANCEL ------> > <----------- 487 Request Terminated > ACK----------> > <------------ 200 OK (CSeq: xxx CANCEL) > > As far as I can see, no need to send BYE here. (Last 4 > exchanges are > as per the behavior of a UAS when it gets a CANCEL and has > NOT send a > final response -- Section 4.2.5 "CANCEL") > > Case 2: CANCEL and 200 OK DO "cross each other on the wire": > > UAC > INVITE-------> > <----------- 100 Trying > <----------- 180 Ringing > CANCEL-----> <------ 200 OK (CSeq: xxx INVITE) > ACK ---------> > BYE ---------> > <------------- 200 OK (CSeq: xxx BYE) > > Clearly, here, the CANCEL has no effect on the state machine of the > UAS since it has already sent out the final response. The UAC, on > receiving the 200 OK notes that this is OK'ing an INVITE, thus the > CANCEL it send out has no meaning. It ACKs the 200 OK and > THEN sends > a BYE. > > So, it looks to me as if a CANCEL results in a 487 Request Terminated, > a BYE may not be sent. Is that accurate? Comments? > > What are other implementors implementing? I think the most correct behavior is to send a CANCEL. If you get a final response to the INVITE that is 200 class, then send BYE. Where in the spec does it say to send both? -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 16 00:17:54 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA14981 for ; Mon, 16 Oct 2000 00:17:54 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2F49B44364; Sun, 15 Oct 2000 23:17:11 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id E2C1B4433A for ; Sun, 15 Oct 2000 23:16:40 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA01355; Mon, 16 Oct 2000 00:17:49 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <4WS2XNW9>; Mon, 16 Oct 2000 00:11:56 -0400 Message-ID: From: Jonathan Rosenberg To: "'Subramania Sivaram'" , "'sip@lists.bell-labs.com'" Subject: RE: [SIP] draft-ietf-sip-rfc2543bis-01.txt: General questions MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 16 Oct 2000 00:11:54 -0400 > -----Original Message----- > From: Subramania Sivaram [mailto:sivaram.subr@wipro.com] > Sent: Saturday, October 14, 2000 10:27 AM > To: sip@lists.bell-labs.com; Henning Schulzrinne; Jonathan Rosenberg > Subject: [SIP] draft-ietf-sip-rfc2543bis-01.txt: General questions > > > While reading the above doc, I had the following questions. > [I am sorry if > these > are very basic, owing to my rather short association with this working > group.] > > - What is maddr & when/ why would it exist in a SIP URI ?? maddr specifies the specific IP address to send to. It exists when the DNS translation of the address in the URI cannot be relied upon, but a domain name needs to be there for other purposes, like application logic. > > - Section 4.2.6: What exactly are multicast registrations & > why are they > sent to > "all SIP servers" multicast address ?? REGISTERs sent via multicast. Multicast is used since it allows for autoconfigurations. A well-known multicast group must be used to eliminate a configured address. > > - Sec 4.2.6, Page 32 > There is a sentence which says > "a traveler sip:alice@acme.com (To) might register under the > Request-URI > sip:atlanta.hiayh.org , with the former as the To > header field and the latter as the Request-URI." > > When a request is sent to the SIP proxy at acme.com (for > alice@acme.com), > how does it know to forward it to sip:atlanta.hiayh.org ?? > In general, how does one SIP proxy know which > is the next proxy to send to (in other words how is the proxy sequence > determined) ?? Its a matter of local configuration. The spec defines some standard approaches, such as using a registration database, or forwarding to the address in the request URI. ANything else you like is possible. > > - Sec 6.34.2, There is a sentence which reads > "Since the URIs contained in the Record-Route header fields > are not useful for the reverse request path..." > Why is this the case ?? Because they refer to the called party. If they are used by the called party in requests back to the caller, they are indicating the wrong person. > > - Can any request be forked ?? e.g. a BYE on a premature > disconnect from the > caller (only > INVITE seems to be used in most examples). Any request can be forked. > > - What are the possible uses of a SIP proxy ?? As a registrar, > a firewall, what else ?? I believe it can be used for implementing > features e.g. ACD, but most features seem to exist at the UA (is this > correct ??). Routing. Namespace partitioning. Scale. Logging/billing, etc. See: http://www.cs.columbia.edu/~jdrosen/papers/devconf_spring2000_proxies.ppt which explains in details why you want proxies. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 16 01:18:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA17485 for ; Mon, 16 Oct 2000 01:18:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 01AB24433A; Mon, 16 Oct 2000 00:18:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 579A944338 for ; Mon, 16 Oct 2000 00:17:58 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA01499; Mon, 16 Oct 2000 01:19:52 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <4WS2XNYC>; Mon, 16 Oct 2000 01:13:58 -0400 Message-ID: From: Jonathan Rosenberg To: "'Rakesh Jain'" , "'sip@lists.bell-labs.com'" Subject: RE: [SIP] some doubts.... MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 16 Oct 2000 01:13:58 -0400 > -----Original Message----- > From: Rakesh Jain [mailto:rak_jain@hotmail.com] > Sent: Thursday, October 12, 2000 12:55 PM > To: sip@lists.bell-labs.com > Subject: [SIP] some doubts.... > > > > Hi, > > I am having some doubts in RFC2543, under section 6-12 CALL-ID, > The statement given in this section is : > > "If the user is already a member of the conference and the > conference parameters contained in the session description > have not changed, a callee user agent server MAY > silently accept the call, regardless of the Call-ID." > > In this case, will Call-ID in second call be same as > existing Call-ID or it can differ With the existing Call-ID. > What I understtod from the sentence is it can be same or > Different also. > Am I right? Yes. In the case of the same Call-ID, this would basically be the case of a re-invite, where there is no change in the session params. This generally wouldn't happen, but its something you should be prepared for. Session timer discusses this in a bit more detail. In the case of a different Call-ID, you would really only see this for multicast conferences, like mbone. In this case, its like you got invited by one person, and then got a totally different invitation from someone else for the same session. Since you're already in it, no point in bother the user. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 16 01:31:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA19403 for ; Mon, 16 Oct 2000 01:31:02 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 19B514433A; Mon, 16 Oct 2000 00:31:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from broadsoft.com (broadsoft.com [161.58.239.68]) by lists.bell-labs.com (Postfix) with ESMTP id A97AE44338 for ; Mon, 16 Oct 2000 00:30:07 -0400 (EDT) Received: from tate ([216.181.56.35]) by broadsoft.com (8.8.8) id BAA39416; Mon, 16 Oct 2000 01:30:03 -0400 (EDT) Message-ID: <0a2501c03732$51052cc0$3202a8c0@broadsoft.com> From: "Brett Tate" To: "SIPbell-labs" 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 Subject: [SIP] Option-tag value for rfc2976 ? Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 16 Oct 2000 01:31:21 -0400 Content-Transfer-Encoding: 7bit What is rfc2976's option-tag value? Are new SIP extension methods such as INFO valid in the Supported header? If not, can the Allow header be included in INVITE request to indicate what methods the caller supports? _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 16 02:40:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA29760 for ; Mon, 16 Oct 2000 02:40:00 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8CE994433A; Mon, 16 Oct 2000 01:40:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sumo.vocaltec.co.il (sumo.vocaltec.co.il [199.203.72.1]) by lists.bell-labs.com (Postfix) with ESMTP id 545D644338 for ; Mon, 16 Oct 2000 01:39:35 -0400 (EDT) Received: from ilnimo.vocaltec.co.il (ilnimo.vocaltec.co.il [194.90.71.135]) by sumo.vocaltec.co.il (8.9.3/8.9.3) with ESMTP id IAA26705 for ; Mon, 16 Oct 2000 08:39:26 +0200 (IST) From: Joshua_Fox@vocaltec.com To: sip@lists.bell-labs.com X-Mailer: Lotus Notes Release 5.0.3 March 21, 2000 Message-ID: X-MIMETrack: Serialize by Router on ILNimo/Vocaltec_Comm(Release 5.0.3 (Intl)|21 March 2000) at 10/16/2000 08:38:51 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [SIP] SIP, PAM, and Presence Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 16 Oct 2000 08:38:49 +0200 The dynamicsoft white paper on SIP and Presence shows an interesting additional use for the SIP protocol http://www.dynamicsoft.com/resources/pdf/Presence_White_Paper.pdf I wonder what relation SIP-Presence has to PAM, the Presence and Availability Management API that is being put forward by Lucent, Novell, and others (www.pamforum.org). I realize that PAM is an API while SIP is a protocol, but it does not seem at first glance that you might implement PAM with SIP. Is there any info online _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 16 03:22:06 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA00124 for ; Mon, 16 Oct 2000 03:22:05 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 289614436D; Mon, 16 Oct 2000 02:22:08 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from valhalla.marko.net (cx851333-b.irvn1.occa.home.com [24.21.59.175]) by lists.bell-labs.com (Postfix) with ESMTP id 50AA844338 for ; Mon, 16 Oct 2000 02:21:07 -0400 (EDT) Received: (from tsearle@localhost) by valhalla.marko.net (8.10.0/8.10.0) id e9G7L3G04467 for sip@lists.bell-labs.com; Mon, 16 Oct 2000 00:21:03 -0700 From: tsearle@valhalla.marko.net To: sip@lists.bell-labs.com Message-ID: <20001016002102.A23502@valhalla.marko.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i Subject: [SIP] SIP heartbeat Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 16 Oct 2000 00:21:02 -0700 Is there a way to perform a heartbeat in sip so that if either endpoints connection is dropped it can be detected and the call can be properly terminated? Torrey _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 16 04:17:00 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA00533 for ; Mon, 16 Oct 2000 04:17:00 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8E43844370; Mon, 16 Oct 2000 03:17:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from drago1.ubiquity.net (unknown [194.202.146.92]) by lists.bell-labs.com (Postfix) with SMTP id 3A3924436C for ; Mon, 16 Oct 2000 03:16:44 -0400 (EDT) Received: from gecko.ubiquity.co.uk by drago1.ubiquity.net via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 16 Oct 2000 08:17:11 UT Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id JAA18629; Mon, 16 Oct 2000 09:14:53 +0100 (BST) Message-ID: <39EAB8FD.6D02D30D@ubiquity.net> From: Neil Deason Organization: Ubiquity Software Corporation Limited X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: "'Brett Tate'" , "'sip-implementors@cs.columbia.edu'" , "'sip@lists.bell-labs.com'" Subject: Re: [SIP] Incorrect behaviour when using a local outbound proxy References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 16 Oct 2000 09:14:53 +0100 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: [snip] > There are two cases here that are being intermixed. > > In case one, the originating UA wants to reach a user with a specific > username AND domain name, and that domain name is totally outside the > network of the originating UA. For example, if I want to reach joe@foo.com, > and I'm within bar.com. In case two, I'm on a gateway and I dial a number. > There is not really a destination domain associated with this number. What > should it be? Yes - I don't think I was very clear originally in saying the problem I have is with implementations that cannnot deal with reaching a user who's domain is outside their the network. They always re-write the Request-URI to be the local domain, even when this is clearly the wrong thing to do. I would also argue that when an implementation does rewrite the Request-URI to the local domain it is much better to use a domain name than the proxy's IP address. Cheers, Neil -- Ubiquity Software Corporation, UK http://www.ubiquity.net > In case one, it is absolutely INCORRECT to modify the request URI to be my > local domain. When sending the request to my local proxy, it would look > like: > > INVITE sip:joe@foo.com SIP/2.0 > > and then be sent NOT to foo.com, but to my local proxy. Changing the request > URI to bar.com to reach the local proxy is an error; user joe is not within > that namespace. > > However, in case two, the destination number can rightly be considered to be > within the domain of the orginating caller. Thats because it knows how to > reach phone numbers. Remember, just because a proxy for bar.com gets a > request with a URI thats some-name@bar.com, does not mean a user some-name > must have registered with a REGISTER. It means that the proxy for bar.com > knows what to do with the user some-name. Its perfectly fine for this proxy > to treat numbers in the user part of its domain as telephone numbers, > especially if they are indicated as such with user=phone, and then route > them to a gateway with some phone routing database. > > So, in that case, if I'm in bar.com, and I dial a number - 5551212, its > reasonable to send that to my own proxy with the URI 5551212@bar.com. In > this case its not even really a local-outbound proxy anymore. Using the IP > address of the proxy is also OK IFF the proxy is configured to know that > requests with that given IP address represent "its domain of ownership". > Using the domain name is better for lots of reasons, though, including SRV > usage. Whether this is allowed is a matter of configuration. > > -Jonathan R. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 16 05:06:59 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA00921 for ; Mon, 16 Oct 2000 05:06:59 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 41B9E44371; Mon, 16 Oct 2000 04:07:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from drago1.ubiquity.net (unknown [194.202.146.92]) by lists.bell-labs.com (Postfix) with SMTP id C905B4436C for ; Mon, 16 Oct 2000 04:06:32 -0400 (EDT) Received: from gecko.ubiquity.co.uk by drago1.ubiquity.net via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 16 Oct 2000 09:07:00 UT Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id KAA02678; Mon, 16 Oct 2000 10:04:46 +0100 (BST) From: "Jo Hornsby" To: , Subject: RE: [SIP] SIP heartbeat Message-ID: <000101c03750$2171c770$4e34c3c1@ubiquity.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Importance: Normal In-Reply-To: <20001016002102.A23502@valhalla.marko.net> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 16 Oct 2000 10:04:46 +0100 Content-Transfer-Encoding: 7bit > Is there a way to perform a heartbeat in sip so that if either > endpoints connection is dropped it can be detected and the call > can be properly terminated? Try Session Timer. Linked under: http://www.cs.columbia.edu/~hgs/sip/drafts.html HTH, - Jo. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 16 06:38:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA01648 for ; Mon, 16 Oct 2000 06:38:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2DA4A4436D; Mon, 16 Oct 2000 05:38:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id E689C4436C for ; Mon, 16 Oct 2000 05:37:14 -0400 (EDT) Received: from dynamicsoft.com ([212.120.151.102]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id GAA01965; Mon, 16 Oct 2000 06:39:03 -0400 (EDT) Message-ID: <39EADA51.E9E7A62D@dynamicsoft.com> From: Chris Harris Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: archow@hss.hns.com Cc: Itamar Gilad , sip@lists.bell-labs.com, "'SIPForum list'" Subject: Re: [SIP] JAIN SIP Specification References: <6525697A.00132CDF.00@sampark.hss.hns.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 16 Oct 2000 11:37:05 +0100 Content-Transfer-Encoding: 7bit Arjun, Response included below... Regards, Chris archow@hss.hns.com wrote: > > The JAIN SIP API does not permit applications to have direct access to > > transactions. An application is given a transaction id as a reference by > the > > JainSipProvider, and it can use the reference to invoke send methods on > the > > JainSipProvider - but the Provider has control over transactions and may > throw > > an exception if an application attempts to do something it doesn't like. > > Chris, at this point , another question comes to mind: > What if my application does not need to keep transaction state ? If I were > to write > a JAIN SIP wrapper on a core stack, I dont mind forming a transaction id in > JainSipProvider, but does it also need me to correlate the transaction with > other > future messages ? This may not be in the scope of my application, which may > not be > interested in even keeping transaction state. The transaction id generated by the JainSipProvider is simply a convenience for applications when sending Acks, Cancels and Responses. There is no reason why an application can't use the generic sendRequest method (which doesn't take a transaction id) if it doesn't wish to keep track of the transaction ids. The JainSipProvider implementation must allow for the possibility that an application might do this. > > > Regds > Arjun > > -- > Arjun Roychowdhury @ Hughes Software Systems _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 16 06:47:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA01729 for ; Mon, 16 Oct 2000 06:47:02 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 946694436D; Mon, 16 Oct 2000 05:47:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from china.com (TCE-E-7-182-11.bta.net.cn [202.106.182.11]) by lists.bell-labs.com (Postfix) with SMTP id A1C1544338 for ; Sun, 15 Oct 2000 23:47:06 -0400 (EDT) Received: from china.com([10.1.7.100]) by china.com(JetMail 2.5.3.0) with SMTP id jm939eab995; Mon, 16 Oct 2000 04:44:23 -0000 Content-Type: text/plain Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Message-ID: From: fordtrueman@china.com To: SIP@lists.bell-labs.com X-Priority: 3 Subject: [SIP] Some discussions Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 16 Oct 2000 12:44:23 +0800 (CST) Content-Transfer-Encoding: 8bit Dear All: I have some questions to discuss. For RFC2543Bis02, I have some doubts, for examples. On page 23, Authorization belongs to request header, But on page 36,it is said it can be used in R & r. Is this contradiction? What's more, the same matter happens on WWW-Authentication, first, on page 23,it belongs to response header, But on page 37,it is said it can be used in R & r. On Page 45 on content-length, it says "If a server receives a UDP request with a Content-Length, but the value is larger than the size of the body sent in the request, the client SHOULD generate a 400 class response." I want to know which 400 class response can act as this response code, please give me a detailed response code, according to the 4xx response code listed, none can act as this situation.Perhelps this code is under the consideration. Thanks a lot! Yours: Ford ---------------------------------------------- ÖлªÍø»ýÉÍÖ®ÂÃ,´ó½±ÈÎÄúÓ®£¡ http://points4u.china.com ²Î¼ÓÍøÉÏÅÄÂô£¬ÃûÈËÇ©ÃûÎïÆ·ÈÎÄãÕù! http://auction4u.china.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 16 06:57:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA01880 for ; Mon, 16 Oct 2000 06:57:03 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 640534436D; Mon, 16 Oct 2000 05:57:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mars.hss.co.in (unknown [202.54.26.197]) by lists.bell-labs.com (Postfix) with ESMTP id D46AB4436C for ; Mon, 16 Oct 2000 05:56:03 -0400 (EDT) Received: from sampark.hss.hns.com (sampark [139.85.229.22]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id e9GAuEC13697; Mon, 16 Oct 2000 16:26:17 +0530 (IST) Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 6525697A.0039C03C ; Mon, 16 Oct 2000 16:00:47 +0530 X-Lotus-FromDomain: HSSBLR From: archow@hss.hns.com To: "Jo Hornsby" Cc: tsearle@valhalla.marko.net, sip@lists.bell-labs.com Message-ID: <6525697A.0039BF46.00@sampark.hss.hns.com> Subject: RE: [SIP] SIP heartbeat Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 16 Oct 2000 16:00:44 +0530 Another way to possibly detect if the endpoint has crashed or not is that you will stop receiving RTP and RTCP packets. Of course, this is valid only if you are using RTP for the session. Regds Arjun -- Arjun Roychowdhury @ Hughes Software Systems "Jo Hornsby" on 10/16/2000 02:34:46 PM To: tsearle@valhalla.marko.net, sip@lists.bell-labs.com cc: Subject: RE: [SIP] SIP heartbeat > Is there a way to perform a heartbeat in sip so that if either > endpoints connection is dropped it can be detected and the call > can be properly terminated? Try Session Timer. Linked under: http://www.cs.columbia.edu/~hgs/sip/drafts.html HTH, - Jo. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 16 07:34:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA02472 for ; Mon, 16 Oct 2000 07:34:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 104084436D; Mon, 16 Oct 2000 06:34:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from wiproecmx2.wipro.com (wiproecmx2.wipro.com [164.164.31.6]) by lists.bell-labs.com (Postfix) with ESMTP id F19C44436C for ; Mon, 16 Oct 2000 06:33:43 -0400 (EDT) Received: from ecvwall1.wipro.com (ecvwall1.wipro.com [192.168.181.23]) by wiproecmx2.wipro.com (8.9.3/8.9.3) with SMTP id RAA02141 for ; Mon, 16 Oct 2000 17:12:46 GMT Received: from wslexch.wipsys.soft.net ([192.219.223.59]) by kmglmail.mail.wipro.com (Netscape Messaging Server 3.6) with ESMTP id AAA3B71; Mon, 16 Oct 2000 17:03:23 +0530 Received: by wslexch.mail.wipro.com with Internet Mail Service (5.5.2650.21) id <4YBMZM0P>; Mon, 16 Oct 2000 17:04:59 +0530 Message-ID: <53BA505BEC72D21194400000E216A244037A2366@wslexch.mail.wipro.com> From: Subramania Sivaram To: Jonathan Rosenberg Cc: "'sip@lists.bell-labs.com'" Subject: RE: [SIP] draft-ietf-sip-rfc2543bis-01.txt: General questions MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 16 Oct 2000 17:04:56 +0530 Sorry Jonathan, Haven't been able to fully understand your brief replies. Hence, some more questions in-line. > > -----Original Message----- > > From: Subramania Sivaram [mailto:sivaram.subr@wipro.com] > > Sent: Saturday, October 14, 2000 10:27 AM > > To: sip@lists.bell-labs.com; Henning Schulzrinne; Jonathan Rosenberg > > Subject: [SIP] draft-ietf-sip-rfc2543bis-01.txt: General questions > > > > > > While reading the above doc, I had the following questions. > > [I am sorry if > > these > > are very basic, owing to my rather short association with this working > > group.] > > > > - What is maddr & when/ why would it exist in a SIP URI ?? > > maddr specifies the specific IP address to send to. It exists when the DNS > translation of the address in the URI cannot be relied upon, but a domain > name needs to be there for other purposes, like application logic. [Sivaram] Any specific scenarios that you have in mind for this (where DNS translation cannot be relied upon etc.) ?? And, why does the spec often say that maddr is usually a multicast address ?? > > > > - Section 4.2.6: What exactly are multicast registrations & > > why are they > > sent to > > "all SIP servers" multicast address ?? > > REGISTERs sent via multicast. Multicast is used since it allows for > autoconfigurations. A well-known multicast group must be used to eliminate > a > configured address. > [Sivaram] Why would I want to send a REGISTER to a multicast address ?? Is it for direct communication between UAs (bypassing proxies) ?? > > > > - Sec 4.2.6, Page 32 > > There is a sentence which says > > "a traveler sip:alice@acme.com (To) might register under the > > Request-URI > > sip:atlanta.hiayh.org , with the former as the To > > header field and the latter as the Request-URI." > > > > When a request is sent to the SIP proxy at acme.com (for > > alice@acme.com), > > how does it know to forward it to sip:atlanta.hiayh.org ?? > > In general, how does one SIP proxy know which > > is the next proxy to send to (in other words how is the proxy sequence > > determined) ?? > > Its a matter of local configuration. The spec defines some standard > approaches, such as using a registration database, or forwarding to the > address in the request URI. ANything else you like is possible. [Sivaram] Are you saying that in the above example alice needs to register at two SIP proxies, one at acme.com & other at atlanta.hiayh.org [so that the SIP proxy at acme.com can forward the request to atlanta.hiayh.org] ?? > > > > - Sec 6.34.2, There is a sentence which reads > > "Since the URIs contained in the Record-Route header fields > > are not useful for the reverse request path..." > > Why is this the case ?? > > Because they refer to the called party. If they are used by the called > party > in requests back to the caller, they are indicating the wrong person. > [Sivaram] I thought record route identified proxies on the path from the UAC to the UAS [if they want to stay on the path of future requests from either end]. If Via can be used to ensure replies take the reverse path to the request, why don't addresses added in Record Route work for the reverse direction (i.e. for future requests from the current UAS to current UAC) ?? > > > > - Can any request be forked ?? e.g. a BYE on a premature > > disconnect from the > > caller (only > > INVITE seems to be used in most examples). > > Any request can be forked. > > > > > - What are the possible uses of a SIP proxy ?? As a registrar, > > a firewall, what else ?? I believe it can be used for implementing > > features e.g. ACD, but most features seem to exist at the UA (is this > > correct ??). > > Routing. Namespace partitioning. Scale. Logging/billing, etc. See: > http://www.cs.columbia.edu/~jdrosen/papers/devconf_spring2000_proxies.ppt > > which explains in details why you want proxies. > > -Jonathan R. > --- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 16 09:11:00 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA04580 for ; Mon, 16 Oct 2000 09:11:00 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7CAF54436D; Mon, 16 Oct 2000 08:11:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from dgesmtp02.wcom.com (dgesmtp02.wcom.com [199.249.16.17]) by lists.bell-labs.com (Postfix) with ESMTP id 2D4964436C for ; Mon, 16 Oct 2000 08:10:50 -0400 (EDT) Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-33 #42261) id <0G2I00H01XXM8J@firewall.mcit.com> for sip@lists.bell-labs.com; Mon, 16 Oct 2000 13:10:34 +0000 (GMT) Received: from dgismtp04.wcomnet.com ([166.38.58.144]) by firewall.mcit.com (PMDF V5.2-33 #42261) with ESMTP id <0G2I00DMHXXMRA@firewall.mcit.com>; Mon, 16 Oct 2000 13:10:34 +0000 (GMT) Received: from CONVERSION-DAEMON by dgismtp04.wcomnet.com (PMDF V5.2-33 #42262) id <0G2I00601XZRX1@dgismtp04.wcomnet.com>; Mon, 16 Oct 2000 13:11:51 +0000 (GMT) Received: from dgismtp04.wcomnet.com by dgismtp04.wcomnet.com (PMDF V5.2-33 #42262) with SMTP id <0G2I00601XZHQR@dgismtp04.wcomnet.com>; Mon, 16 Oct 2000 13:11:51 +0000 (GMT) Received: from C25776A ([166.44.57.21]) by dgismtp04.wcomnet.com (PMDF V5.2-33 #42262) with SMTP id <0G2I00651XZD1B@dgismtp04.wcomnet.com>; Mon, 16 Oct 2000 13:11:38 +0000 (GMT) From: Henry Sinnreich Subject: RE: [SIP] SIP, PAM, and Presence In-reply-to: To: Joshua_Fox@vocaltec.com, sip@lists.bell-labs.com Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 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: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 16 Oct 2000 08:10:20 -0500 Content-Transfer-Encoding: 7bit The PamForum displays the logo: "Establishing the Internet Standard" :( Are they an acredited (Internet) standards organization? Henry >-----Original Message----- >From: sip-admin@lists.bell-labs.com >[mailto:sip-admin@lists.bell-labs.com]On Behalf Of >Joshua_Fox@vocaltec.com >Sent: Monday, October 16, 2000 1:39 AM >To: sip@lists.bell-labs.com >Subject: [SIP] SIP, PAM, and Presence > > >The dynamicsoft white paper on SIP and Presence shows >an interesting >additional use for the SIP protocol > >http://www.dynamicsoft.com/resources/pdf/Presence_White >_Paper.pdf > >I wonder what relation SIP-Presence has to PAM, the >Presence and >Availability Management API that is being put forward >by Lucent, Novell, >and others (www.pamforum.org). I realize that PAM is >an API while SIP is a >protocol, but it does not seem at first glance that >you might implement PAM >with SIP. > >Is there any info online > > >_______________________________________________ >SIP mailing list >SIP@lists.bell-labs.com >http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 16 09:53:00 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA05677 for ; Mon, 16 Oct 2000 09:53:00 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id CA9634436C; Mon, 16 Oct 2000 08:53:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 49D8C44363 for ; Mon, 16 Oct 2000 08:52:11 -0400 (EDT) Received: from dynamicsoft.com ([212.120.151.140]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id JAA02946; Mon, 16 Oct 2000 09:54:01 -0400 (EDT) Message-ID: <39EB0803.756A35C@dynamicsoft.com> From: Chris Harris Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: discussion@sipforum.org Cc: sip@lists.bell-labs.com Subject: Re: [SIPFORUM] Re: [SIP] JAIN SIP Specification References: <6525697A.0011D47E.00@sampark.hss.hns.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 16 Oct 2000 14:52:03 +0100 Content-Transfer-Encoding: 7bit Arjun, Indeed this was overlooked in the current version - I will add such a section to the introduction in the next version. Regards, Chris archow@hss.hns.com wrote: > Chris, > as you correctly stated, I would not be the last (nor the first) to ask > about any abstraction for the current API set. > I suggest you add a *small* section to the Introduction of JAIN-SIP > explicitly higlighting its scope and the justification of > why there is no CC in the current state. This would quell the most obvious > question that comes to everyone's mind, avoiding > repetitive explanation . > > Regds > Arjun > > -- > Arjun Roychowdhury @ Hughes Software Systems > > Chris Harris on 10/16/2000 04:36:13 AM > > Please respond to discussion@sipforum.org > > To: Itamar Gilad > cc: sip@lists.bell-labs.com, "'SIPForum list'" > > Subject: [SIPFORUM] Re: [SIP] JAIN SIP Specification > > Hello Itamar, > > Thanks for the comments. I have included responses below. > > Regards, > Chris > > Itamar Gilad wrote: > > > Hi Chris, > > > > a few comments: > > > > Requirement 3.3.1.2 (JAIN SIP Events) names only SIP messages as SIP > events. > > RFC2543 specifies that a TCP connection-close event should sometimes be > > interpreted as reception of CANCEL, which might qualify it as an event > for > > the purposes of JAIN. > > The JAIN SIP API is independent of the underlying transport, and if > something > happens at the transport level, such as your example, then it would be up > to the > JAIN SIP implementation to interpret the underlying event, and generate an > appropriate SIP message to send to JAIN SIP applications. > > > > > > > This seems to be a very comprehensive API. I didn't count, but I > estimate > > you have over 500 methods listed (many of which throw exceptions) in > dozens > > of classes. This is only the part of the API that deals with SIP > messages. > > In real life a SIP stack needs to export APIs also for calls, > transactions, > > SDP and more. Implementing such an extensive API on a system with limited > > resources may not be feasible in the near future. Also, it's very likely > > that many SIP-capable devices will not require the entire scope of the > > specified API as they may not use all message types and headers. Any > > thoughts on generating a specification for a minimal/mid-level JAIN API > > implementation, perhaps in the spirit of RFC2543 appendix A? > > Yes - it is true that there are many classes and methods. This is for the > benefit of the API user - it removes the need for users to parse the > standard > headers, reduces the risk of users using incorrect header values, and > ensures > greater application portability. The API certainly could have been defined > with > just one generic Header and Message class, but that would that be a very > helpful > SIP API? > > The JAIN SIP API does not permit applications to have direct access to > transactions. An application is given a transaction id as a reference by > the > JainSipProvider, and it can use the reference to invoke send methods on the > JainSipProvider - but the Provider has control over transactions and may > throw > an exception if an application attempts to do something it doesn't like. > > There is no notion of call control in this API - it is intended only as a > Java > interface to SIP. Within the JAIN framework, call control is handled by JCC > (Java Call Control) which is an Application Level API - the JAIN SIP API > needs > to fit beneath this call control API. There have been several requests for > a > higher level API for SIP-specific services, but whether this will be within > the > JAIN framework is not clear. This high level API could sit on top of the > current > API - or could be used instead - making it a candidate for the > minimal/mid-level > JAIN API you suggest. I would be very interested to hear suggestions from > people > about this. > > As for SDP, I have created classes for JAIN SDP which can be used across > all the > JAIN Protocol API's, but their use is not mandated by the JAIN SIP API - > the > body is simply an Object (whose toString() method will be called). In > hindsight, > the SDP classes should probably have been included in the Javadoc and > jar-file, > but since these classes are within the scope of more than just this API, I > postponed their inclusion. > > > > > > > Regards, > > > > Itamar Gilad > > > > > -----Original Message----- > > > From: Chris Harris [mailto:charris@dynamicsoft.com] > > > Sent: Fri, October 13, 2000 12:52 PM > > > To: sip@lists.bell-labs.com > > > Subject: [SIP] JAIN SIP Specification > > > > > > > > > Dear SIP WG, > > > > > > The JAIN SIP Specification is available from today for Public > > > Review on > > > the Java website. It can be found at > > > http://java.sun.com/aboutJava/communityprocess/review/jsr032/i > > ndex.html. > > > > The Public Review will close on 28th November. > > > > Regards, > > Chris Haris > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 16 10:37:12 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA06492 for ; Mon, 16 Oct 2000 10:37:12 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5FC554438E; Mon, 16 Oct 2000 09:37:03 -0400 (EDT) Delivered-To: sip@share.research.bell-labs.com Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by lists.bell-labs.com (Postfix) with SMTP id 566984433D for ; Mon, 16 Oct 2000 09:32:06 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Mon Oct 16 10:31:59 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 57C3344380; Mon, 16 Oct 2000 10:18:50 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ans.ih.lucent.com (ans.ih.lucent.com [135.2.78.5]) by lists.bell-labs.com (Postfix) with SMTP id 152BE4437D for ; Mon, 16 Oct 2000 10:18:50 -0400 (EDT) Received: by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id JAA19501; Mon, 16 Oct 2000 09:18:40 -0500 Cc: "'sip@lists.bell-labs.com'" , "'sip-implementors@cs.columbia.edu'" , Vijay Gurbani Received: from lucent.com by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id JAA19447; Mon, 16 Oct 2000 09:18:38 -0500 Message-ID: <39EB0E3B.37EAF4C2@lucent.com> From: "Vijay K. Gurbani" Reply-To: vkg@lucent.com Organization: Intelligent Network/Messaging Systems & Internet Software Group X-Mailer: Mozilla 4.61 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Original-CC: "'sip@lists.bell-labs.com'" , "'sip-implementors@cs.columbia.edu'" , Vijay Gurbani Subject: Re: [SIP] CANCEL/200 OK/BYE References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 16 Oct 2000 09:18:35 -0500 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > > -----Original Message----- > > From: Vijay K. Gurbani [mailto:vkg@lucent.com] > > > > All: > > > > The bis RFC says that when an INVITE is to be terminated > > (either by the > > UAC timing out after sending 7 requests out or by the caller > > associated > > with the UAC hanging up) a BYE or CANCEL request may be sent; it > > recommends sending both. > > > > I know the reason BYE is preferred is if CANCEL and 200 OK "cross > > each other on the wire". But what if they don't? Why send the > > BYE if after sending a CANCEL, the UAC gets a 487 Request Terminated > > (which it will have to ACK, of course). There are two cases (let's > > assume a lossless network with in-order delivery of packets): > > > > Case 1: CANCEL and 200 OK DO NOT "cross each other on the wire": > > > > UAC > > INVITE-------> > > <----------- 100 Trying > > <----------- 180 Ringing > > CANCEL ------> > > <----------- 487 Request Terminated > > ACK----------> > > <------------ 200 OK (CSeq: xxx CANCEL) > > > > As far as I can see, no need to send BYE here. (Last 4 > > exchanges are as per the behavior of a UAS when it gets a CANCEL and > > has NOT send a final response -- Section 4.2.5 "CANCEL") > > > > Case 2: CANCEL and 200 OK DO "cross each other on the wire": > > > > UAC > > INVITE-------> > > <----------- 100 Trying > > <----------- 180 Ringing > > CANCEL-----> <------ 200 OK (CSeq: xxx INVITE) > > ACK ---------> > > BYE ---------> > > <------------- 200 OK (CSeq: xxx BYE) > > > > Clearly, here, the CANCEL has no effect on the state machine of > > the UAS since it has already sent out the final response. The > > UAC, on receiving the 200 OK notes that this is OK'ing an INVITE, > > thus the CANCEL it send out has no meaning. It ACKs the 200 OK > > and THEN sends a BYE. > > > > So, it looks to me as if a CANCEL results in a 487 Request > > Terminated, a BYE may not be sent. Is that accurate? Comments? > > > > What are other implementors implementing? > > I think the most correct behavior is to send a CANCEL. If you get a > final response to the INVITE that is 200 class, then send BYE. Right. That is my understanding (and implementation, as well). But, to me, the spec is expansive enough that there may be problems with interoperability. > Where in the spec does it say to send both? Section 10.5.1 "Unreliable Transport Protocols", first paragraph, last sentence. I think the spec should state that a UAC MUST send a BYE iff after having sent a CANCEL (for an in-progress INVITE), it got a 200 class response to the INVITE (which means that the 200 OK and CANCEL "crossed each other on the wire"). Thanks, - vijay -- Vijay K. Gurbani vkg@lucent.com vkg@research.bell-labs.com vkg@acm.org Internet Software Group/Intelligent Network and Messaging Systems Lucent Technologies/Bell Labs Innovations, 263 Shuman Blvd, Rm 1A-413 Naperville, Illinois 60566 Voice: +1 630 224 0216 Fax: +1 630 713 0184 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 16 10:37:30 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA06506 for ; Mon, 16 Oct 2000 10:37:29 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4135444394; Mon, 16 Oct 2000 09:37:10 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from drago1.ubiquity.net (unknown [194.202.146.92]) by lists.bell-labs.com (Postfix) with SMTP id 3608E4433D for ; Mon, 16 Oct 2000 09:33:57 -0400 (EDT) Received: from gecko.ubiquity.co.uk by drago1.ubiquity.net via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 16 Oct 2000 14:34:24 UT Received: from phoffer by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id PAA04072; Mon, 16 Oct 2000 15:32:17 +0100 (BST) Message-ID: <006501c0377d$d3e7aff0$5334c3c1@ubiquity.co.uk> From: "Phil Hoffer" To: 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 Subject: [SIP] Use of Record-Route and Contact Headers Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 16 Oct 2000 15:31:52 +0100 Content-Transfer-Encoding: 7bit Hi, Table 4 of bis02 states that a Contact header can occur in the following response types: 1xx 2xx 3xx 485 (Ambiguous) However, Table 5 states that Record-Route can occur in the following response types: 2xx 401 (Unauthorized) 484 (Address Incomplete) I don't see how a response can include a Record-Route, if it can't contain a Contact. I believe that 401 and 484 should be added to the list of response types for a Contact header. What do you think? Cheers Phil (Just appreciating how overloaded Contact header is! :) http://www.ubiquity.net _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 16 10:41:55 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA06568 for ; Mon, 16 Oct 2000 10:41:55 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id AD0D744398; Mon, 16 Oct 2000 09:40:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from smtp4.cluster.oleane.net (smtp4.cluster.oleane.net [195.25.12.62]) by lists.bell-labs.com (Postfix) with ESMTP id F0F2244398 for ; Mon, 16 Oct 2000 09:39:28 -0400 (EDT) Received: from oleane (dyn-1-1-025.Vin.dialup.oleane.fr [195.25.4.25]) by smtp4.cluster.oleane.net with SMTP id QAA81061 for ; Mon, 16 Oct 2000 16:39:23 +0200 (CEST) Message-ID: <02b701c0377e$ac886200$0401a8c0@oleane.com> From: "Peter Lewis" To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02B4_01C0378F.6FA35500" 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 Subject: [SIP] VoDSL Europe : the Deployment Scenario Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 16 Oct 2000 16:37:55 +0200 This is a multi-part message in MIME format. ------=_NextPart_000_02B4_01C0378F.6FA35500 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable =20 VoDSL Europe : the Deployment Scenario Paris, 16-19 January 2001, second edition Network design, deployments, standardization, softswitch evolution, = management, marketing issues. Get more details on: http://www.upperside.fr/bavodsl2001.htm ------=_NextPart_000_02B4_01C0378F.6FA35500 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
 
VoDSL Europe : the Deployment=20 Scenario
Paris, 16-19 January 2001, second = edition
Network design, deployments, standardization, = softswitch=20 evolution, management, marketing issues.
Get more details on:
http://www.upperside.fr/= bavodsl2001.htm
 
------=_NextPart_000_02B4_01C0378F.6FA35500-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 16 10:45:54 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA06616 for ; Mon, 16 Oct 2000 10:45:54 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 064814439D; Mon, 16 Oct 2000 09:45:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 4D35144393 for ; Mon, 16 Oct 2000 09:44:33 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id KAA03895; Mon, 16 Oct 2000 10:46:32 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <4WS2X3GN>; Mon, 16 Oct 2000 10:40:38 -0400 Message-ID: From: Jonathan Rosenberg To: "'Brett Tate'" , "'SIPbell-labs'" Subject: RE: [SIP] Option-tag value for rfc2976 ? MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 16 Oct 2000 10:40:37 -0400 New methods don't require option tags. They are covered by the Allow/405 mechanism. Two answer your second question - yes, it is a good idea, in fact, to include Allow in INVITE to indicate supported methods. Same with the 200 OK. This is really useful for REFER, for example. It allows a caller to "grey out" the transfer button if the called party doesn't support it. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com > -----Original Message----- > From: Brett Tate [mailto:brett@broadsoft.com] > Sent: Monday, October 16, 2000 1:31 AM > To: SIPbell-labs > Subject: [SIP] Option-tag value for rfc2976 ? > > > What is rfc2976's option-tag value? > > Are new SIP extension methods such as INFO > valid in the Supported header? If not, can the > Allow header be included in INVITE request > to indicate what methods the caller supports? > > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 16 11:22:00 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA07484 for ; Mon, 16 Oct 2000 11:22:00 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id CB96544363; Mon, 16 Oct 2000 10:22:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mailgw1.netvision.net.il (mailgw1.netvision.net.il [194.90.1.14]) by lists.bell-labs.com (Postfix) with ESMTP id 2539A4433D for ; Mon, 16 Oct 2000 10:21:27 -0400 (EDT) Received: from ismailout.icomverse.com (Efrat-FR3.ser.netvision.net.il [199.203.174.65]) by mailgw1.netvision.net.il (8.9.3/8.9.3) with ESMTP id RAA08184 for ; Mon, 16 Oct 2000 17:21:17 +0200 (IST) Received: from ismail1.icomverse.com ([190.190.110.2]) by ismailout.icomverse.com (8.11.0.Beta3/8.11.0.Beta3) with ESMTP id e9GFKGs07038 for ; Mon, 16 Oct 2000 18:20:16 +0300 Received: by ismail1.icomverse.com with Internet Mail Service (5.5.2650.21) id ; Mon, 16 Oct 2000 17:21:17 +0200 Message-ID: From: "Gazal, Elly" To: "'sip@lists.bell-labs.com'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="windows-1255" Subject: [SIP] (no subject) Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 16 Oct 2000 17:21:15 +0200 unsubscribe QJqQ elly_gazal@icomverse.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 16 11:55:11 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA08482 for ; Mon, 16 Oct 2000 11:55:09 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6368444363; Mon, 16 Oct 2000 10:55:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 95BFD4433D for ; Mon, 16 Oct 2000 10:54:30 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id LAA05388; Mon, 16 Oct 2000 11:56:06 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <4WS2X33V>; Mon, 16 Oct 2000 11:50:12 -0400 Message-ID: From: Jonathan Rosenberg To: "'Gonzalo Camarillo'" , "'Culpepper, Bert'" Cc: "'Michael Thomas'" , "'Rohan Mahy'" , Jonathan Rosenberg , "'sip@lists.bell-labs.com'" , "'Henning Schulzrinne'" , "'mmusic'" Subject: RE: [SIP] draft-camarillo-sip-sdp-00.txt MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 16 Oct 2000 11:50:11 -0400 I just thought of an issue with this approach that is worth considering. The problem is that if A sends an INVITE to B, there cannot be more m lines in the response from B that in the request from A. THis is needed to support matching up of m lines. Now, lets say A is a PC, and it calls some user B that needs to use one of these transcoders. In the 200 OK, B cannot add a separate media stream for this codec. Rather, it will have to send a regular 200 OK, and then immediately re-invite to add a media stream for that specific codec, and remove that codec from the original media stream. Kind of ugly, and possibly might get you glitches in the beginning of lost media. So, whilst I agree with the idea of what you are trying to do here (a choose-one-of-M session feature), I am concerned about its general ability to fit within the framework of SDP, which is widely recognized as limited for such things. -Jonathan R. > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > Sent: Friday, October 13, 2000 4:30 AM > To: Culpepper, Bert > Cc: Michael Thomas; Rohan Mahy; Jonathan Rosenberg; > sip@lists.bell-labs.com; Henning Schulzrinne; mmusic > Subject: Re: [SIP] draft-camarillo-sip-sdp-00.txt > > > Hi, > > I will try to summarize the discussions so far: > > The issue I am looking at is: "What happens when I need to receive a > single media stream in different ports (or even different IP > addresses) > depending on the codec used at any moment". > > A media stream here is, for instance, the audio transmitted > in a regular > telephone call. > > With this issue in mind, it is good to know scenarios where this can > happen and, of course, possible solutions. > > There are multiple scenarios where we can have this situation. > > -The device receiving voice is not the same as the device that handles > DTMF tones. Thus, the media stream will have to be sent to the device > handling voice when the RTP packets contain PCM voice (for > instance) and > to the device handling DTFM tones when they carry tones. > > -I need to use a transcoder because I have a cheap client > that does not > support all the audio codecs in the world. I want to receive PCM in my > IP address, but I would like to receive GSM in the IP address of the > transcoder. The transcoder will take care of sending the > stream to my IP > address once it has been transcoded. > > -Cellular terminals that have to configure radio bearers with specific > codec information because some optimizations are applied. They want to > receive media on different ports depending on the codec used. > > Folks have pointed out more scenarios where this might happen. > > The first solution I thought of was to send a single RTP stream to > different ports (or different IP addresses). As the AVT guys pointed > out, this would cause lots of problems. Mainly related to RTCP. > Everybody agreed that a much better solution was to establish > different > RTP sessions. > > If different RTP sessions are established, this issue is > transparent to > RTP and RTCP. They are thus not affected. > > SDP backwards compatibility was also an issue, so a solution that does > not break existing implementations has to be found. > > The fid (flow identifier) attribute I was describing in my > previous mail > would just be an identifier for the flow. That is, we might > have several > RTP streams, but all of them are related, because we are dealing with > just one flow. > > So, an application receiving this parameter would know that all the m > lines in the SDP with the same fid attribute (a=fid:12, for instance) > are related. I believe this is useful information for the application. > > If an application does not understand the fid attribute, everything > works properly. The only issue is that the application is not aware of > this relation between m lines. > > > Regarding Mike's question, this was already presented as > input for SDPng > in the last IETF. I am now after a solution for SDP. I agree > that SDPng > will solve all these issues. The quesion is: when? Everybody > working on > it is currently pretty busy. > > Best regards, > > Gonzalo > > > > "Culpepper, Bert" wrote: > > > > Hi: > > > > I've only followed this thread on the SIP list and read the recent > > discussion on the AVT WG list, I've probably missed some > related discussion > > in other WGs. It appears to me, and as Gonzalo pointed > out, separate RTP > > streams are OK. The session description below describes > two RTP streams > > with only one active at any point in time (I believe the > semantics of the > > fid attribute shown indicate that I can choose to send only > one) vs. a > > single RTP stream with either of two encoding schemes. > However, as a SIP UA > > and having received that session description I know to send the two > > encodings separately if I want to make the other endpoint > happy. (And only > > one at a time if I support the fid attribute.) It does > seem reasonable that > > it might complicate QoS, but I expect the benefit of the > separate media > > streams is justified when used. > > > > Anyway, segregating media streams (where exact > synchronization isn't needed > > and RTP is good enough) enables certain efficiencies when providing > > telecommunications and like services in an IP network. > This is only one > > advantage I suspect. > > > > Regards, > > Bert > > > > > -----Original Message----- > > > From: Michael Thomas [mailto:mat@cisco.com] > > > Sent: Thursday, October 12, 2000 10:22 AM > > > To: Gonzalo Camarillo > > > Cc: Culpepper, Bert; Rohan Mahy; Jonathan Rosenberg; > > > sip@lists.bell-labs.com; Henning Schulzrinne; mmusic > > > Subject: Re: [SIP] draft-camarillo-sip-sdp-00.txt > > > > > > > > > Gonzalo Camarillo writes: > > > > I would like my session description to look like: > > > > > > > > v=0 > > > > o=John 289085535 289085535 IN IP4 first.example.com > > > > t=0 0 > > > > c=IN IP4 111.111.111.111 > > > > m=audio 20000 RTP/AVP 0 > > > > a=fid:1 > > > > m=audio 20002 RTP/AVP 8 > > > > a=fid:1 > > > > > > > > If an implementation does not understand the fid > attribute it will try > > > > to mix the audio streams. Since one is "empty" all the > time, doing this > > > > is not really a big deal. Thus, backwards > compatibility is not a > > > > concern. > > > > > > > > Do you have any concerns with this approach? > > > > > > The main problem I see is with the interaction with > > > QoS reservations. Namely, that you'd expect the receiver > > > to book reservations for both flows. Doing: > > > > > > m=audio 20000 RTP/AVP 0 8 > > > > > > on the other hand only implies that you book the ceil() > > > of both flows. > > > > > > Why is it so advantageous to segregate these into two > > > streams? The implicit coupling you're after seems like > > > it's not well handled by SDP right now, and I'd bet > > > that this would be better taken up as a working item > > > for SDPng (if not already there) because my understanding > > > is that explicit audio synch with video is also problematic in > > > SDP right now, which is sort of similar. > > > > > > Mike > > > > > -- > Gonzalo Camarillo Phone : +358 9 299 33 71 > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > Telecom R&D Fax : +358 9 299 30 52 > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > Finland http://www.hut.fi/~gonzalo > --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 16 12:30:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA09391 for ; Mon, 16 Oct 2000 12:30:04 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 757F544363; Mon, 16 Oct 2000 11:30:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by lists.bell-labs.com (Postfix) with ESMTP id 562704433D for ; Mon, 16 Oct 2000 11:29:08 -0400 (EDT) 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 JAA14556; Mon, 16 Oct 2000 09:29:07 -0700 (PDT) Received: from sony-laptop (rmahy-dsl5.cisco.com [10.19.53.126]) by imop.cisco.com (Mirapoint) with SMTP id AAH48894; Mon, 16 Oct 2000 09:28:58 -0700 (PDT) Message-Id: <4.1.20001016093434.00c2fc70@imop.cisco.com> X-Sender: rmahy@imop.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 To: "Junyoung Heo" , "Gonzalo Camarillo" , From: Rohan Mahy Subject: Re: [SIP] Conferencing Cc: In-Reply-To: <004301c03350$1afc3370$9901a8c0@nadatel.com> References: <39E3F99A.2E10D31A@lmf.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 16 Oct 2000 09:39:26 -0700 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA09391 At 11:54 PM 10/10/00 , Junyoung Heo wrote: >Hi, all. > >> Hi Aparna, >> >> Check section 3 of: >> http://search.ietf.org/internet-drafts/draft-camarillo-3pcc-qos-00.txt >> > >I cannot understand that draft camarillo-3pcc-qos-00. >What is PRACK, COMET ? >I have never seen these methods. Where can I find its definition? > >> The request-URI is used in order to know which conference you want to >> join. > >I know request-URI may be changed by proxies. >So, How changable field can be used as ID? The requestURI can be changed by proxies... to change it into something meaningful to the receiving proxies and UAs. so I can change: sip:8000@proxy1.widgets.com into: sip:widgets-telecast@conf-server42.serviceprovider.net the o= line in the SDP is unlikely to be useful. hope this helps... thanks, -rohan >And, I think, SIP is not necessary to support multi-unicast call itself. >It overburden SIP. I like SIP for its simplicity. >I use origin of SDP for conference ID. > >Thanks so much if you point out my misunderstanding about SIP and related doc. > > >> The example includes also a controller. >> >> Regards, >> >> Gonzalo >> >> Aparna.Vemuri@Level3.com wrote: >> > >> > Hello. >> > I have a question about SIP-based conferencing. Let us assume the existence >> > of a SIP UA that performs conferencing. SIP UAs that want to join a >> > conference send SIP INVITEs to the conference server to conference them in, >> > i.e. for an n-party conference, the CS will receive n INVITEs. I believe >> > there has to be a need for corrolation and disambiguation of the different >> > call-legs at the conference server. For a dial-in conference such as >this, I >> > think the easiest (and the most intuitive) way to corrolate all these n >> > INVITEs (that have different Call-IDs) is via the dialed number/ >> > conference-ID (i.e. the "To" field). >> > >> > However, if all these different call-legs were initiated by a third-party >> > entity (called the controller) that sent these INVITEs on behalf of the >> > actual participants, how should the corrolation and disambiguation of >> > call-legs be performed at the conference server? >> > >> > I think there are two options: >> > a) Same as before. Have each one of the INVITEs have different Call-IDs and >> > have the conferencing SIP UA corrolate them based on the "To" field. >> > This requires the controller to have a mechanism to corrolate all these >> > call-legs at its end. >> > >> > b) Mandate that all the call-legs share the same Call-ID. The 'From' field >> > in each INVITE sent to the CS (from the controller) must then be tagged. >> > The CS could use the Call-ID to corrolate all these call-legs and the >tag in >> > the From to help distinguish one from the other. >> > >> > Is there a reason to prefer one over the other? Is there a third option >that >> > I have missed? Is there a preferred/ accepted mechanism to accomplish this >> > and is this documented somewhere? >> > >> > Thanks, >> > Aparna >> > >> > _______________________________________________ >> > SIP mailing list >> > SIP@lists.bell-labs.com >> > http://lists.bell-labs.com/mailman/listinfo/sip >> >> -- >> Gonzalo Camarillo Phone : +358 9 299 33 71 >> Oy L M Ericsson Ab Mobile: +358 40 702 35 35 >> Telecom R&D Fax : +358 9 299 30 52 >> FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com >> Finland http://www.hut.fi/~gonzalo >> >> _______________________________________________ >> SIP mailing list >> SIP@lists.bell-labs.com >> http://lists.bell-labs.com/mailman/listinfo/sip >/s/s/sip >.com >> http://lists.bell-labs.com/mailman/Hƒæj)bž >b²Ôˆ>X¬¶ÆÞ­YZnÇ(šm§ÿåŠËlmée•¦ìr‰¿™¨¥™©ÿ­+-ŠwèþÈ© _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 16 12:37:18 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA09568 for ; Mon, 16 Oct 2000 12:37:17 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9662944363; Mon, 16 Oct 2000 11:37:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by lists.bell-labs.com (Postfix) with ESMTP id 6960D4433D for ; Mon, 16 Oct 2000 11:36:56 -0400 (EDT) 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 JAA21825; Mon, 16 Oct 2000 09:36:53 -0700 (PDT) Received: from sony-laptop (rmahy-dsl5.cisco.com [10.19.53.126]) by imop.cisco.com (Mirapoint) with SMTP id AAH49017; Mon, 16 Oct 2000 09:36:46 -0700 (PDT) Message-Id: <4.1.20001016094122.00b17f00@imop.cisco.com> X-Sender: rmahy@imop.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 To: Henning Schulzrinne , Bryan Byerly From: Rohan Mahy Subject: Re: [SIP] I-D ACTION:draft-byerly-sip-hide-route-00.txt Cc: Neil Deason , jdrosen@dynamicsoft.com, sip@lists.bell-labs.com, ddaiker@cisco.com, shbhatna@cisco.com, ntrivedi@cisco.com In-Reply-To: <39E4844A.6FDD26F@cs.columbia.edu> References: <200010111031.GAA05690@ietf.org> <39E47B1F.D41D0A2D@ubiquity.net> <39E48377.8E20B647@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 16 Oct 2000 09:47:13 -0700 Henning, I recall that the two main criticisms of Via hiding were a) complexity, so make it an optional draft; and b) that there was no similar mechanism for other sensitive headers like Router/Record-Route, so here is a suitable mechanism. DCS, and similar architectures, will need this kind of functionality. IMO it is better to make the mechanism generic, than to write more proprietary extensions. If you'd like, someone can bundle Via hiding with this draft into a header-hiding "package"? Can you propose an alternate mechanism which satisfies the same requirements? thanks, -rohan At 08:16 AM 10/11/00 , Henning Schulzrinne wrote: >Bryan Byerly wrote: >> > >> >> Jonathan/Henning, >> Is a Via header hiding draft in the works? Do you need volunteers to >perform the >> extraction of Via into an I-D? > >The reason that Via header hiding was removed is that some of us >(including me) see it as a flawed mechanism. I can't prevent others from >implementing anything, but I don't think I want to contribute to an I-D >that prolongs its agony and further complicates the protocol, for >extremely marginal gain in mostly feel-good security. > >-- >Henning Schulzrinne http://www.cs.columbia.edu/~hgs > >_______________________________________________ >SIP mailing list >SIP@lists.bell-labs.com >http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 16 12:48:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA10008 for ; Mon, 16 Oct 2000 12:48:02 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 80D354438D; Mon, 16 Oct 2000 11:48:03 -0400 (EDT) Delivered-To: sip@share.research.bell-labs.com Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by lists.bell-labs.com (Postfix) with SMTP id E20F34439C for ; Mon, 16 Oct 2000 11:30:06 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Mon Oct 16 12:28:06 EDT 2000 Received: by lists.bell-labs.com (Postfix) id A47BE44380; Mon, 16 Oct 2000 12:14:57 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from zydeco.research.bell-labs.com (zydeco.research.bell-labs.com [135.104.120.150]) by lists.bell-labs.com (Postfix) with ESMTP id 7E8894437D for ; Mon, 16 Oct 2000 12:14:57 -0400 (EDT) Received: from research.bell-labs.com (lespaul.research.bell-labs.com [135.104.66.18]) by zydeco.research.bell-labs.com (8.9.1/8.9.1) with ESMTP id MAA05467; Mon, 16 Oct 2000 12:14:56 -0400 (EDT) Message-ID: <3A1414DB.483A376@research.bell-labs.com> From: G A Venkatesh X-Mailer: Mozilla 4.75 [en] (Win95; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: sip@lists.bell-labs.com Cc: venk@research.bell-labs.com Subject: RE: [SIP] SIP, PAM, and Presence References: <39EB1361.A5501317@lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 16 Nov 2000 12:09:47 -0500 Content-Transfer-Encoding: 7bit I will answer both questions related to PAM in this message. > The PamForum displays the logo: "Establishing the Internet > Standard" :( > Are they an acredited (Internet) standards organization? Please don't read too much into the logo! The original designer got a bit carried away. The site is being redesigned for a new launch shortly. PAMforum is an industry consortium that has been established as a non-profit organization to promote PAM specifications in the spirit of Parlay, VoiceXML, WAPforum, etc. > >The dynamicsoft white paper on SIP and Presence shows > >an interesting > >additional use for the SIP protocol > > > >http://www.dynamicsoft.com/resources/pdf/Presence_White_Paper.pdf > > > >I wonder what relation SIP-Presence has to PAM, the > >Presence and > >Availability Management API that is being put forward > >by Lucent, Novell, > >and others (www.pamforum.org). I realize that PAM is > >an API while SIP is a > >protocol, but it does not seem at first glance that > >you might implement PAM > >with SIP. That is a common question. There will be a white paper shortly on the above when the new PAMforum web site is launched. A "brief" answer is PAM is orthogonal to the Presence capabilities in SIP (or IMPP or 3GPP or any other protocol for that matter). PAM is designed to promote inter-operability over multiple networks and communication mediums and to enable presence servers to share/export presence information with security/charging considerations. There are three different but related aspects of presence (and availability) management where the relationship between protocols and PAM should be explored. 1. Presence registration or detection: There is not going to be a single model of presence storage due to administrative jurisdictions and heterogeneity of networks. Case 1a: Presence registered explicitly by devices. We expect this will be done via protocols such as SIP that are natural to those devices. PAM based presence servers will translate these registration messages to the PAM APIs in the implementation back end. Case 1b: Presence registered explicitly by heterogeneous networks into an aggregating presence server or to peer networks. Not very different from the above except that the networks may use multiple protocols native to them (including SIP) or may use PAM APIs directly if the interaction requires some of the authentication/charging mechanisms not supported by a native protocol. Case 2: Presence is exposed via a network implicitly: Networks can choose to expose presence information via a single protocol or via an API such as PAM based on the capabilities of the protocol and the privacy/security requirements of the networks. The advantage of having an API standard such as PAM here is that it is not tied to a specific application (unless "SIP everywhere" is realized as hoped by members of this group) protocol and the networks do not have to support multiple protocols for different communication types. 2. Presence query: Here PAM differentiates between query for presence (of devices) and query for availability (of people owning those devices). If the device is synonymous with the person then there is no difference but in services that can operate over devices in multiple networks (messaging via WAP/SMS or IMPP) or when people have more than one device capable of a particular communication type (messaging) and have preferences as to how they wish to use one or the other, we need that explicit differentiation. Queries for presence by simple devices to a presence server are still expected to be done via a protocol native to them (such as SIP). PAM based servers at the back end will translate those messages to PAM APIs and may even convert "presence queries" to "availability queries" if the protocol is naive about such things. Queries for presence between networks or aggregating services over multiple networks would use a protocol such as SIP (if SIP was everywhere and supported the type of authentication/charging arrangements necessary between them) or an application and network independent API such as PAM. 3. Presence and Availability Management: This part consists of tying static user information (identity/address information and the ownership of one or more devices) with dynamic information about those devices and user control of how they are to be available to others over those devices based on personal preferences and/or enterprise policies. This is more of a backend management that cannot be fully (nor is it necessary to be) addressed by individual protocols, mostly to keep the protocols simple. As an example, LDAP is a simple and useful protocol for directory access and update but the directory management (schema management, access control lists, etc.) is beyond (and should sensibly remain beyond) the scope of a protocol such as LDAP. The need for standardization via PAM here is to allow "north-bound" applications to be written by independent ISVs to enable users to manage their communications. In some cases, certain management features (for example, turning a preference off or replacing one preference by the other) may be supported by these applications via protocols such as SIP if they wish to do so. PAM is neutral about this and will be able to support such implemenations. Hope this gives some flavor of where PAM sits in relation to a protocol such as SIP. PAMforum is establishing liaison activities with other forums so as not to re-invent the wheel on either side or to lead to divergent paths. Hopefully some co-ordination can be done with the SIP community just as there is between Parlay and SIP communities. Guda Venkatesh Bell Laboratories Lucent Technologies venk@lucent.com +1 908 582 5517 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 16 12:50:38 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA10199 for ; Mon, 16 Oct 2000 12:50:36 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 859DD443A7; Mon, 16 Oct 2000 11:49:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id D19994438D for ; Mon, 16 Oct 2000 11:48:39 -0400 (EDT) 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 MAA24804; Mon, 16 Oct 2000 12:48:04 -0400 (EDT) Message-ID: <39EB3144.F786BCD8@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Rohan Mahy Cc: Bryan Byerly , Neil Deason , jdrosen@dynamicsoft.com, sip@lists.bell-labs.com, ddaiker@cisco.com, shbhatna@cisco.com, ntrivedi@cisco.com Subject: Re: [SIP] I-D ACTION:draft-byerly-sip-hide-route-00.txt References: <200010111031.GAA05690@ietf.org> <39E47B1F.D41D0A2D@ubiquity.net> <39E48377.8E20B647@cisco.com> <4.1.20001016094122.00b17f00@imop.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 16 Oct 2000 12:48:04 -0400 Content-Transfer-Encoding: 7bit Rohan Mahy wrote: > > Henning, > > I recall that the two main criticisms of Via hiding were a) complexity, so > make it an optional draft; and b) that there was no similar mechanism for > other sensitive headers like Router/Record-Route, so here is a suitable > mechanism. > > DCS, and similar architectures, will need this kind of functionality. IMO > it is better to make the mechanism generic, than to write more proprietary > extensions. If you'd like, someone can bundle Via hiding with this draft > into a header-hiding "package"? > > Can you propose an alternate mechanism which satisfies the same requirements? > In the earlier discussion, I listed a whole lot of headers and other information, of which Route is only the most obvious. The only real solution that I can think of is back-to-back "anonymizer" UAs. This also makes the trust model far more explicit. Also, in almost all cases, you care far more about where your voice/video IP packets come from. Unless you hide those, hiding the Route or Via seems pointless to me (and very hard to explain to users). Thus, I don't think the mechanism proposed for Route does anything but add more complexity and the feel-good perception of security. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 16 12:53:26 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA10282 for ; Mon, 16 Oct 2000 12:53:23 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 659FB443AF; Mon, 16 Oct 2000 11:52:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by lists.bell-labs.com (Postfix) with ESMTP id 970024438D for ; Mon, 16 Oct 2000 11:51:56 -0400 (EDT) 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 JAA02346; Mon, 16 Oct 2000 09:51:52 -0700 (PDT) Received: from sony-laptop (rmahy-dsl5.cisco.com [10.19.53.126]) by imop.cisco.com (Mirapoint) with SMTP id AAH49316; Mon, 16 Oct 2000 09:51:46 -0700 (PDT) Message-Id: <4.1.20001016095141.0098ef00@imop.cisco.com> X-Sender: rmahy@imop.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 To: Joshua_Fox@vocaltec.com, sip@lists.bell-labs.com From: Rohan Mahy Subject: Re: [SIP] call flow: Two different media types in parallel In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 16 Oct 2000 10:02:07 -0700 Joshua, If I understand you correctly, Alice and Bob each have only one physical device, which happens to handle multiple media types. If this is the case then Alice will send a single INVITE to Bob with an SDP for both (two distinct m= lines in the SDP). c=1.1.1.1 etc.et m=audio 16748 blah blah m=video 16750 blah blah If instead you want Alice's SIP phone to play audio, and her computer to play video, you could do this with REFER and caller preferences: Alice's phone sends an INVITE to bob and a REFER to her PC: INVITE sip:bob@here.com SIP/2.0 Contact: Accept-Contact: *;media="audio" ... REFER alice@alice-pc.here.com Refer-To: ... Her PC will generate an INVITE for bob as well. Note that it is not necessary for Alice to specify to which of Bob's devices to send audio and video--caller preferences will take care of that. INVITE sip:bob@here.com SIP/2.0 Contact: Accept-Contact: *;media="video" ... hope this helps. thanks, -rohan At 12:40 AM 10/12/00 , Joshua_Fox@vocaltec.com wrote: >Thanks to SIP-list readers for answering my questions, which I hope are not >too newbie-ish. > >Here is a call flow question. I did not see this discussed in the FAQ or >call-flow examples, >but if I missed it, could you please point me to the right URL. > >Say that two humans--the omnipresent Alice and Bob of cryptography >fame--have two SIP-enabled >UA's each. The UA's may be two apps running on one computer, or an app on a >computer and >on a handheld embedded-SIP device. The two devices communicate on different >media--say one >is audio-only and the other video-only, or one is audio-video and the >other text-chat. Part of this >call flow is that each person uses two independent SIP >implementations--this is not one SIP UA controlling >two media types, but rather two SIP UA's controlling two media types. > >Alice wants to push one and only one button and initiate simultaneous >parallel channels on two separate media. > >What is the correct call flow? Does Alice's UA1 INVITE three other >UA's--Alice's UA2, >Bob's UA1, and Bob's UA2--to a four-way session (using SDP to >distinguish the two channels)? If this is a case where Alice's UA1 and >Alice's UA2 can >communicate easily using a non-SIP protocol--say they are two apps on the >same computer, >and inter-process communication is possible--should that be done first, >rather than attempting >a SIP 4-way session? If so, then should the same thing be done of the other >side--only one of >Bob's UA's is initially invited, and this UA then INVITEs or otherwise >brings Bob's other UA into the session? > >Or should Alice's initial INVITE from her UA1 be forked to both of Bob's >UA's >(a forking proxy typically forks to find which one of several choices is >valid, but it could be asked to return >more than one) and if so, what about Alice's UA2? In any of these cases, >does Alice's UA1 have to be >"told" about her UA2, or should a automated discovery process be built >using REGISTER? > >I guess that both of each person's UAs would have the same SIP URL. > >We could take the question further and ask what call-flow to use when one >of the >apps is not SIP-enabled, but rather uses one of the other protocols which >can be translated to/from SIP >with a gateway. > >This is a rather wide question, and no doubt many implementations are >possible. I'd like to see what >has been written about these possibilities. > > >Joshua Fox > > >_______________________________________________ >SIP mailing list >SIP@lists.bell-labs.com >http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 16 13:11:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA10897 for ; Mon, 16 Oct 2000 13:11:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id BE3734433D; Mon, 16 Oct 2000 12:11:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from broadsoft.com (broadsoft.com [161.58.239.68]) by lists.bell-labs.com (Postfix) with ESMTP id 1244E4433A for ; Mon, 16 Oct 2000 12:10:18 -0400 (EDT) Received: from tate ([216.181.56.35]) by broadsoft.com (8.8.8) id NAA09614; Mon, 16 Oct 2000 13:10:12 -0400 (EDT) Message-ID: <0b1b01c03794$2183d7f0$3202a8c0@broadsoft.com> From: "Brett Tate" To: "'SIPbell-labs'" References: 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 Subject: [SIP] rfc2543bis-02 table 4 comment Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 16 Oct 2000 13:11:27 -0400 Content-Transfer-Encoding: 7bit rfc2543bis-02 section 6.4 table 4 comment: Please add a row to show that Allow is optional in an INVITE request. Section 6.10 should also be updated to reflect that the Allow header can be used in a request to show what methods are supported by the sender of the INVITE. ----- Original Message ----- From: Jonathan Rosenberg To: 'Brett Tate' ; 'SIPbell-labs' Sent: Monday, October 16, 2000 10:40 AM Subject: RE: [SIP] Option-tag value for rfc2976 ? > New methods don't require option tags. They are covered by the Allow/405 > mechanism. Two answer your second question - yes, it is a good idea, in > fact, to include Allow in INVITE to indicate supported methods. Same with > the 200 OK. This is really useful for REFER, for example. It allows a caller > to "grey out" the transfer button if the called party doesn't support it. > > -Jonathan R. > > --- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > > -----Original Message----- > > From: Brett Tate [mailto:brett@broadsoft.com] > > Sent: Monday, October 16, 2000 1:31 AM > > To: SIPbell-labs > > Subject: [SIP] Option-tag value for rfc2976 ? > > > > > > What is rfc2976's option-tag value? > > > > Are new SIP extension methods such as INFO > > valid in the Supported header? If not, can the > > Allow header be included in INVITE request > > to indicate what methods the caller supports? > > > > > > > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 16 13:25:13 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA11278 for ; Mon, 16 Oct 2000 13:25:08 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 62BF744353; Mon, 16 Oct 2000 12:25:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id DC29B4433A for ; Mon, 16 Oct 2000 12:24:41 -0400 (EDT) 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 NAA27509; Mon, 16 Oct 2000 13:24:35 -0400 (EDT) Message-ID: <39EB39D4.75B10FB5@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Brett Tate Cc: "'SIPbell-labs'" Subject: Re: [SIP] rfc2543bis-02 table 4 comment References: <0b1b01c03794$2183d7f0$3202a8c0@broadsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 16 Oct 2000 13:24:36 -0400 Content-Transfer-Encoding: 7bit Brett Tate wrote: > > rfc2543bis-02 section 6.4 table 4 comment: > > Please add a row to show that Allow is > optional in an INVITE request. > > Section 6.10 should also be updated to > reflect that the Allow header can be used > in a request to show what methods are > supported by the sender of the INVITE. Tentatively added as being possible for all requests (no reason to single out INVITE, I believe) and applying to the same call leg. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 16 13:29:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA11380 for ; Mon, 16 Oct 2000 13:29:04 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1D42D4433F; Mon, 16 Oct 2000 12:29:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from pentagon.cisco.com (pentagon.cisco.com [161.44.199.141]) by lists.bell-labs.com (Postfix) with ESMTP id 7E18444363 for ; Mon, 16 Oct 2000 12:27:23 -0400 (EDT) Received: from cia.cisco.com (mirapoint@cia.cisco.com [161.44.199.157]) by pentagon.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA10646; Mon, 16 Oct 2000 13:27:17 -0400 (EDT) Received: from mhammer-nt.cisco.com (va-dhcp198-137.cisco.com [161.44.198.137]) by cia.cisco.com (Mirapoint) with ESMTP id ACP04353; Mon, 16 Oct 2000 13:27:16 -0400 (EDT) Message-Id: <4.3.2.7.2.20001016133010.00b3e5a0@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: G A Venkatesh , sip@lists.bell-labs.com From: hammer michael Subject: RE: [SIP] SIP, PAM, and Presence Cc: venk@research.bell-labs.com In-Reply-To: <3A1414DB.483A376@research.bell-labs.com> References: <39EB1361.A5501317@lucent.com> Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 16 Oct 2000 13:32:14 -0700 It sounds like you should emphasize the Management in PAM, as it appears this is very much provisioning-like, and supports your explanation of being orthogonal.

Mike


At 12:09 PM 11/16/2000 -0500, G A Venkatesh wrote:
I will answer both questions related to PAM in this message.

> The PamForum displays the logo: "Establishing the Internet
> Standard" :(
> Are they an acredited (Internet) standards organization?

Please don't read too much into the logo! The original designer got a
bit carried away. The site is being redesigned for a new launch shortly.

PAMforum is an industry consortium that has been established as a
non-profit organization to promote PAM specifications in the spirit of
Parlay, VoiceXML, WAPforum, etc.

> >The dynamicsoft white paper on SIP and Presence shows
> >an interesting
> >additional use for the SIP protocol
> >
> >http://www.dynamicsoft.com/resources/pdf/Presence_White_Paper.pdf
> >
> >I wonder what relation SIP-Presence  has to PAM, the
> >Presence and
> >Availability Management API that is being put forward
> >by Lucent, Novell,
> >and others (www.pamforum.org). I realize that PAM is
> >an API while SIP is a
> >protocol, but it does not seem at first glance that
> >you might implement PAM
> >with SIP.

That is a common question. There will be a white paper shortly on the
above when the new PAMforum web site is launched. A "brief" answer is

PAM is orthogonal to the Presence capabilities in SIP (or IMPP or 3GPP
or any other protocol for that matter). PAM is designed to promote
inter-operability over multiple networks and communication mediums and
to enable presence servers to share/export presence information with
security/charging considerations. There are three different but related
aspects of presence (and availability) management where the relationship
between protocols and PAM should be explored.

1. Presence registration or detection: There is not going to be a single
model of presence storage due to administrative jurisdictions and
heterogeneity of networks.
Case 1a: Presence registered explicitly by devices. We expect this will
be done via protocols such as SIP that are natural to those devices. PAM
based presence servers will translate these registration messages to the
PAM APIs in the implementation back end.
Case 1b: Presence registered explicitly by heterogeneous networks into
an aggregating presence server or to peer networks. Not very different
from the above except that the networks may use multiple protocols
native to them (including SIP) or may use PAM APIs directly if the
interaction requires some of the authentication/charging mechanisms not
supported by a native protocol.
Case 2: Presence is exposed via a network implicitly: Networks can
choose to expose presence information via a single protocol or via an
API such as PAM based on the capabilities of the protocol and the
privacy/security requirements of the networks. The advantage of having
an API standard such as PAM here is that it is not tied to a specific
application (unless "SIP everywhere" is realized as hoped by members of
this group) protocol and the networks do not have to support multiple
protocols for different communication types.

2. Presence query: Here PAM differentiates between query for presence
(of devices) and query for availability (of people owning those
devices). If the device is synonymous with the person then there is no
difference but in services that can operate over devices in multiple
networks (messaging via WAP/SMS or IMPP) or when people have more than
one device capable of a particular communication type (messaging) and
have preferences as to how they wish to use one or the other, we need
that explicit differentiation.
Queries for presence by simple devices to a presence server are still
expected to be done via a protocol native to them (such as SIP). PAM
based servers at the back end will translate those messages to PAM APIs
and may even convert "presence queries" to "availability queries" if the
protocol is naive about such things.
Queries for presence between networks or aggregating services over
multiple networks would use a protocol such as SIP (if SIP was
everywhere and supported the type of authentication/charging
arrangements necessary between them) or an application and network
independent API such as PAM.

3. Presence and Availability Management: This part consists of tying
static user information (identity/address information and the ownership
of one or more devices) with dynamic information about those devices and
user control of how they are to be available to others over those
devices based on personal preferences and/or enterprise policies. This
is more of a backend management that cannot be fully (nor is it
necessary to be) addressed by individual protocols, mostly to keep the
protocols simple. As an example, LDAP is a simple and useful protocol
for directory access and update but the directory management (schema
management, access control lists, etc.) is beyond (and should sensibly
remain beyond) the scope of a protocol such as LDAP. The need for
standardization via PAM here is to allow "north-bound" applications to
be written by independent ISVs to enable users to manage their
communications. In some cases, certain management features (for example,
turning a preference off or replacing one preference by the other) may
be supported by these applications via protocols such as SIP if they
wish to do so. PAM is neutral about this and will be able to support
such implemenations.

Hope this gives some flavor of where PAM sits in relation to a protocol
such as SIP. PAMforum is establishing liaison activities with other
forums so as not to re-invent the wheel on either side or to lead to
divergent paths. Hopefully some co-ordination can be done with the SIP
community just as there is between Parlay and SIP communities.

Guda Venkatesh
Bell Laboratories
Lucent Technologies
venk@lucent.com
+1 908 582 5517


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip

_______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 16 13:39:14 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA11622 for ; Mon, 16 Oct 2000 13:39:13 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C20454433F; Mon, 16 Oct 2000 12:39:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from guardian1.tlv.radvision.com (unknown [212.143.185.30]) by lists.bell-labs.com (Postfix) with ESMTP id 819B14433A for ; Mon, 16 Oct 2000 12:38:25 -0400 (EDT) Received: from nt-mail.tlv.radvision.com ([172.20.2.100]) by guardian1.tlv.radvision.com (Post.Office MTA v3.5.3 release 223 ID# 0-0U10L2S100V35) with ESMTP id com; Mon, 16 Oct 2000 20:37:13 +0200 Received: by NT-MAIL with Internet Mail Service (5.5.2650.21) id <48RJ5VW8>; Mon, 16 Oct 2000 19:38:37 +0200 Message-ID: From: Itamar Gilad To: "'Chris Harris'" , Itamar Gilad Cc: sip@lists.bell-labs.com, "'SIPForum list'" Subject: RE: [SIP] JAIN SIP Specification MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 16 Oct 2000 19:38:36 +0200 Chris, thanks for your responses. See responses below. Itamar > -----Original Message----- > From: Chris Harris [mailto:charris@dynamicsoft.com] > Sent: Mon, October 16, 2000 1:06 AM > To: Itamar Gilad > Cc: sip@lists.bell-labs.com; 'SIPForum list' > Subject: Re: [SIP] JAIN SIP Specification > > Itamar Gilad wrote: > > > > This seems to be a very comprehensive API. I didn't count, > but I estimate > > you have over 500 methods listed (many of which throw > exceptions) in dozens > > of classes. This is only the part of the API that deals > with SIP messages. > > In real life a SIP stack needs to export APIs also for > calls, transactions, > > SDP and more. Implementing such an extensive API on a > system with limited > > resources may not be feasible in the near future. Also, > it's very likely > > that many SIP-capable devices will not require the entire > scope of the > > specified API as they may not use all message types and > headers. Any > > thoughts on generating a specification for a > minimal/mid-level JAIN API > > implementation, perhaps in the spirit of RFC2543 appendix A? > ... > The API certainly could have > been defined with > just one generic Header and Message class, but that would > that be a very helpful > SIP API? Probably not, but there's a range of possibilities between this extremely limited approach (which BTW doesn't really save anything - just moves the complexity to supplementary function arguments and turns-off type safety) and the API presented in the SIP JAIN specification. What I had in mind is a definition of different levels of SIP JAIN API implementations based on what sub-sets of headers, methods and response codes are supported. For example: * Minimal SIP JAIN API = {To, From, Call-ID, CSeq, Content-Length, Content-Type } + {INV, ACK} * Basic SIP JAIN API = Minimal + BYE, + Accept-Language. * etc. I've taken these definitions from RFC2543 A just for the sake of the example. There are probably better ways to break the presented JAIN API into sub-groups. I believe that this form of reduced-SIP JAIN will enable the API to be much more prevalent. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 16 13:56:11 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA11989 for ; Mon, 16 Oct 2000 13:56:04 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id CF9774433D; Mon, 16 Oct 2000 12:56:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lists.bell-labs.com (Postfix) with ESMTP id AAE334433A for ; Mon, 16 Oct 2000 12:55:13 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id e9GHt8t17586 for ; Mon, 16 Oct 2000 19:55:08 +0200 (MEST) 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 UAA10993 for ; Mon, 16 Oct 2000 20:55:08 +0300 (EET DST) Received: from lmf.ericsson.se (E005004B52C74-udp423509.lmf.ericsson.se [131.160.106.10]) by greymse1.lmf.ericsson.se (8.9.3 (PHNE_18979)/8.8.6) with ESMTP id UAA03353 for ; Mon, 16 Oct 2000 20:55:07 +0300 (EETDST) Message-ID: <39EB40FB.4CDB19CC@lmf.ericsson.se> From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Content-Type: multipart/mixed; boundary="------------68F2DC695F0DA52985B34008" Subject: [SIP] Session-timer with INFO Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 16 Oct 2000 20:55:07 +0300 This is a multi-part message in MIME format. --------------68F2DC695F0DA52985B34008 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, First, this mail is NOT a proposal for a change. I would just like to hear some opinions - or maybe it has already been discussed on the list? The INFO Method RFC says that for INFO requests without a message body, a server supporting INFO MUST respond with response code 200. So, my question is: why couldn't INFO be used for the session-timer functionality? Is the ACK the (re-)INVITE provides really necessary for the purpose? And, like the session-timer is defined now, the other party would not even have to support the INFO method, because a 501 Not Implemented would be sent, and the sender of the INFO would know the session is "alive". Just some thoughts... Please let me know if there is something I haven't taken into consideration. Regards, Christer Holmberg Ericsson Finland --------------68F2DC695F0DA52985B34008 Content-Type: text/x-vcard; charset=us-ascii; name="christer.holmberg.vcf" Content-Description: Card for Christer Holmberg Content-Disposition: attachment; filename="christer.holmberg.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Holmberg;Christer tel;cell:+358-40-5604412 tel;work:+358-9-2992943 x-mozilla-html:FALSE org:Ericsson;Advanced Signalling Research Laboratory adr:;;;;;; version:2.1 email;internet:christer.holmberg@lmf.ericsson.se title:System Designer fn:Christer Holmberg end:vcard --------------68F2DC695F0DA52985B34008-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 16 14:18:11 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA12468 for ; Mon, 16 Oct 2000 14:18:08 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 643824433D; Mon, 16 Oct 2000 13:18:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 671EF4433A for ; Mon, 16 Oct 2000 13:17:44 -0400 (EDT) Received: from dynamicsoft.com (userab52.ie.uudial.com [212.120.133.152]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id OAA07254; Mon, 16 Oct 2000 14:19:45 -0400 (EDT) Message-ID: <39EB464C.44254E5B@dynamicsoft.com> From: Chris Harris Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Itamar Gilad Cc: sip@lists.bell-labs.com, "'SIPForum list'" Subject: Re: [SIP] JAIN SIP Specification References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 16 Oct 2000 19:17:48 +0100 Content-Transfer-Encoding: 7bit Itamar, The idea of levelling the API based on what messages, headers and response codes are understood is certainly an interesting one - minimal, basic, redirection, firewall-friendly, negotiation, authentication and "full". jain.protocol.ip.sip jain.protocol.ip.sip.header jain.protocol.ip.sip.message could then become... jain.protocol.ip.sip - listener, provider, stack, general classes used at all levels jain.protocol.ip.sip.header - contains base Header class (and requestHeader, ResponseHeader, EntityHeader, GeneralHeader) jain.protocol.ip.sip.message - contains base Message class jain.protocol.ip.sip.minimal - general classes used only at this level and above jain.protocol.ip.sip.minimal.header - headers used only at this level and above jain.protocol.ip.sip.minimal.message - messages only used at this level and above jain.protocol.ip.sip.basic - general classes used only at this level and above jain.protocol.ip.sip.basic.header - headers used only at this level and above jain.protocol.ip.sip.basic.message - messages used only at this level and above ... ... jain.protocol.ip.sip."full" - general classes only used at this level jain.protocol.ip.sip."full".header - headers used only at this level jain.protocol.ip.sip."full".message - messages used only at this level The API user could then pick the packages they need - say they initially only want the minimal features, but then realise they need to use their application behind a firewall - then they can simply add the firewall-friendly package. The RFC says "In general, each capability listed builds on the ones above it" but it is not hard to see that firewall-friendly and authentication may be desired without redirection for example. Is this what you hand in mind Itamar? Regards, Chris Itamar Gilad wrote: > Chris, > > thanks for your responses. See responses below. > > Itamar > > -----Original Message----- > > From: Chris Harris [mailto:charris@dynamicsoft.com] > > Sent: Mon, October 16, 2000 1:06 AM > > To: Itamar Gilad > > Cc: sip@lists.bell-labs.com; 'SIPForum list' > > Subject: Re: [SIP] JAIN SIP Specification > > > > > Itamar Gilad wrote: > > > > > > > This seems to be a very comprehensive API. I didn't count, > > but I estimate > > > you have over 500 methods listed (many of which throw > > exceptions) in dozens > > > of classes. This is only the part of the API that deals > > with SIP messages. > > > In real life a SIP stack needs to export APIs also for > > calls, transactions, > > > SDP and more. Implementing such an extensive API on a > > system with limited > > > resources may not be feasible in the near future. Also, > > it's very likely > > > that many SIP-capable devices will not require the entire > > scope of the > > > specified API as they may not use all message types and > > headers. Any > > > thoughts on generating a specification for a > > minimal/mid-level JAIN API > > > implementation, perhaps in the spirit of RFC2543 appendix A? > > > ... > > The API certainly could have > > been defined with > > just one generic Header and Message class, but that would > > that be a very helpful > > SIP API? > > Probably not, but there's a range of possibilities between this extremely > limited approach (which BTW doesn't really save anything - just moves the > complexity to supplementary function arguments and turns-off type safety) > and the API presented in the SIP JAIN specification. > What I had in mind is a definition of different levels of SIP JAIN API > implementations based on what sub-sets of headers, methods and response > codes are supported. > For example: > * Minimal SIP JAIN API = {To, From, Call-ID, CSeq, Content-Length, > Content-Type } + {INV, ACK} > * Basic SIP JAIN API = Minimal + BYE, + Accept-Language. > * etc. > I've taken these definitions from RFC2543 A just for the sake of the > example. There are probably better ways to break the presented JAIN API into > sub-groups. > > I believe that this form of reduced-SIP JAIN will enable the API to be much > more prevalent. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 16 14:33:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA12812 for ; Mon, 16 Oct 2000 14:33:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4B27D4433D; Mon, 16 Oct 2000 13:33:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from guardian1.tlv.radvision.com (unknown [212.143.185.30]) by lists.bell-labs.com (Postfix) with ESMTP id 56DA54433A for ; Mon, 16 Oct 2000 13:32:46 -0400 (EDT) Received: from nt-mail.tlv.radvision.com ([172.20.2.100]) by guardian1.tlv.radvision.com (Post.Office MTA v3.5.3 release 223 ID# 0-0U10L2S100V35) with ESMTP id com; Mon, 16 Oct 2000 21:31:35 +0200 Received: by NT-MAIL with Internet Mail Service (5.5.2650.21) id <48RJ5VY8>; Mon, 16 Oct 2000 20:32:59 +0200 Message-ID: From: Itamar Gilad To: "'discussion@sipforum.org'" , Itamar Gilad Cc: sip@lists.bell-labs.com Subject: RE: [SIPFORUM] Re: [SIP] JAIN SIP Specification MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 16 Oct 2000 20:32:57 +0200 Yap, pretty much. I'm not sure the strict definitions in RFC2543 are the best ones for this purpose, though (I don't really know of a lot of applications that don't need the BYE message, but require the Require header). There is some sort of classification in this page http://www.cs.columbia.edu/~hgs/sip/bakeoff/classification.html , but this relates more to UA and proxy application. Thanks Itamar > -----Original Message----- > From: Chris Harris [mailto:charris@dynamicsoft.com] > Sent: Mon, October 16, 2000 8:18 PM > To: Itamar Gilad > Cc: sip@lists.bell-labs.com; 'SIPForum list' > Subject: [SIPFORUM] Re: [SIP] JAIN SIP Specification > > > Itamar, > > The idea of levelling the API based on what messages, headers > and response codes > are understood is certainly an interesting one - minimal, > basic, redirection, > firewall-friendly, negotiation, authentication and "full". > > jain.protocol.ip.sip > jain.protocol.ip.sip.header > jain.protocol.ip.sip.message > > could then become... > > jain.protocol.ip.sip - listener, provider, stack, general > classes used at all > levels > jain.protocol.ip.sip.header - contains base Header class (and > requestHeader, > ResponseHeader, EntityHeader, GeneralHeader) > jain.protocol.ip.sip.message - contains base Message class > > jain.protocol.ip.sip.minimal - general classes used only at > this level and above > > jain.protocol.ip.sip.minimal.header - headers used only at > this level and above > jain.protocol.ip.sip.minimal.message - messages only used at > this level and > above > > jain.protocol.ip.sip.basic - general classes used only at > this level and above > jain.protocol.ip.sip.basic.header - headers used only at this > level and above > jain.protocol.ip.sip.basic.message - messages used only at > this level and above > ... > ... > jain.protocol.ip.sip."full" - general classes only used at this level > jain.protocol.ip.sip."full".header - headers used only at this level > jain.protocol.ip.sip."full".message - messages used only at this level > > The API user could then pick the packages they need - say > they initially only > want the minimal features, but then realise they need to use > their application > behind a firewall - then they can simply add the > firewall-friendly package. The > RFC says "In general, each capability listed builds on the > ones above it" but it > is not hard to see that firewall-friendly and authentication > may be desired > without redirection for example. > > Is this what you hand in mind Itamar? > > Regards, > Chris > > > > Itamar Gilad wrote: > > > Chris, > > > > thanks for your responses. See responses below. > > > > Itamar > > > -----Original Message----- > > > From: Chris Harris [mailto:charris@dynamicsoft.com] > > > Sent: Mon, October 16, 2000 1:06 AM > > > To: Itamar Gilad > > > Cc: sip@lists.bell-labs.com; 'SIPForum list' > > > Subject: Re: [SIP] JAIN SIP Specification > > > > > > > > Itamar Gilad wrote: > > > > > > > > > > This seems to be a very comprehensive API. I didn't count, > > > but I estimate > > > > you have over 500 methods listed (many of which throw > > > exceptions) in dozens > > > > of classes. This is only the part of the API that deals > > > with SIP messages. > > > > In real life a SIP stack needs to export APIs also for > > > calls, transactions, > > > > SDP and more. Implementing such an extensive API on a > > > system with limited > > > > resources may not be feasible in the near future. Also, > > > it's very likely > > > > that many SIP-capable devices will not require the entire > > > scope of the > > > > specified API as they may not use all message types and > > > headers. Any > > > > thoughts on generating a specification for a > > > minimal/mid-level JAIN API > > > > implementation, perhaps in the spirit of RFC2543 appendix A? > > > > > ... > > > The API certainly could have > > > been defined with > > > just one generic Header and Message class, but that would > > > that be a very helpful > > > SIP API? > > > > Probably not, but there's a range of possibilities between > this extremely > > limited approach (which BTW doesn't really save anything - > just moves the > > complexity to supplementary function arguments and > turns-off type safety) > > and the API presented in the SIP JAIN specification. > > What I had in mind is a definition of different levels of > SIP JAIN API > > implementations based on what sub-sets of headers, methods > and response > > codes are supported. > > For example: > > * Minimal SIP JAIN API = {To, From, Call-ID, CSeq, Content-Length, > > Content-Type } + {INV, ACK} > > * Basic SIP JAIN API = Minimal + BYE, + Accept-Language. > > * etc. > > I've taken these definitions from RFC2543 A just for the sake of the > > example. There are probably better ways to break the > presented JAIN API into > > sub-groups. > > > > I believe that this form of reduced-SIP JAIN will enable > the API to be much > > more prevalent. > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 16 14:40:24 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA12960 for ; Mon, 16 Oct 2000 14:40:23 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0B69C4433D; Mon, 16 Oct 2000 13:40:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lists.bell-labs.com (Postfix) with ESMTP id ABBC84433A for ; Mon, 16 Oct 2000 13:39:16 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id e9GIcXZ15337; Mon, 16 Oct 2000 20:38:33 +0200 (MEST) 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 VAA12462; Mon, 16 Oct 2000 21:38:32 +0300 (EET DST) Received: from lmf.ericsson.se (E0080C77A56E4.lmf.ericsson.se [131.160.105.66]) by greymse1.lmf.ericsson.se (8.9.3 (PHNE_18979)/8.8.6) with ESMTP id VAA08926; Mon, 16 Oct 2000 21:38:27 +0300 (EETDST) Message-ID: <39EB4B11.783DE7AE@lmf.ericsson.se> From: Gonzalo Camarillo Organization: Ericsson X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: "'Culpepper, Bert'" , "'Michael Thomas'" , "'Rohan Mahy'" , "'sip@lists.bell-labs.com'" , "'Henning Schulzrinne'" , "'mmusic'" Subject: Re: [SIP] draft-camarillo-sip-sdp-00.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 16 Oct 2000 21:38:09 +0300 Content-Transfer-Encoding: 7bit Hi Jonathan, Jonathan Rosenberg wrote: > > I just thought of an issue with this approach that is worth considering. > > The problem is that if A sends an INVITE to B, there cannot be more m lines > in the response from B that in the request from A. THis is needed to support > matching up of m lines. If A does not support the fid attribute, we are in today's situation (what we want to avioid), and B will have to do what you describe (re-INVITE right after the 200 OK). If A supports the fid attribute, it will include a fid attribute for each m line in the SDP. Upon reception of the INVITE, B knows that A understands the fid attribute because it appears in the SDP. Then, since both understand it, B can add as many m lines as it wishes, since the fid attribute will be used to align the media streams (rather than nth m lines matching). That's why the title of the draft is "SDP media alignment in SIP". So, this is a general mechanism not just for demultiplexing media flows but also for performing media alignment. Best regards, Gonzalo Now, lets say A is a PC, and it calls some user B > that needs to use one of these transcoders. In the 200 OK, B cannot add a > separate media stream for this codec. Rather, it will have to send a regular > 200 OK, and then immediately re-invite to add a media stream for that > specific codec, and remove that codec from the original media stream. Kind > of ugly, and possibly might get you glitches in the beginning of lost media. > > So, whilst I agree with the idea of what you are trying to do here (a > choose-one-of-M session feature), I am concerned about its general ability > to fit within the framework of SDP, which is widely recognized as limited > for such things. > > -Jonathan R. > > > -----Original Message----- > > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > Sent: Friday, October 13, 2000 4:30 AM > > To: Culpepper, Bert > > Cc: Michael Thomas; Rohan Mahy; Jonathan Rosenberg; > > sip@lists.bell-labs.com; Henning Schulzrinne; mmusic > > Subject: Re: [SIP] draft-camarillo-sip-sdp-00.txt > > > > > > Hi, > > > > I will try to summarize the discussions so far: > > > > The issue I am looking at is: "What happens when I need to receive a > > single media stream in different ports (or even different IP > > addresses) > > depending on the codec used at any moment". > > > > A media stream here is, for instance, the audio transmitted > > in a regular > > telephone call. > > > > With this issue in mind, it is good to know scenarios where this can > > happen and, of course, possible solutions. > > > > There are multiple scenarios where we can have this situation. > > > > -The device receiving voice is not the same as the device that handles > > DTMF tones. Thus, the media stream will have to be sent to the device > > handling voice when the RTP packets contain PCM voice (for > > instance) and > > to the device handling DTFM tones when they carry tones. > > > > -I need to use a transcoder because I have a cheap client > > that does not > > support all the audio codecs in the world. I want to receive PCM in my > > IP address, but I would like to receive GSM in the IP address of the > > transcoder. The transcoder will take care of sending the > > stream to my IP > > address once it has been transcoded. > > > > -Cellular terminals that have to configure radio bearers with specific > > codec information because some optimizations are applied. They want to > > receive media on different ports depending on the codec used. > > > > Folks have pointed out more scenarios where this might happen. > > > > The first solution I thought of was to send a single RTP stream to > > different ports (or different IP addresses). As the AVT guys pointed > > out, this would cause lots of problems. Mainly related to RTCP. > > Everybody agreed that a much better solution was to establish > > different > > RTP sessions. > > > > If different RTP sessions are established, this issue is > > transparent to > > RTP and RTCP. They are thus not affected. > > > > SDP backwards compatibility was also an issue, so a solution that does > > not break existing implementations has to be found. > > > > The fid (flow identifier) attribute I was describing in my > > previous mail > > would just be an identifier for the flow. That is, we might > > have several > > RTP streams, but all of them are related, because we are dealing with > > just one flow. > > > > So, an application receiving this parameter would know that all the m > > lines in the SDP with the same fid attribute (a=fid:12, for instance) > > are related. I believe this is useful information for the application. > > > > If an application does not understand the fid attribute, everything > > works properly. The only issue is that the application is not aware of > > this relation between m lines. > > > > > > Regarding Mike's question, this was already presented as > > input for SDPng > > in the last IETF. I am now after a solution for SDP. I agree > > that SDPng > > will solve all these issues. The quesion is: when? Everybody > > working on > > it is currently pretty busy. > > > > Best regards, > > > > Gonzalo > > > > > > > > "Culpepper, Bert" wrote: > > > > > > Hi: > > > > > > I've only followed this thread on the SIP list and read the recent > > > discussion on the AVT WG list, I've probably missed some > > related discussion > > > in other WGs. It appears to me, and as Gonzalo pointed > > out, separate RTP > > > streams are OK. The session description below describes > > two RTP streams > > > with only one active at any point in time (I believe the > > semantics of the > > > fid attribute shown indicate that I can choose to send only > > one) vs. a > > > single RTP stream with either of two encoding schemes. > > However, as a SIP UA > > > and having received that session description I know to send the two > > > encodings separately if I want to make the other endpoint > > happy. (And only > > > one at a time if I support the fid attribute.) It does > > seem reasonable that > > > it might complicate QoS, but I expect the benefit of the > > separate media > > > streams is justified when used. > > > > > > Anyway, segregating media streams (where exact > > synchronization isn't needed > > > and RTP is good enough) enables certain efficiencies when providing > > > telecommunications and like services in an IP network. > > This is only one > > > advantage I suspect. > > > > > > Regards, > > > Bert > > > > > > > -----Original Message----- > > > > From: Michael Thomas [mailto:mat@cisco.com] > > > > Sent: Thursday, October 12, 2000 10:22 AM > > > > To: Gonzalo Camarillo > > > > Cc: Culpepper, Bert; Rohan Mahy; Jonathan Rosenberg; > > > > sip@lists.bell-labs.com; Henning Schulzrinne; mmusic > > > > Subject: Re: [SIP] draft-camarillo-sip-sdp-00.txt > > > > > > > > > > > > Gonzalo Camarillo writes: > > > > > I would like my session description to look like: > > > > > > > > > > v=0 > > > > > o=John 289085535 289085535 IN IP4 first.example.com > > > > > t=0 0 > > > > > c=IN IP4 111.111.111.111 > > > > > m=audio 20000 RTP/AVP 0 > > > > > a=fid:1 > > > > > m=audio 20002 RTP/AVP 8 > > > > > a=fid:1 > > > > > > > > > > If an implementation does not understand the fid > > attribute it will try > > > > > to mix the audio streams. Since one is "empty" all the > > time, doing this > > > > > is not really a big deal. Thus, backwards > > compatibility is not a > > > > > concern. > > > > > > > > > > Do you have any concerns with this approach? > > > > > > > > The main problem I see is with the interaction with > > > > QoS reservations. Namely, that you'd expect the receiver > > > > to book reservations for both flows. Doing: > > > > > > > > m=audio 20000 RTP/AVP 0 8 > > > > > > > > on the other hand only implies that you book the ceil() > > > > of both flows. > > > > > > > > Why is it so advantageous to segregate these into two > > > > streams? The implicit coupling you're after seems like > > > > it's not well handled by SDP right now, and I'd bet > > > > that this would be better taken up as a working item > > > > for SDPng (if not already there) because my understanding > > > > is that explicit audio synch with video is also problematic in > > > > SDP right now, which is sort of similar. > > > > > > > > Mike > > > > > > > > -- > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > Telecom R&D Fax : +358 9 299 30 52 > > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > > Finland http://www.hut.fi/~gonzalo > > > > --- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip -- 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 31 18 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 16 15:04:12 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA13644 for ; Mon, 16 Oct 2000 15:04:12 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id ACDAA4433A; Mon, 16 Oct 2000 14:04:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from wusr3.mobilerain.com (sdsl-208-185-234-252.dsl.sjc.megapath.net [208.185.234.252]) by lists.bell-labs.com (Postfix) with ESMTP id 8AC8B44338 for ; Mon, 16 Oct 2000 14:03:38 -0400 (EDT) Received: from mobilerain.com (IDENT:dsardana@localhost [127.0.0.1]) by wusr3.mobilerain.com (8.9.3/8.9.3) with ESMTP id MAA21544; Mon, 16 Oct 2000 12:00:55 -0700 Message-ID: <39EB5067.6E417D89@mobilerain.com> From: Bobby Sardana Organization: MobileRain Technologies, Inc. X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: Chris Harris Cc: sip@lists.bell-labs.com Subject: Re: [SIP] JAIN SIP Specification References: <39E6E93C.7958683D@dynamicsoft.com> Content-Type: multipart/mixed; boundary="------------633A6CF5F6C9B17695D1F6E8" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 16 Oct 2000 12:00:55 -0700 This is a multi-part message in MIME format. --------------633A6CF5F6C9B17695D1F6E8 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello Chris: After reading the JAIN SIP Specification, I have the following comments: a. The specification [Section 3.3.2] JAIN SIP Provider Requirements - implies that the Provider interface interfaces with a vendor specific SIP stack. The SIP stack, as I understand, is nothing more than the header parsing and construction -- which is already included in the JAIN SIP jar file. So how can the provider, or a sample provider interface be implemented using the included SIP stack? In simplistic terms, how can a SIP Redirect Server be implemented using the SipJainProviider interface? This part is not clear from the specification. Regards, Bobby.Sardana@mobilerain.com Chris Harris wrote: > Dear SIP WG, > > The JAIN SIP Specification is available from today for Public Review on > the Java website. It can be found at > http://java.sun.com/aboutJava/communityprocess/review/jsr032/index.html. > > The Public Review will close on 28th November. > > Regards, > Chris Haris > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip --------------633A6CF5F6C9B17695D1F6E8 Content-Type: text/x-vcard; charset=us-ascii; name="bobby.sardana.vcf" Content-Description: Card for Bobby Sardana Content-Disposition: attachment; filename="bobby.sardana.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Sardana;Bobby x-mozilla-html:FALSE org:MobileRain Technologies, Inc.;Telecommunications adr:;;;;;; version:2.1 email;internet:bobby.sardana@mobilerain.com title:Engineer x-mozilla-cpt:;0 fn:Bobby Sardana end:vcard --------------633A6CF5F6C9B17695D1F6E8-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 16 15:12:06 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA13796 for ; Mon, 16 Oct 2000 15:12:04 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 808444434A; Mon, 16 Oct 2000 14:12:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by lists.bell-labs.com (Postfix) with ESMTP id 30C8844338 for ; Mon, 16 Oct 2000 14:11:44 -0400 (EDT) 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 MAA16561; Mon, 16 Oct 2000 12:11:40 -0700 (PDT) Received: from sony-laptop (rmahy-dsl5.cisco.com [10.19.53.126]) by imop.cisco.com (Mirapoint) with SMTP id AAH52403; Mon, 16 Oct 2000 12:11:37 -0700 (PDT) Message-Id: <4.1.20001016115728.00c3cc00@imop.cisco.com> X-Sender: rmahy@imop.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 To: Christer Holmberg , sip@lists.bell-labs.com From: Rohan Mahy Subject: Re: [SIP] Session-timer with INFO In-Reply-To: <39EB40FB.4CDB19CC@lmf.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 16 Oct 2000 12:21:06 -0700 Hi, If the UA crashed and rebooted and forgot about the old session, it would respond with either a 481 call leg doesn't exist (you would know the call is down), or a 501 (you know the UA is up, but is the call?) thanks, -rohan At 10:55 AM 10/16/00 , Christer Holmberg wrote: > >Hi, > >First, this mail is NOT a proposal for a change. I would just like to >hear some opinions - or maybe it has already been discussed on the list? > >The INFO Method RFC says that for INFO requests without a message body, >a server supporting INFO MUST respond with response code 200. So, my >question is: why couldn't INFO be used for the session-timer >functionality? Is the ACK the (re-)INVITE provides really necessary for >the purpose? > >And, like the session-timer is defined now, the other party would not >even have to support the INFO method, because a 501 Not Implemented >would be sent, and the sender of the INFO would know the session is >"alive". > >Just some thoughts... Please let me know if there is something I haven't >taken into consideration. > >Regards, > >Christer Holmberg >Ericsson Finland > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 16 15:17:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA13887 for ; Mon, 16 Oct 2000 15:17:03 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2CAF34433A; Mon, 16 Oct 2000 14:17:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from elektron.elka.pw.edu.pl (elektron.elka.pw.edu.pl [194.29.160.2]) by lists.bell-labs.com (Postfix) with ESMTP id 9C3B744338 for ; Mon, 16 Oct 2000 14:16:20 -0400 (EDT) Received: from pm141.warszawa.cvx.ppp.tpnet.pl ([213.76.108.141]:1296 "EHLO elka.pw.edu.pl") by elektron.elka.pw.edu.pl with ESMTP id ; Mon, 16 Oct 2000 21:16:06 +0200 Message-ID: <39EB520A.2DFD60CC@elka.pw.edu.pl> From: "Piotr S. Kossowski" Organization: Warsaw University of Technology - Institute of Telecommunications X-Mailer: Mozilla 4.7 [pl] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] CANCEL - responses sequence issue Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 16 Oct 2000 21:07:54 +0200 Content-Transfer-Encoding: 7bit Hi, From rfc2543bis-02: " (...) If the server has not issued a final response for the original request, it immediately sends a 487 (Request Terminated) for the original request. The UAC confirms receipt of any final response for the original request as normal with an ACK request. CANCEL request itself is answered with a 200 (OK) response in either case. " Vijay Gurbani presented in mail "CANCEL/200 OK/BYE" following sequences: 1. UAC INVITE-------> <----------- 100 Trying <----------- 180 Ringing CANCEL ------> <----------- 487 Request Terminated ACK----------> <------------ 200 OK (CSeq: xxx CANCEL) 2. UAC INVITE-------> <----------- 100 Trying <----------- 180 Ringing CANCEL-----> <------ 200 OK (CSeq: xxx INVITE) ACK ---------> BYE ---------> <------------- 200 OK (CSeq: xxx BYE) My question is about correctness of next sequences: 3. UAC INVITE-----> <----------- 100, 18x.. CANCEL-----> <----------- 487 (CSeq: xxx INVITE) <----------- 200 (CSeq: xxx CANCEL) ACK--------> (for 487 response) Is it allowed to send 200 response just after sending 487, before getting ACK for 487 response ? If yes, what about: 4. UAC INVITE-----> <----------- 100 , 18x.. CANCEL-----> <----------- 200 (CSeq: xxx CANCEL) <----------- 487 (CSeq: xxx INVITE) ACK--------> (for 487 response) Piotr Kossowski _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 16 15:43:40 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA14580 for ; Mon, 16 Oct 2000 15:43:20 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9AFDD44348; Mon, 16 Oct 2000 14:43:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lists.bell-labs.com (Postfix) with ESMTP id 60A204433D for ; Mon, 16 Oct 2000 14:42:03 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id e9GJfwt04686; Mon, 16 Oct 2000 21:41:58 +0200 (MEST) 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 WAA14397; Mon, 16 Oct 2000 22:41:57 +0300 (EET DST) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.106.10]) by greymse1.lmf.ericsson.se (8.9.3 (PHNE_18979)/8.8.6) with ESMTP id WAA17138; Mon, 16 Oct 2000 22:41:56 +0300 (EETDST) Message-ID: <39EB59FE.8AEF772E@lmf.ericsson.se> From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Cc: Rohan Mahy Subject: Re: [SIP] Session-timer with INFO References: <4.1.20001016115728.00c3cc00@imop.cisco.com> Content-Type: multipart/mixed; boundary="------------2A12807E4C9DCB482D211810" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 16 Oct 2000 22:41:50 +0300 This is a multi-part message in MIME format. --------------2A12807E4C9DCB482D211810 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, Thanks for the comments! >If the UA crashed and rebooted and forgot about the old session, it would >respond with either a 481 call leg doesn't exist (you would know the call >is down), or a 501 (you know the UA is up, but is the call?) > >thanks, >-rohan I think that would be good, because then we could inform the user that the call doesn't exist anymore. Let's assume the UAS crashes, reboots and the UAC sends the session-timer re-INVITE. If the UAS has forgotten about the old session it would consider the re-INVITE as a new INVITE, for a new session. It would try to establish a new session - and we could suddenly start receiving provisional 18x responses (with or without SDP bodies), and/or a 200 response with a SDP body, to the session-timer re-INVITE. What do we do then? Regards, Christer Holmberg Ericsson Finland > > At 10:55 AM 10/16/00 , Christer Holmberg wrote: > > > >Hi, > > > >First, this mail is NOT a proposal for a change. I would just like to > >hear some opinions - or maybe it has already been discussed on the list? > > > >The INFO Method RFC says that for INFO requests without a message body, > >a server supporting INFO MUST respond with response code 200. So, my > >question is: why couldn't INFO be used for the session-timer > >functionality? Is the ACK the (re-)INVITE provides really necessary for > >the purpose? > > > >And, like the session-timer is defined now, the other party would not > >even have to support the INFO method, because a 501 Not Implemented > >would be sent, and the sender of the INFO would know the session is > >"alive". > > > >Just some thoughts... Please let me know if there is something I haven't > >taken into consideration. > > > >Regards, > > > >Christer Holmberg > >Ericsson Finland > > --------------2A12807E4C9DCB482D211810 Content-Type: text/x-vcard; charset=us-ascii; name="christer.holmberg.vcf" Content-Description: Card for Christer Holmberg Content-Disposition: attachment; filename="christer.holmberg.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Holmberg;Christer tel;cell:+358-40-5604412 tel;work:+358-9-2992943 x-mozilla-html:FALSE org:Ericsson;Advanced Signalling Research Laboratory adr:;;;;;; version:2.1 email;internet:christer.holmberg@lmf.ericsson.se title:System Designer fn:Christer Holmberg end:vcard --------------2A12807E4C9DCB482D211810-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 16 16:00:33 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA15054 for ; Mon, 16 Oct 2000 16:00:25 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 61AE24435E; Mon, 16 Oct 2000 15:00:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from is1-55.antd.nist.gov (is1-60.antd.nist.gov [129.6.60.251]) by lists.bell-labs.com (Postfix) with ESMTP id 68E784433D for ; Mon, 16 Oct 2000 14:59:41 -0400 (EDT) Received: from nist.gov (IDENT:mranga@stinkbug.antd.nist.gov [129.6.55.9]) by is1-55.antd.nist.gov (8.9.3/8.9.3) with ESMTP id PAA17539; Mon, 16 Oct 2000 15:55:05 -0400 (EDT) Message-ID: <39EB5E27.23B04B13@nist.gov> From: "M. Ranganathan" Reply-To: mranga@nist.gov Organization: NIST advanced networking technologies group X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Cc: Chris Harris Subject: Re: [SIP] JAIN SIP Specification References: <39E6E93C.7958683D@dynamicsoft.com> <39EB5067.6E417D89@mobilerain.com> Content-Type: text/plain; charset=iso-8859-1 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 16 Oct 2000 15:59:35 -0400 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id QAA15054 Hello! I looked at the JAIN SIP specification and I had a similar question. According to what I understand, JAIN is attempting to build an event oriented mapping interface between a SIP stack and service code. The classes in the jar file are not a sip stack but are to be mapped by the stack to its own structures. If this is the wrong interpretation, some clarification would be appreciated by the author(s). Incidentally I thought some of these classes might better be defined as interfaces rather than classes but Chris has clarified that this design choice has historical precedent in JAIN. What I think might be useful in clearing up some of this confusion is to include a scenario of a service being called (and make explicit reference to the provided jar file as appropriate). Ranga. Bobby Sardana wrote: > Hello Chris: > > After reading the JAIN SIP Specification, I have the following comments: > > a. The specification [Section 3.3.2] JAIN SIP Provider Requirements - > implies that the Provider interface interfaces with a vendor specific > SIP stack. The SIP stack, as I understand, is nothing more than the header > parsing and construction -- which is already included in the JAIN SIP jar > file. So how can the provider, or a sample provider interface be > implemented using the included SIP stack? > > In simplistic terms, how can a SIP Redirect Server be implemented using the > SipJainProviider interface? This part is not clear from the specification. > > Regards, > > Bobby.Sardana@mobilerain.com > > Chris Harris wrote: > > > Dear SIP WG, > > > > The JAIN SIP Specification is available from today for Public Review on > > the Java website. It can be found at > > http://java.sun.com/aboutJava/communityprocess/review/jsr032/index.html. > > > > The Public Review will close on 28th November. > > > > Regards, > > Chris Haris > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip -- M.Ranganathan NIST Advanced Networking Technologies Group, 100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899. Tel: 301 975 3664 Fax: 301 590 0932 ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÒ ùšŠX§‚X¬µ"þX¬¶ÏÛzYÿ•¦ìýÊ&†ÛiÿÿåŠËlý·¥—ùZnÏÜ¢oæj)fjåŠËbú? From sip-admin@lists.bell-labs.com Mon Oct 16 16:11:20 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA15261 for ; Mon, 16 Oct 2000 16:11:15 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D73B944363; Mon, 16 Oct 2000 15:11:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from is1-55.antd.nist.gov (is1-60.antd.nist.gov [129.6.60.251]) by lists.bell-labs.com (Postfix) with ESMTP id C78D744338 for ; Mon, 16 Oct 2000 15:10:17 -0400 (EDT) Received: from nist.gov (IDENT:mranga@stinkbug.antd.nist.gov [129.6.55.9]) by is1-55.antd.nist.gov (8.9.3/8.9.3) with ESMTP id QAA17841; Mon, 16 Oct 2000 16:05:42 -0400 (EDT) Message-ID: <39EB60A5.B4CC31C2@nist.gov> From: "M. Ranganathan" Reply-To: mranga@nist.gov Organization: NIST advanced networking technologies group X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Content-Type: text/plain; charset=iso-8859-1 Subject: [SIP] JAIN-SIP vs. SIP Servlets. Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 16 Oct 2000 16:10:13 -0400 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id QAA15261 Hello! Some time ago, I read a few drafts that talked about a Servlet API for SIP. It would appear that JAIN and its event architecture can provide for all the functionality talked about in these drafts (making these essentially obsolete). Am I correct in this interpretation? Thank you in advance for your replies. -- M.Ranganathan NIST Advanced Networking Technologies Group, 100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899. Tel: 301 975 3664 Fax: 301 590 0932 ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÒ ùšŠX§‚X¬µ"þX¬¶ÏÛzYÿ•¦ìýÊ&†ÛiÿÿåŠËlý·¥—ùZnÏÜ¢oæj)fjåŠËbú? From sip-admin@lists.bell-labs.com Mon Oct 16 16:20:10 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA15381 for ; Mon, 16 Oct 2000 16:20:04 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 608B644351; Mon, 16 Oct 2000 15:20:04 -0400 (EDT) Delivered-To: sip@share.research.bell-labs.com Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by lists.bell-labs.com (Postfix) with SMTP id C0CF644360 for ; Mon, 16 Oct 2000 14:44:06 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Mon Oct 16 15:42:03 EDT 2000 Received: by lists.bell-labs.com (Postfix) id A034D44380; Mon, 16 Oct 2000 15:28:53 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ans.ih.lucent.com (ans.ih.lucent.com [135.2.78.5]) by lists.bell-labs.com (Postfix) with SMTP id 5A9944437D for ; Mon, 16 Oct 2000 15:28:53 -0400 (EDT) Received: by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id OAA17165; Mon, 16 Oct 2000 14:28:49 -0500 Cc: sip@lists.bell-labs.com Received: from lucent.com by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id OAA17125; Mon, 16 Oct 2000 14:28:46 -0500 Message-ID: <39EB56EC.C6C59C4A@lucent.com> From: "Vijay K. Gurbani" Reply-To: vkg@lucent.com Organization: Intelligent Network/Messaging Systems & Internet Software Group X-Mailer: Mozilla 4.61 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: "Piotr S. Kossowski" Original-CC: sip@lists.bell-labs.com Subject: Re: [SIP] CANCEL - responses sequence issue References: <39EB520A.2DFD60CC@elka.pw.edu.pl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 16 Oct 2000 14:28:44 -0500 Content-Transfer-Encoding: 7bit "Piotr S. Kossowski" wrote: > > Hi, > > From rfc2543bis-02: > > " (...) > If the server has not issued a final response for the original > request, it immediately sends a 487 (Request Terminated) for the > original request. The UAC confirms receipt of any final response for > the original request as normal with an ACK request. CANCEL request > itself is answered with a 200 (OK) response in either case. " > > Vijay Gurbani presented in mail "CANCEL/200 OK/BYE" following > sequences: > > 1. > > UAC > INVITE-------> > <----------- 100 Trying > <----------- 180 Ringing > CANCEL ------> > <----------- 487 Request Terminated > ACK----------> > <------------ 200 OK (CSeq: xxx CANCEL) > > 2. > > UAC > INVITE-------> > <----------- 100 Trying > <----------- 180 Ringing > CANCEL-----> <------ 200 OK (CSeq: xxx INVITE) > ACK ---------> > BYE ---------> > <------------- 200 OK (CSeq: xxx BYE) > > My question is about correctness of next sequences: > > 3. > > UAC > INVITE-----> > <----------- 100, 18x.. > CANCEL-----> > <----------- 487 (CSeq: xxx INVITE) > <----------- 200 (CSeq: xxx CANCEL) > ACK--------> (for 487 response) > > Is it allowed to send 200 response just after sending 487, before > getting ACK for 487 response ? > > If yes, what about: > > 4. > UAC > INVITE-----> > <----------- 100 , 18x.. > CANCEL-----> > <----------- 200 (CSeq: xxx CANCEL) > <----------- 487 (CSeq: xxx INVITE) > ACK--------> (for 487 response) Piotr: I would presume so. In either case 3 or 4, the INVITE and CANCEL are distinct transactions; the 200 terminates the CANCEL and the 487 terminates the INVITE (which is ACK'ed). - vijay -- Vijay K. Gurbani vkg@lucent.com vkg@research.bell-labs.com vkg@acm.org Internet Software Group/Intelligent Network and Messaging Systems Lucent Technologies/Bell Labs Innovations, 263 Shuman Blvd, Rm 1A-413 Naperville, Illinois 60566 Voice: +1 630 224 0216 Fax: +1 630 713 0184 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 16 16:28:00 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA15533 for ; Mon, 16 Oct 2000 16:27:59 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E00C044344; Mon, 16 Oct 2000 15:28:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mail.comdial.com (temp.comdial.com [198.232.235.241]) by lists.bell-labs.com (Postfix) with SMTP id D18C74433D for ; Mon, 16 Oct 2000 15:27:46 -0400 (EDT) Received: FROM MAIL_1 BY mail.comdial.com ; Mon Oct 16 16:27:41 2000 -0400 Received: by mail_1.comdial.com with Internet Mail Service (5.5.2650.21) id ; Mon, 16 Oct 2000 16:26:19 -0400 Message-ID: <1D2D2C552C4CD4118BC50006293834D7446D70@mail_1.comdial.com> From: "Rigaldies, Bertrand" To: "SIP WG (E-mail)" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] SIP CGI and CPL status? Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 16 Oct 2000 16:26:19 -0400 Greetings! We're considering implementing the SIP CGI and CPL service creation environments as specified in http://www.cs.columbia.edu/~library/TR-repository/reports/reports-1999/cucs- 010-99.pdf. I'm trying to appreciate the endorsement of SIP CGI and CPL within the IP Telephony community: Are these two service creation environments being pursued by anyone? Thank you for any comment on that. Bertrand Rigaldies Sr. Principal Engineer COMDIAL Charlottesville, VA, USA _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 16 16:31:10 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA15616 for ; Mon, 16 Oct 2000 16:31:08 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0727B44344; Mon, 16 Oct 2000 15:31:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 38B514433D for ; Mon, 16 Oct 2000 15:30:31 -0400 (EDT) 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 QAA16703; Mon, 16 Oct 2000 16:30:11 -0400 (EDT) Message-ID: <39EB6554.993A65E5@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "Rigaldies, Bertrand" Cc: "SIP WG (E-mail)" Subject: Re: [SIP] SIP CGI and CPL status? References: <1D2D2C552C4CD4118BC50006293834D7446D70@mail_1.comdial.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 16 Oct 2000 16:30:12 -0400 Content-Transfer-Encoding: 7bit "Rigaldies, Bertrand" wrote: > > Greetings! We're considering implementing the SIP CGI and CPL service > creation environments as specified in > http://www.cs.columbia.edu/~library/TR-repository/reports/reports-1999/cucs- > 010-99.pdf. I'm trying to appreciate the endorsement of SIP CGI and CPL > within the IP Telephony community: Are these two service creation > environments being pursued by anyone? Thank you for any comment on that. > Our server is implementing cgi and will implement CPL, but more generally, it might be a good idea to keep a list, since this question keeps coming up. Thus, if member of this list are doing such implementation and are willing to let the world know, I'd be glad to add you to a yet-to-be-made list. (I know of a few, but they should step forward themselves). Thanks. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 16 16:46:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA15846 for ; Mon, 16 Oct 2000 16:46:02 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 882AC44338; Mon, 16 Oct 2000 15:46:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ivigate.intervoice.com (ivigate.intervoice.com [208.200.21.196]) by lists.bell-labs.com (Postfix) with ESMTP id 3EB1D44336 for ; Mon, 16 Oct 2000 15:45:42 -0400 (EDT) Received: from itmail-ict1.wichita.brite.com (itmail-ict1.wichita.brite.com [151.214.5.174]) by ivigate.intervoice.com (Build 98 8.9.3/NT-8.9.3) with ESMTP id PAA31213; Mon, 16 Oct 2000 15:44:56 -0500 Received: by itmail-ict1-imc.wichita.brite.com with Internet Mail Service (5.5.2448.0) id ; Mon, 16 Oct 2000 15:38:19 -0500 Message-ID: From: "Culpepper, Bert" To: Christer Holmberg , sip@lists.bell-labs.com Cc: Rohan Mahy Subject: RE: [SIP] Session-timer with INFO MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 16 Oct 2000 15:38:11 -0500 Some things to think about. I believe INFO is _not_ to be used to modify the state of a session. I suppose a debate is possible about session-timer affecting session state - present vs. future and if INFO is only restricted to one. But it's probably best to leave it alone. Also, the INV-200-ACK exchange allows multiple parties to agree on the duration of the session. If the recipient of the INFO request wants a smaller value (because its heartbeat interval is shorter) for the session timer it would have to send its own INFO request (unless you plan to keep the proposed Session-expires header and its use in a 200 OK). Now four messages are needed. In addition, there may be proxy issues when using INFO. There's other behavior described in the draft too. > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > Sent: Monday, October 16, 2000 3:42 PM > To: sip@lists.bell-labs.com > Cc: Rohan Mahy > Subject: Re: [SIP] Session-timer with INFO > > > > Hi, > > Thanks for the comments! > > >If the UA crashed and rebooted and forgot about the old session, it > would > >respond with either a 481 call leg doesn't exist (you would know the > call > >is down), or a 501 (you know the UA is up, but is the call?) > > > >thanks, > >-rohan > > I think that would be good, because then we could inform the user that > the call doesn't exist anymore. > > Let's assume the UAS crashes, reboots and the UAC sends the > session-timer re-INVITE. If the UAS has forgotten about the old > session > it would consider the re-INVITE as a new INVITE, for a new session. It > would try to establish a new session - and we could suddenly start > receiving provisional 18x responses (with or without SDP bodies), > and/or > a 200 response with a SDP body, to the session-timer re-INVITE. What > do > we do then? Well, you could ignore the provisional responses (you know the other end is confused) and let the session get re-established or decide to terminate the session with CANCEL/BYE. Regards, Bert > > Regards, > > Christer Holmberg > Ericsson Finland > > > > > > > > > > > At 10:55 AM 10/16/00 , Christer Holmberg wrote: > > > > > >Hi, > > > > > >First, this mail is NOT a proposal for a change. I would just like > to > > >hear some opinions - or maybe it has already been discussed on the > list? > > > > > >The INFO Method RFC says that for INFO requests without a message > body, > > >a server supporting INFO MUST respond with response code 200. So, > my > > >question is: why couldn't INFO be used for the session-timer > > >functionality? Is the ACK the (re-)INVITE provides really necessary > for > > >the purpose? > > > > > >And, like the session-timer is defined now, the other party would > not > > >even have to support the INFO method, because a 501 Not Implemented > > >would be sent, and the sender of the INFO would know the session is > > >"alive". > > > > > >Just some thoughts... Please let me know if there is something I > haven't > > >taken into consideration. > > > > > >Regards, > > > > > >Christer Holmberg > > >Ericsson Finland > > > > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 16 16:50:32 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA16002 for ; Mon, 16 Oct 2000 16:50:31 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9CED14435E; Mon, 16 Oct 2000 15:50:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lists.bell-labs.com (Postfix) with ESMTP id 50FD944338 for ; Mon, 16 Oct 2000 15:49:22 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id e9GKnEt13157; Mon, 16 Oct 2000 22:49:15 +0200 (MEST) 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 XAA16422; Mon, 16 Oct 2000 23:49:11 +0300 (EET DST) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.106.10]) by greymse1.lmf.ericsson.se (8.9.3 (PHNE_18979)/8.8.6) with ESMTP id XAA24969; Mon, 16 Oct 2000 23:49:06 +0300 (EETDST) Message-ID: <39EB69C3.4A7F24C@lmf.ericsson.se> From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Cc: clive.dellard@bt.com, jdrosen@dynamicsoft.com, simon@firetalk.com Subject: Re: [SIP] From header to ISUP CgPN mapping References: Content-Type: multipart/mixed; boundary="------------F83B670AF6267E36F6E6B9E7" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 16 Oct 2000 23:49:07 +0300 This is a multi-part message in MIME format. --------------F83B670AF6267E36F6E6B9E7 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, This is something I've also been looking into. One way would be to add a new header (e.g. Also-From). That header could be inserted by a proxy that does know the request may end up in a gateway. The UA may not know that, so he could put whatever string in the user part of the From header (e.g. his e-mail address). If the proxy then knows the UAs telephone number, for example by using some kind of database lookup, which is needed by the gateway - for any possible A-number procedure - the proxy can add that to the request. Another way would be to just define a URI parameter for the From header, but the bad thing about that is that it can not be inserted by a proxy if it was not in the request from the UA (since the From header must not be changed) by a proxy, or any other intermediate node. Note, that this response is according to Clive's mail. I do NOT support the idea of ALSO-TO headers, multiple FROM/TO headers and whatever was proposed in the previous mails :) Regards, Christer Holmberg Ericsson Finland clive.dellard@bt.com wrote: > > I agree with what you say, however, if you consider a call originating from > a SIP device (telephone or softphone) that ends up going through a gateway > to the PSTN then it is a different story. > Neither the user or the UAC can know where a call will end up, therefore the > ability to be able to provide both SIP address and SIP Telephone number > would be useful to providing a complete service as then an appropriate > calling address is available wherever the call ends up. In the scenario I > described the gateway could chose the Telephone number (ok I know there are > verification issues but that's another story). > Something like Simon's idea of an "ALSO-FROM" seems a good idea to me (this > is similar to "two number delivery" in the ISDN CLIP service) older versions > would just ignore the ALSO-FROM and it wouldn't affect the significance of > the FROM and TO headers. > > Clive > > > -----Original Message----- > > From: Jonathan Rosenberg [SMTP:jdrosen@dynamicsoft.com] > > Sent: Wednesday, October 11, 2000 7:41 PM > > To: 'clive.dellard@bt.com'; 'sip@lists.bell-labs.com' > > Subject: RE: [SIP] From header to ISUP CgPN mapping > > > > > > > > > > > -----Original Message----- > > > From: clive.dellard@bt.com [mailto:clive.dellard@bt.com] > > > Sent: Wednesday, October 11, 2000 12:17 PM > > > To: sip@lists.bell-labs.com > > > Subject: [SIP] From header to ISUP CgPN mapping > > > > > > > > > In the call flows document draft-ietf-sip-call-flows-01.txt, > > > scenario 4.1.1, > > > the message detail and text show User A using a SIP telephone > > > number rather > > > than a SIP address in the From header. The text at the > > > beginning of section > > > 4 also says "that User A still uses his/her SIP URL in the > > > Contact header, > > > since the call could be redirected back to the SIP network." > > > This implies that User A has pre-knowledge that the call is > > > going to route > > > to the PSTN and has the ability to chose the address to be > > > used in the From > > > header. > > > > No. > > > > The From header is the logical identity of the user making the call. Since > > the call is coming through a gateway, that user is some user on a PSTN > > terminal somewhere. The identity in this case can either be a tel URL, or > > a > > SIP URL at the domain of the originating network. > > > > The Contact is used for signaling addressing. Its not a logical > > identifier. > > It answers the question "where should I send SIP messages to for the rest > > of > > this call". The SIP spec says this is supposed to be a SIP URL preferably > > with a complete hostname, so that there are no ambiguities about where to > > send requests. > > > > Neither of these have anything to do with knowing where the call is going. > > > > -Jonathan R. > > > > --- > > Jonathan D. Rosenberg 72 Eagle Rock Ave. > > Chief Scientist First Floor > > dynamicsoft East Hanover, NJ 07936 > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > > http://www.dynamicsoft.com > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip --------------F83B670AF6267E36F6E6B9E7 Content-Type: text/x-vcard; charset=us-ascii; name="christer.holmberg.vcf" Content-Description: Card for Christer Holmberg Content-Disposition: attachment; filename="christer.holmberg.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Holmberg;Christer tel;cell:+358-40-5604412 tel;work:+358-9-2992943 x-mozilla-html:FALSE org:Ericsson;Advanced Signalling Research Laboratory adr:;;;;;; version:2.1 email;internet:christer.holmberg@lmf.ericsson.se title:System Designer fn:Christer Holmberg end:vcard --------------F83B670AF6267E36F6E6B9E7-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 16 16:54:32 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA16157 for ; Mon, 16 Oct 2000 16:54:14 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3C3BA44376; Mon, 16 Oct 2000 15:53:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ix.netcorps.com (ix.netcorps.com [207.1.125.106]) by lists.bell-labs.com (Postfix) with ESMTP id 062FE44338 for ; Mon, 16 Oct 2000 15:52:14 -0400 (EDT) Received: from indigosw.com (adsl-11220.turboline.skynet.be [62.4.191.212]) by ix.netcorps.com (8.9.0/8.9.0) with ESMTP id NAA12609; Mon, 16 Oct 2000 13:51:27 -0700 (PDT) Message-ID: <39EB6684.A84A7BA9@indigosw.com> From: Emmanuel Bertrand Organization: Indigo Software X-Mailer: Mozilla 4.7C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; I; PPC) X-Accept-Language: en MIME-Version: 1.0 To: Henning Schulzrinne Cc: "Rigaldies, Bertrand" , "SIP WG (E-mail)" Subject: Re: [SIP] SIP CGI and CPL status? References: <1D2D2C552C4CD4118BC50006293834D7446D70@mail_1.comdial.com> <39EB6554.993A65E5@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 16 Oct 2000 22:35:16 +0200 Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > Our server is implementing cgi and will implement CPL, but more > generally, it might be a good idea to keep a list, since this question > keeps coming up. Thus, if member of this list are doing such > implementation and are willing to let the world know, I'd be glad to add > you to a yet-to-be-made list. (I know of a few, but they should step > forward themselves). > > Thanks. > -- > Henning Schulzrinne http://www.cs.columbia.edu/~hgs > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip Indigo Software has CPL implementations for both client and server sides (CPL "editor" and CPL "server") that can be coupled to a SIP UA and a SIP proxy, respectively. We are also working on an implementation of SIP-CGI. It might indeed be a good idea to maintain a list of service creation tools that are SIP / SIP-CGI / CPL -based. Emmanuel. -- Emmanuel Bertrand mailto:eb@indigosw.com http://www.indigosw.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 16 16:58:30 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA16188 for ; Mon, 16 Oct 2000 16:58:25 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3654E4435E; Mon, 16 Oct 2000 15:58:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lists.bell-labs.com (Postfix) with ESMTP id A06CE44338 for ; Mon, 16 Oct 2000 15:57:16 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id e9GKvBt14035; Mon, 16 Oct 2000 22:57:11 +0200 (MEST) 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 XAA16655; Mon, 16 Oct 2000 23:57:10 +0300 (EET DST) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.106.10]) by greymse1.lmf.ericsson.se (8.9.3 (PHNE_18979)/8.8.6) with ESMTP id XAA25901; Mon, 16 Oct 2000 23:57:08 +0300 (EETDST) Message-ID: <39EB6BA5.317E6AEF@lmf.ericsson.se> From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Cc: "Culpepper, Bert" , Rohan Mahy Subject: Re: [SIP] Session-timer with INFO References: Content-Type: multipart/mixed; boundary="------------2C6BA3551B58EF6B61BA179E" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 16 Oct 2000 23:57:09 +0300 This is a multi-part message in MIME format. --------------2C6BA3551B58EF6B61BA179E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, >Some things to think about. > >I believe INFO is _not_ to be used to modify the state of a session. Well, I guess it depends on how you define modifying the session. The session-timer re-INVITE doesn't change the state of the session either. Of course, if there is no response to the request, or if a request is not received before the timer expires, we will change the state of the session by releasing it, but that could happend in other cases too. >I suppose a debate is possible about session-timer affecting session >state - present vs. future and if INFO is only restricted to one. But >it's probably best to leave it alone. Also, the INV-200-ACK exchange >allows multiple parties to agree on the duration of the session. If the >recipient of the INFO request wants a smaller value (because its >heartbeat interval is shorter) for the session timer it would have to >send its own INFO request (unless you plan to keep the proposed >Session-expires header and its use in a 200 OK). That was my idea. I did not plan to remove the headers related to the session-timer, just to change the request method used for the heartbeat. Regards, Christer Holmberg Ericsson Finland >Now four messages are needed. In addition, there may be proxy issues >when using INFO. There's other behavior described in the draft too. > > > -----Original Message----- > > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > > Sent: Monday, October 16, 2000 3:42 PM > > To: sip@lists.bell-labs.com > > Cc: Rohan Mahy > > Subject: Re: [SIP] Session-timer with INFO > > > > > > > > Hi, > > > > Thanks for the comments! > > > > >If the UA crashed and rebooted and forgot about the old session, it > > would > > >respond with either a 481 call leg doesn't exist (you would know the > > call > > >is down), or a 501 (you know the UA is up, but is the call?) > > > > > >thanks, > > >-rohan > > > > I think that would be good, because then we could inform the user that > > the call doesn't exist anymore. > > > > Let's assume the UAS crashes, reboots and the UAC sends the > > session-timer re-INVITE. If the UAS has forgotten about the old > > session > > it would consider the re-INVITE as a new INVITE, for a new session. It > > would try to establish a new session - and we could suddenly start > > receiving provisional 18x responses (with or without SDP bodies), > > and/or > > a 200 response with a SDP body, to the session-timer re-INVITE. What > > do > > we do then? > > Well, you could ignore the provisional responses (you know the other end > is confused) and let the session get re-established or decide to terminate > the session with CANCEL/BYE. > > Regards, > Bert > > > > > Regards, > > > > Christer Holmberg > > Ericsson Finland > > > > > > > > > > > > > > > > > > > > At 10:55 AM 10/16/00 , Christer Holmberg wrote: > > > > > > > >Hi, > > > > > > > >First, this mail is NOT a proposal for a change. I would just like > > to > > > >hear some opinions - or maybe it has already been discussed on the > > list? > > > > > > > >The INFO Method RFC says that for INFO requests without a message > > body, > > > >a server supporting INFO MUST respond with response code 200. So, > > my > > > >question is: why couldn't INFO be used for the session-timer > > > >functionality? Is the ACK the (re-)INVITE provides really necessary > > for > > > >the purpose? > > > > > > > >And, like the session-timer is defined now, the other party would > > not > > > >even have to support the INFO method, because a 501 Not Implemented > > > >would be sent, and the sender of the INFO would know the session is > > > >"alive". > > > > > > > >Just some thoughts... Please let me know if there is something I > > haven't > > > >taken into consideration. > > > > > > > >Regards, > > > > > > > >Christer Holmberg > > > >Ericsson Finland > > > > > > --------------2C6BA3551B58EF6B61BA179E Content-Type: text/x-vcard; charset=us-ascii; name="christer.holmberg.vcf" Content-Description: Card for Christer Holmberg Content-Disposition: attachment; filename="christer.holmberg.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Holmberg;Christer tel;cell:+358-40-5604412 tel;work:+358-9-2992943 x-mozilla-html:FALSE org:Ericsson;Advanced Signalling Research Laboratory adr:;;;;;; version:2.1 email;internet:christer.holmberg@lmf.ericsson.se title:System Designer fn:Christer Holmberg end:vcard --------------2C6BA3551B58EF6B61BA179E-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 16 17:09:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA16328 for ; Mon, 16 Oct 2000 17:09:04 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 02EE544344; Mon, 16 Oct 2000 16:09:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 250A84433A for ; Mon, 16 Oct 2000 16:08:24 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id RAA10219; Mon, 16 Oct 2000 17:10:13 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <4WS2XPKK>; Mon, 16 Oct 2000 17:04:18 -0400 Message-ID: From: Jonathan Rosenberg To: "'Rigaldies, Bertrand'" , "SIP WG (E-mail)" Subject: RE: [SIP] SIP CGI and CPL status? MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 16 Oct 2000 17:04:18 -0400 > -----Original Message----- > From: Rigaldies, Bertrand [mailto:Bertrand.Rigaldies@comdial.com] > Sent: Monday, October 16, 2000 4:26 PM > To: SIP WG (E-mail) > Subject: [SIP] SIP CGI and CPL status? > > > Greetings! We're considering implementing the SIP CGI and CPL service > creation environments as specified in > http://www.cs.columbia.edu/~library/TR-repository/reports/repo > rts-1999/cucs- > 010-99.pdf. I'm trying to appreciate the endorsement of SIP > CGI and CPL > within the IP Telephony community: Are these two service creation > environments being pursued by anyone? Thank you for any > comment on that. The dynamicsoft application server supports CGI, CPL, in addition to servlets. You can find a white paper describing our motivations for this architecture at: http://www.dynamicsoft.com/resources/pdf/AppServWhitePaper.pdf -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 16 17:13:59 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA16397 for ; Mon, 16 Oct 2000 17:13:51 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C33CB4438A; Mon, 16 Oct 2000 16:12:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from smtprch2.nortel.com (smtprch2.nortelnetworks.com [192.135.215.15]) by lists.bell-labs.com (Postfix) with ESMTP id 6245B44386 for ; Mon, 16 Oct 2000 16:11:59 -0400 (EDT) Received: from zrchb200.us.nortel.com (actually zrchb200) by smtprch2.nortel.com; Mon, 16 Oct 2000 16:04:01 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2652.35) id <4VMDAL1V>; Mon, 16 Oct 2000 16:07:54 -0500 Message-ID: <36FA02BD7083D411BC9E0000F8073E43E70643@crchy271.us.nortel.com> From: "Brian Stucker" To: "Culpepper, Bert" , Christer Holmberg , sip@lists.bell-labs.com Cc: Rohan Mahy Subject: RE: [SIP] Session-timer with INFO MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C037B5.22BD8D70" X-Orig: Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 16 Oct 2000 16:07:47 -0500 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_01C037B5.22BD8D70 Content-Type: text/plain; charset="iso-8859-1" Good points. Here's one more problem you may want to consider. Whenever you invoke a ping-style method of deciding if a session is alive, you open up problems due to network jitter and bandwidth. For instance, you could easily have a packet delayed at an endpoint due to a large file transfer starting up, or some other bandwidth consuming event. In this case, your ping could be delayed long enough to cause the session to drop for no good reason. You're also creating the potential for artificial problems in wireless networks by using a ping-method to keep a session alive. During a handover there may be a period where packets are in effect "muted" for a short period of time. The mute period may not, by itself be long enough to trigger a ping-timer to pop and kill the session, but if the ping was near the edge of the time envelope to be accepted as "on-time" anyhow, once again, your session could very easily drop when the media was operating just fine. Also, keep in mind, the longer you set the ping timer for, the more network resources you will likely waste over time because of the additional latentcy in discovering a "dead" session. This method has one other nasty side-effect. You'd be wasting network resources on an event that will likely not occur very often. After all, every INFO exchange except the very last one that invalidates the session could have very well not been sent without any negative impact on the session (otherwise they would have been the last one). So you've got proxies and UAs, and other transport resources being tied up processing packets that by and large are providing no value, and they're chewing up bandwidth budget that other services could be using instead. Please keep in mind that not everyone is looking at implementing SIP on a 10Mbit+ hardwired LAN (or has to scale up to tremendous numbers of users), pinging and triangle-routing can be the death-knell of these sorts of networks. Because of all of this, I think it would be a very bad idea for a UA to send an INFO to a client who repeatedly tells him "I don't understand INFO" to see if he's alive. He may not understand INFO because that particular network doesn't deem the bandwidth required for this mechanism as being best used for that purpose. If someone tells you "don't send me this method" then don't send it to them. Otherwise your implementation may be viewed as favorably as the record clubs that used to require you to send them a card every month telling them not to send you anything by some groups. Brian Stucker Nortel Networks -----Original Message----- From: Culpepper, Bert [mailto:bert.culpepper@intervoice-brite.com] Sent: Monday, October 16, 2000 3:38 PM To: Christer Holmberg; sip@lists.bell-labs.com Cc: Rohan Mahy Subject: RE: [SIP] Session-timer with INFO Some things to think about. I believe INFO is _not_ to be used to modify the state of a session. I suppose a debate is possible about session-timer affecting session state - present vs. future and if INFO is only restricted to one. But it's probably best to leave it alone. Also, the INV-200-ACK exchange allows multiple parties to agree on the duration of the session. If the recipient of the INFO request wants a smaller value (because its heartbeat interval is shorter) for the session timer it would have to send its own INFO request (unless you plan to keep the proposed Session-expires header and its use in a 200 OK). Now four messages are needed. In addition, there may be proxy issues when using INFO. There's other behavior described in the draft too. > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > Sent: Monday, October 16, 2000 3:42 PM > To: sip@lists.bell-labs.com > Cc: Rohan Mahy > Subject: Re: [SIP] Session-timer with INFO > > > > Hi, > > Thanks for the comments! > > >If the UA crashed and rebooted and forgot about the old session, it > would > >respond with either a 481 call leg doesn't exist (you would know the > call > >is down), or a 501 (you know the UA is up, but is the call?) > > > >thanks, > >-rohan > > I think that would be good, because then we could inform the user that > the call doesn't exist anymore. > > Let's assume the UAS crashes, reboots and the UAC sends the > session-timer re-INVITE. If the UAS has forgotten about the old > session > it would consider the re-INVITE as a new INVITE, for a new session. It > would try to establish a new session - and we could suddenly start > receiving provisional 18x responses (with or without SDP bodies), > and/or > a 200 response with a SDP body, to the session-timer re-INVITE. What > do > we do then? Well, you could ignore the provisional responses (you know the other end is confused) and let the session get re-established or decide to terminate the session with CANCEL/BYE. Regards, Bert > > Regards, > > Christer Holmberg > Ericsson Finland > > > > > > > > > > > At 10:55 AM 10/16/00 , Christer Holmberg wrote: > > > > > >Hi, > > > > > >First, this mail is NOT a proposal for a change. I would just like > to > > >hear some opinions - or maybe it has already been discussed on the > list? > > > > > >The INFO Method RFC says that for INFO requests without a message > body, > > >a server supporting INFO MUST respond with response code 200. So, > my > > >question is: why couldn't INFO be used for the session-timer > > >functionality? Is the ACK the (re-)INVITE provides really necessary > for > > >the purpose? > > > > > >And, like the session-timer is defined now, the other party would > not > > >even have to support the INFO method, because a 501 Not Implemented > > >would be sent, and the sender of the INFO would know the session is > > >"alive". > > > > > >Just some thoughts... Please let me know if there is something I > haven't > > >taken into consideration. > > > > > >Regards, > > > > > >Christer Holmberg > > >Ericsson Finland > > > > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip ------_=_NextPart_001_01C037B5.22BD8D70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [SIP] Session-timer with INFO

Good points. Here's one more problem you may want to = consider. Whenever you invoke a ping-style method of deciding if a = session is alive, you open up problems due to network jitter and = bandwidth. For instance, you could easily have a packet delayed at an = endpoint due to a large file transfer starting up, or some other = bandwidth consuming event. In this case, your ping could be delayed = long enough to cause the session to drop for no good reason.

You're also creating the potential for artificial = problems in wireless networks by using a ping-method to keep a session = alive. During a handover there may be a period where packets are in = effect "muted" for a short period of time. The mute period = may not, by itself be long enough to trigger a ping-timer to pop and = kill the session, but if the ping was near the edge of the time = envelope to be accepted as "on-time" anyhow, once again, your = session could very easily drop when the media was operating just = fine.

Also, keep in mind, the longer you set the ping timer = for, the more network resources you will likely waste over time because = of the additional latentcy in discovering a "dead" = session.

This method has one other nasty side-effect. You'd be = wasting network resources on an event that will likely not occur very = often. After all, every INFO exchange except the very last one that = invalidates the session could have very well not been sent without any = negative impact on the session (otherwise they would have been the last = one). So you've got proxies and UAs, and other transport resources = being tied up processing packets that by and large are providing no = value, and they're chewing up bandwidth budget that other services = could be using instead.

Please keep in mind that not everyone is looking at = implementing SIP on a 10Mbit+ hardwired LAN (or has to scale up to = tremendous numbers of users), pinging and triangle-routing can be the = death-knell of these sorts of networks.

Because of all of this, I think it would be a very = bad idea for a UA to send an INFO to a client who repeatedly tells him = "I don't understand INFO" to see if he's alive. He may not = understand INFO because that particular network doesn't deem the = bandwidth required for this mechanism as being best used for that = purpose. If someone tells you "don't send me this method" = then don't send it to them. Otherwise your implementation may be viewed = as favorably as the record clubs that used to require you to send them = a card every month telling them not to send you anything by some = groups.

Brian Stucker
Nortel Networks

-----Original Message-----
From: Culpepper, Bert [mailto:bert.culpeppe= r@intervoice-brite.com]
Sent: Monday, October 16, 2000 3:38 PM
To: Christer Holmberg; = sip@lists.bell-labs.com
Cc: Rohan Mahy
Subject: RE: [SIP] Session-timer with INFO


Some things to think about.

I believe INFO is _not_ to be used to modify the = state of a session.  I
suppose a debate is possible about session-timer = affecting session
state - present vs. future and if INFO is only = restricted to one.  But it's
probably best to leave it alone.  Also, the = INV-200-ACK exchange
allows multiple parties to agree on the duration of = the session.  If the
recipient of the INFO request wants a smaller value = (because its
heartbeat interval is shorter) for the session timer = it would have to
send its own INFO request (unless you plan to keep = the proposed
Session-expires header and its use in a 200 = OK).  Now four
messages are needed.  In addition, there may be = proxy issues when
using INFO.  There's other behavior described = in the draft too.

> -----Original Message-----
> From: Christer Holmberg [mailto:christer.holmbe= rg@lmf.ericsson.se]
> Sent: Monday, October 16, 2000 3:42 PM
> To: sip@lists.bell-labs.com
> Cc: Rohan Mahy
> Subject: Re: [SIP] Session-timer with = INFO
>
>
>
> Hi,
>
> Thanks for the comments!
>
> >If the UA crashed and rebooted and forgot = about the old session, it
> would
> >respond with either a 481 call leg doesn't = exist (you would know the
> call
> >is down), or a 501 (you know the UA is up, = but is the call?)
> >
> >thanks,
> >-rohan
>
> I think that would be good, because then we = could inform the user that
> the call doesn't exist anymore.
>
> Let's assume the UAS crashes, reboots and the = UAC sends the
> session-timer re-INVITE. If the UAS has = forgotten about the old
> session
> it would consider the re-INVITE as a new = INVITE, for a new session. It
> would try to establish a new session - and we = could suddenly start
> receiving provisional 18x responses (with or = without SDP bodies),
> and/or
> a 200 response with a SDP body, to the = session-timer re-INVITE. What
> do
> we do then?

Well, you could ignore the provisional responses (you = know the other end
is confused) and let the session get re-established = or decide to terminate
the session with CANCEL/BYE.

Regards,
Bert

>
> Regards,
>
> Christer Holmberg
> Ericsson Finland
>
>
>
>
>
>
>
> >
> > At 10:55 AM 10/16/00 , Christer Holmberg = wrote:
> > >
> > >Hi,
> > >
> > >First, this mail is NOT a proposal for = a change. I would just like
> to
> > >hear some opinions - or maybe it has = already been discussed on the
> list?
> > >
> > >The INFO Method RFC says that for INFO = requests without a message
> body,
> > >a server supporting INFO MUST respond = with response code 200. So,
> my
> > >question is: why couldn't INFO be used = for the session-timer
> > >functionality? Is the ACK the = (re-)INVITE provides really necessary
> for
> > >the purpose?
> > >
> > >And, like the session-timer is defined = now, the other party would
> not
> > >even have to support the INFO method, = because a 501 Not Implemented
> > >would be sent, and the sender of the = INFO would know the session is
> > >"alive".
> > >
> > >Just some thoughts... Please let me = know if there is something I
> haven't
> > >taken into consideration.
> > >
> > >Regards,
> > >
> > >Christer Holmberg
> > >Ericsson Finland
> > >
>

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip

------_=_NextPart_001_01C037B5.22BD8D70-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 16 17:31:21 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA16654 for ; Mon, 16 Oct 2000 17:31:14 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0795644338; Mon, 16 Oct 2000 16:31:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lists.bell-labs.com (Postfix) with ESMTP id 70A8444336 for ; Mon, 16 Oct 2000 16:30:22 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id e9GLUHZ24325; Mon, 16 Oct 2000 23:30:17 +0200 (MEST) 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 AAA17455; Tue, 17 Oct 2000 00:30:16 +0300 (EET DST) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.106.10]) by greymse1.lmf.ericsson.se (8.9.3 (PHNE_18979)/8.8.6) with ESMTP id AAA29705; Tue, 17 Oct 2000 00:30:15 +0300 (EETDST) Message-ID: <39EB7368.794876C8@lmf.ericsson.se> From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Cc: Brian Stucker Subject: Re: [SIP] Session-timer with INFO References: <36FA02BD7083D411BC9E0000F8073E43E70643@crchy271.us.nortel.com> Content-Type: multipart/mixed; boundary="------------973279060F594FCB084FF915" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 17 Oct 2000 00:30:16 +0300 This is a multi-part message in MIME format. --------------973279060F594FCB084FF915 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, >Good points. Here's one more problem you may want to consider. >Whenever you invoke a ping-style method of deciding if a session is >alive, you open up problems due to network jitter and bandwidth. For >instance, you could easily have a packet delayed at an endpoint due to >a large file transfer starting up, or some other bandwidth consuming >event. In this case, your ping could be delayed long enough to cause >the session to drop for no good reason. Well, this could be the case no matter which method (INVITE, INFO, or whatever...) you use in the heartbeat request... >You're also creating the potential for artificial problems in wireless >networks by using a ping-method to keep a session alive. During a >handover there may be a period where packets are in effect "muted" for >a short period of time. The mute period may not, by itself be long >enough to trigger a ping-timer to pop and kill the session, but if the >ping was near the edge of the time envelope to be accepted as >"on-time" anyhow, once again, your session could very easily drop when >the media was operating just fine. >Also, keep in mind, the longer you set the ping timer for, the more >network resources you will likely waste over time because of the >additional latentcy in discovering a "dead" session. Just to clarify, this "ping-method" IS already defined for SIP (draft-ietf-sip-session-timer-02.txt), and re-INVITEs are used to ping. My idea was about replacing the re-INVITE with INFO, which mean we would actually save resources since we don't have to send ACK every time. >This method has one other nasty side-effect. You'd be wasting network >resources on an event that will likely not occur very often. After >all, every INFO exchange except the very last one that invalidates the >session could have very well not been sent without any negative impact >on the session (otherwise they would have been the last one). So >you've got proxies and UAs, and other transport resources being tied >up processing packets that by and large are providing no value, and >they're chewing up bandwidth budget that other services could be using >instead. That is an interesting point, and it is valid also for a number of other SIP extensions where extra messages are sent (e.g. PRACK), but it is another discussion. >Please keep in mind that not everyone is looking at implementing SIP >on a 10Mbit+ hardwired LAN (or has to scale up to tremendous numbers >of users), pinging and triangle-routing can be the death-knell of >these sorts of networks. Who said "bandwidth is free"? :) >Because of all of this, I think it would be a very bad idea for a UA >to send an INFO to a client who repeatedly tells him "I don't >understand INFO" to see if he's alive. The number of messages on the network will be the same no matter if we send an INVITE which he understands, or an INFO he may not understand. Also, when we receive the response for the INVITE we also have to send back an ACK, which is not the case when INFO is used. >He may not understand INFO because that particular network doesn't deem >the bandwidth required for this mechanism as being best used for that >purpose. If someone tells you "don't send me this method" then don't send >it to them. Again, this has nothing to do with the bandwith issue. Even if I send re-INVITEs, which the other party understands, he can not tell me not to send any more re-INVITEs. >Otherwise your implementation may be viewed as favorably as the record >clubs that used to require you to send them a card every month telling >them not to send you anything by some groups. Well, it's not up to me to decide when and if an operator will use the session-timer, as defined in the draft, or not - I am just trying to make it as good (and less resource consuming) if he choses to. Regards, Christer Holmberg Ericsson Finland > > Brian Stucker > Nortel Networks > > -----Original Message----- > From: Culpepper, Bert [mailto:bert.culpepper@intervoice-brite.com] > Sent: Monday, October 16, 2000 3:38 PM > To: Christer Holmberg; sip@lists.bell-labs.com > Cc: Rohan Mahy > Subject: RE: [SIP] Session-timer with INFO > > Some things to think about. > > I believe INFO is _not_ to be used to modify the state of a session. > I > suppose a debate is possible about session-timer affecting session > state - present vs. future and if INFO is only restricted to one. But > it's > probably best to leave it alone. Also, the INV-200-ACK exchange > allows multiple parties to agree on the duration of the session. If > the > recipient of the INFO request wants a smaller value (because its > heartbeat interval is shorter) for the session timer it would have to > send its own INFO request (unless you plan to keep the proposed > Session-expires header and its use in a 200 OK). Now four > messages are needed. In addition, there may be proxy issues when > using INFO. There's other behavior described in the draft too. > > > -----Original Message----- > > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > > Sent: Monday, October 16, 2000 3:42 PM > > To: sip@lists.bell-labs.com > > Cc: Rohan Mahy > > Subject: Re: [SIP] Session-timer with INFO > > > > > > > > Hi, > > > > Thanks for the comments! > > > > >If the UA crashed and rebooted and forgot about the old session, it > > > would > > >respond with either a 481 call leg doesn't exist (you would know > the > > call > > >is down), or a 501 (you know the UA is up, but is the call?) > > > > > >thanks, > > >-rohan > > > > I think that would be good, because then we could inform the user > that > > the call doesn't exist anymore. > > > > Let's assume the UAS crashes, reboots and the UAC sends the > > session-timer re-INVITE. If the UAS has forgotten about the old > > session > > it would consider the re-INVITE as a new INVITE, for a new session. > It > > would try to establish a new session - and we could suddenly start > > receiving provisional 18x responses (with or without SDP bodies), > > and/or > > a 200 response with a SDP body, to the session-timer re-INVITE. What > > > do > > we do then? > > Well, you could ignore the provisional responses (you know the other > end > is confused) and let the session get re-established or decide to > terminate > the session with CANCEL/BYE. > > Regards, > Bert > > > > > Regards, > > > > Christer Holmberg > > Ericsson Finland > > > > > > > > > > > > > > > > > > > > At 10:55 AM 10/16/00 , Christer Holmberg wrote: > > > > > > > >Hi, > > > > > > > >First, this mail is NOT a proposal for a change. I would just > like > > to > > > >hear some opinions - or maybe it has already been discussed on > the > > list? > > > > > > > >The INFO Method RFC says that for INFO requests without a message > > > body, > > > >a server supporting INFO MUST respond with response code 200. So, > > > my > > > >question is: why couldn't INFO be used for the session-timer > > > >functionality? Is the ACK the (re-)INVITE provides really > necessary > > for > > > >the purpose? > > > > > > > >And, like the session-timer is defined now, the other party would > > > not > > > >even have to support the INFO method, because a 501 Not > Implemented > > > >would be sent, and the sender of the INFO would know the session > is > > > >"alive". > > > > > > > >Just some thoughts... Please let me know if there is something I > > haven't > > > >taken into consideration. > > > > > > > >Regards, > > > > > > > >Christer Holmberg > > > >Ericsson Finland > > > > > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip --------------973279060F594FCB084FF915 Content-Type: text/x-vcard; charset=us-ascii; name="christer.holmberg.vcf" Content-Description: Card for Christer Holmberg Content-Disposition: attachment; filename="christer.holmberg.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Holmberg;Christer tel;cell:+358-40-5604412 tel;work:+358-9-2992943 x-mozilla-html:FALSE org:Ericsson;Advanced Signalling Research Laboratory adr:;;;;;; version:2.1 email;internet:christer.holmberg@lmf.ericsson.se title:System Designer fn:Christer Holmberg end:vcard --------------973279060F594FCB084FF915-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 16 17:37:11 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA16731 for ; Mon, 16 Oct 2000 17:37:11 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5C37F4436A; Mon, 16 Oct 2000 16:37:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id F10F144364 for ; Mon, 16 Oct 2000 16:36:46 -0400 (EDT) Received: from dynamicsoft.com (userab71.ie.uudial.com [212.120.133.171]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id RAA10528; Mon, 16 Oct 2000 17:38:49 -0400 (EDT) Message-ID: <39EB74F5.504322E4@dynamicsoft.com> From: Chris Harris Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: mranga@nist.gov Cc: sip@lists.bell-labs.com, jainsip@sun.com, Jonathan Rosenberg Subject: Re: [SIP] JAIN-SIP vs. SIP Servlets. References: <39EB60A5.B4CC31C2@nist.gov> Content-Type: multipart/alternative; boundary="------------2624FF4AFCB751978DAFD0A1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 16 Oct 2000 22:36:53 +0100 --------------2624FF4AFCB751978DAFD0A1 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Ranga, Yes, it is certainly true that the JAIN SIP API can provide all the functionality that the SIP Servlet API does. This could be viewed as you mentioned - the JAIN SIP API making the SIP Servlet API obsolete, but the converse could be argued too - if it weren't for the fact that the SIP Servlet API doesn't allow client applications. However the SIP Servlet API does mention that a complementary client API will be developed to address this issue, so the possibility of two competing Java SIP API's certainly exists...Had the client API been available previously, there may not have been a JAIN SIP API at all - it may have just been the Java SIP API - after all, if a JAIN service wished to incorporate email or web pages, would not use a JAIN HTTP or JAIN SMTP API? :) Chris "M. Ranganathan" wrote: > Hello! > > Some time ago, I read a few drafts that talked about a Servlet API for > SIP. It would appear that JAIN and its event architecture can provide > for all the functionality talked about in these drafts (making these > essentially obsolete). Am I correct in this interpretation? > > Thank you in advance for your replies. > > -- > M.Ranganathan > NIST Advanced Networking Technologies Group, > 100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899. > Tel: 301 975 3664 Fax: 301 590 0932 > > Hƒæj)bž b²Ôˆ>X¬¶ÆÞ–YZnÇ(šm§ÿåŠËlmée•¦ìr‰¿™¨¥™©ÿ–+-ŠwèþÈ© --------------2624FF4AFCB751978DAFD0A1 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Ranga,

Yes, it is certainly true that the JAIN SIP API can provide all the functionality that the SIP Servlet API does. This could be viewed as you mentioned - the JAIN SIP API making the SIP Servlet API obsolete, but the converse could be argued too - if it weren't for the fact that the SIP Servlet API doesn't allow client applications.

However the SIP Servlet API does mention that a complementary client API will be developed to address this issue, so the possibility of  two competing Java SIP API's certainly exists...Had the client API been available previously, there may not have been a JAIN SIP API at all - it may have just been the Java SIP API - after all, if a JAIN service wished to incorporate email or web pages, would not use a JAIN HTTP or JAIN SMTP API? :)

Chris
 

"M. Ranganathan" wrote:

Hello!

Some time ago,  I read a few drafts that talked about a Servlet API for
SIP. It would appear that JAIN and its event architecture can provide
for all the functionality  talked about in  these drafts (making these
essentially obsolete).  Am I correct in this interpretation?

Thank you  in advance for your replies.

--
M.Ranganathan
NIST Advanced Networking Technologies Group,
100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899.
Tel: 301 975 3664 Fax: 301 590 0932

Hƒæj)bž b²Ôˆ>X¬¶ÆÞ–YZnÇ(šm§ÿåŠËlmée•¦ìr‰¿™¨¥™©ÿ–+-ŠwèþÈ©

--------------2624FF4AFCB751978DAFD0A1-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 16 18:19:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA17037 for ; Mon, 16 Oct 2000 18:19:00 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7572A44338; Mon, 16 Oct 2000 17:19:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from smtprch2.nortel.com (smtprch2.nortelnetworks.com [192.135.215.15]) by lists.bell-labs.com (Postfix) with ESMTP id 29EAF44336 for ; Mon, 16 Oct 2000 17:18:34 -0400 (EDT) Received: from zrchb200.us.nortel.com (actually zrchb200) by smtprch2.nortel.com; Mon, 16 Oct 2000 16:54:40 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2652.35) id <4VMDANBY>; Mon, 16 Oct 2000 16:58:39 -0500 Message-ID: <36FA02BD7083D411BC9E0000F8073E43E706E1@crchy271.us.nortel.com> From: "Brian Stucker" To: Christer Holmberg , sip@lists.bell-labs.com Subject: RE: [SIP] Session-timer with INFO MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C037BC.3BD5A390" X-Orig: Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 16 Oct 2000 16:58:36 -0500 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_01C037BC.3BD5A390 Content-Type: text/plain; charset="iso-8859-1" Hi, Yeah, I knew that this method is already in there, and that there is a re-INVITE method that's worse from the viewpoint of number of messages. I'm just throwing things out there for people to consider when thinking about these types of mechanisms in their designs (and a draft suggests one way of doing things, not necessarily always the best way of doing things). I strongly suspect that this mechanism was considered as part of a relatively high-bandwidth, low jitter network environment with a relatively small number of users. It seems to me that there are those who would like to solve every problem that they come across by throwing more bandwidth at it, which is fine if you've got tons of bandwidth to spare (I definitely don't consider bandwidth free) and are running on a network with low jitter. Not everyone has that luxury, and by pinning them down by requiring them to support a solution that does not work well in other environments means just that more people are going to do one of two things: 1. Not be completely compliant to all RFCs and drafts. 2. Not implement SIP for their solution. That's why I was saying that it's a bad idea to rely on a 501 response to an INFO for keep-alive purposes. The other guy is telling you in a SIP compliant manner that he doesn't want you to send him INFO messages for whatever reason (just doesn't support it, or doesn't want them clogging up their network). Even though this mechanism is compliant to the protocol, I wouldn't characterize it as being compliant to the spirit of the protocol (although it is ingenious). Brian Stucker Nortel Networks -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] Sent: Monday, October 16, 2000 4:30 PM To: sip@lists.bell-labs.com Cc: Stucker, Brian [RICH2:WI12:EXCH] Subject: Re: [SIP] Session-timer with INFO Hi, >Good points. Here's one more problem you may want to consider. >Whenever you invoke a ping-style method of deciding if a session is >alive, you open up problems due to network jitter and bandwidth. For >instance, you could easily have a packet delayed at an endpoint due to >a large file transfer starting up, or some other bandwidth consuming >event. In this case, your ping could be delayed long enough to cause >the session to drop for no good reason. Well, this could be the case no matter which method (INVITE, INFO, or whatever...) you use in the heartbeat request... >You're also creating the potential for artificial problems in wireless >networks by using a ping-method to keep a session alive. During a >handover there may be a period where packets are in effect "muted" for >a short period of time. The mute period may not, by itself be long >enough to trigger a ping-timer to pop and kill the session, but if the >ping was near the edge of the time envelope to be accepted as >"on-time" anyhow, once again, your session could very easily drop when >the media was operating just fine. >Also, keep in mind, the longer you set the ping timer for, the more >network resources you will likely waste over time because of the >additional latentcy in discovering a "dead" session. Just to clarify, this "ping-method" IS already defined for SIP (draft-ietf-sip-session-timer-02.txt), and re-INVITEs are used to ping. My idea was about replacing the re-INVITE with INFO, which mean we would actually save resources since we don't have to send ACK every time. >This method has one other nasty side-effect. You'd be wasting network >resources on an event that will likely not occur very often. After >all, every INFO exchange except the very last one that invalidates the >session could have very well not been sent without any negative impact >on the session (otherwise they would have been the last one). So >you've got proxies and UAs, and other transport resources being tied >up processing packets that by and large are providing no value, and >they're chewing up bandwidth budget that other services could be using >instead. That is an interesting point, and it is valid also for a number of other SIP extensions where extra messages are sent (e.g. PRACK), but it is another discussion. >Please keep in mind that not everyone is looking at implementing SIP >on a 10Mbit+ hardwired LAN (or has to scale up to tremendous numbers >of users), pinging and triangle-routing can be the death-knell of >these sorts of networks. Who said "bandwidth is free"? :) >Because of all of this, I think it would be a very bad idea for a UA >to send an INFO to a client who repeatedly tells him "I don't >understand INFO" to see if he's alive. The number of messages on the network will be the same no matter if we send an INVITE which he understands, or an INFO he may not understand. Also, when we receive the response for the INVITE we also have to send back an ACK, which is not the case when INFO is used. >He may not understand INFO because that particular network doesn't deem >the bandwidth required for this mechanism as being best used for that >purpose. If someone tells you "don't send me this method" then don't send >it to them. Again, this has nothing to do with the bandwith issue. Even if I send re-INVITEs, which the other party understands, he can not tell me not to send any more re-INVITEs. >Otherwise your implementation may be viewed as favorably as the record >clubs that used to require you to send them a card every month telling >them not to send you anything by some groups. Well, it's not up to me to decide when and if an operator will use the session-timer, as defined in the draft, or not - I am just trying to make it as good (and less resource consuming) if he choses to. Regards, Christer Holmberg Ericsson Finland > > Brian Stucker > Nortel Networks > > -----Original Message----- > From: Culpepper, Bert [mailto:bert.culpepper@intervoice-brite.com] > Sent: Monday, October 16, 2000 3:38 PM > To: Christer Holmberg; sip@lists.bell-labs.com > Cc: Rohan Mahy > Subject: RE: [SIP] Session-timer with INFO > > Some things to think about. > > I believe INFO is _not_ to be used to modify the state of a session. > I > suppose a debate is possible about session-timer affecting session > state - present vs. future and if INFO is only restricted to one. But > it's > probably best to leave it alone. Also, the INV-200-ACK exchange > allows multiple parties to agree on the duration of the session. If > the > recipient of the INFO request wants a smaller value (because its > heartbeat interval is shorter) for the session timer it would have to > send its own INFO request (unless you plan to keep the proposed > Session-expires header and its use in a 200 OK). Now four > messages are needed. In addition, there may be proxy issues when > using INFO. There's other behavior described in the draft too. > > > -----Original Message----- > > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > > Sent: Monday, October 16, 2000 3:42 PM > > To: sip@lists.bell-labs.com > > Cc: Rohan Mahy > > Subject: Re: [SIP] Session-timer with INFO > > > > > > > > Hi, > > > > Thanks for the comments! > > > > >If the UA crashed and rebooted and forgot about the old session, it > > > would > > >respond with either a 481 call leg doesn't exist (you would know > the > > call > > >is down), or a 501 (you know the UA is up, but is the call?) > > > > > >thanks, > > >-rohan > > > > I think that would be good, because then we could inform the user > that > > the call doesn't exist anymore. > > > > Let's assume the UAS crashes, reboots and the UAC sends the > > session-timer re-INVITE. If the UAS has forgotten about the old > > session > > it would consider the re-INVITE as a new INVITE, for a new session. > It > > would try to establish a new session - and we could suddenly start > > receiving provisional 18x responses (with or without SDP bodies), > > and/or > > a 200 response with a SDP body, to the session-timer re-INVITE. What > > > do > > we do then? > > Well, you could ignore the provisional responses (you know the other > end > is confused) and let the session get re-established or decide to > terminate > the session with CANCEL/BYE. > > Regards, > Bert > > > > > Regards, > > > > Christer Holmberg > > Ericsson Finland > > > > > > > > > > > > > > > > > > > > At 10:55 AM 10/16/00 , Christer Holmberg wrote: > > > > > > > >Hi, > > > > > > > >First, this mail is NOT a proposal for a change. I would just > like > > to > > > >hear some opinions - or maybe it has already been discussed on > the > > list? > > > > > > > >The INFO Method RFC says that for INFO requests without a message > > > body, > > > >a server supporting INFO MUST respond with response code 200. So, > > > my > > > >question is: why couldn't INFO be used for the session-timer > > > >functionality? Is the ACK the (re-)INVITE provides really > necessary > > for > > > >the purpose? > > > > > > > >And, like the session-timer is defined now, the other party would > > > not > > > >even have to support the INFO method, because a 501 Not > Implemented > > > >would be sent, and the sender of the INFO would know the session > is > > > >"alive". > > > > > > > >Just some thoughts... Please let me know if there is something I > > haven't > > > >taken into consideration. > > > > > > > >Regards, > > > > > > > >Christer Holmberg > > > >Ericsson Finland > > > > > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip ------_=_NextPart_001_01C037BC.3BD5A390 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [SIP] Session-timer with INFO

Hi,

Yeah, I knew that this method is already in there, = and that there is a re-INVITE method that's worse from the viewpoint of = number of messages. I'm just throwing things out there for people to = consider when thinking about these types of mechanisms in their designs = (and a draft suggests one way of doing things, not necessarily always = the best way of doing things). I strongly suspect that this mechanism = was considered as part of a relatively high-bandwidth, low jitter = network environment with a relatively small number of users.

It seems to me that there are those who would like to = solve every problem that they come across by throwing more bandwidth at = it, which is fine if you've got tons of bandwidth to spare (I = definitely don't consider bandwidth free) and are running on a network = with low jitter. Not everyone has that luxury, and by pinning them down = by requiring them to support a solution that does not work well in = other environments means just that more people are going to do one of = two things:

1. Not be completely compliant to all RFCs and = drafts.
2. Not implement SIP for their solution.

That's why I was saying that it's a bad idea to rely = on a 501 response to an INFO for keep-alive purposes. The other guy is = telling you in a SIP compliant manner that he doesn't want you to send = him INFO messages for whatever reason (just doesn't support it, or = doesn't want them clogging up their network). Even though this = mechanism is compliant to the protocol, I wouldn't characterize it as = being compliant to the spirit of the protocol (although it is = ingenious).

Brian Stucker
Nortel Networks

-----Original Message-----
From: Christer Holmberg [mailto:christer.holmbe= rg@lmf.ericsson.se]
Sent: Monday, October 16, 2000 4:30 PM
To: sip@lists.bell-labs.com
Cc: Stucker, Brian [RICH2:WI12:EXCH]
Subject: Re: [SIP] Session-timer with INFO



Hi,

>Good points. Here's one more problem you may want = to consider.
>Whenever you invoke a ping-style method of = deciding if a session is
>alive, you open up problems due to network = jitter and bandwidth. For
>instance, you could easily have a packet delayed = at an endpoint due to
>a large file transfer starting up, or some other = bandwidth consuming
>event. In this case, your ping could be delayed = long enough to cause
>the session to drop for no good reason.

Well, this could be the case no matter which method = (INVITE, INFO, or
whatever...) you use in the heartbeat = request...
 
>You're also creating the potential for = artificial problems in wireless
>networks by using a ping-method to keep a = session alive. During a
>handover there may be a period where packets are = in effect "muted" for
>a short period of time. The mute period may not, = by itself be long
>enough to trigger a ping-timer to pop and kill = the session, but if the
>ping was near the edge of the time envelope to = be accepted as
>"on-time" anyhow, once again, your = session could very easily drop when
>the media was operating just fine.
>Also, keep in mind, the longer you set the ping = timer for, the more
>network resources you will likely waste over = time because of the
>additional latentcy in discovering a = "dead" session.

Just to clarify, this "ping-method" IS = already defined for SIP
(draft-ietf-sip-session-timer-02.txt), and = re-INVITEs are used to ping.
My idea was about replacing the re-INVITE with INFO, = which mean we would
actually save resources since we don't have to send = ACK every time.
 
>This method has one other nasty side-effect. = You'd be wasting network
>resources on an event that will likely not occur = very often. After
>all, every INFO exchange except the very last = one that invalidates the
>session could have very well not been sent = without any negative impact
>on the session (otherwise they would have been = the last one). So
>you've got proxies and UAs, and other transport = resources being tied
>up processing packets that by and large are = providing no value, and
>they're chewing up bandwidth budget that other = services could be using
>instead.

That is an interesting point, and it is valid also = for a number of other
SIP extensions where extra messages are sent (e.g. = PRACK), but it is
another discussion.
 
>Please keep in mind that not everyone is looking = at implementing SIP
>on a 10Mbit+ hardwired LAN (or has to scale up = to tremendous numbers
>of users), pinging and triangle-routing can be = the death-knell of
>these sorts of networks.

Who said "bandwidth is free"? :)
 
>Because of all of this, I think it would be a = very bad idea for a UA
>to send an INFO to a client who repeatedly tells = him "I don't
>understand INFO" to see if he's = alive.

The number of messages on the network will be the = same no matter if we
send an INVITE which he understands, or an INFO he = may not understand.
Also, when we receive the response for the INVITE we = also have to send
back an ACK, which is not the case when INFO is = used.

>He may not understand INFO because that = particular network doesn't deem >the bandwidth required for this = mechanism as being best used for that >purpose. If someone tells you = "don't send me this method" then don't send >it to = them.

Again, this has nothing to do with the bandwith = issue. Even if I send
re-INVITEs, which the other party understands, he = can not tell me not to
send any more re-INVITEs.

>Otherwise your implementation may be viewed as = favorably as the record
>clubs that used to require you to send them a = card every month telling
>them not to send you anything by some = groups.

Well, it's not up to me to decide when and if an = operator will use the
session-timer, as defined in the draft, or not - I = am just trying to
make it as good (and less resource consuming) if he = choses to.

Regards,

Christer Holmberg
Ericsson Finland


>
> Brian Stucker
> Nortel Networks
>
> -----Original Message-----
> From: Culpepper, Bert [mailto:bert.culpeppe= r@intervoice-brite.com]
> Sent: Monday, October 16, 2000 3:38 PM
> To: Christer Holmberg; = sip@lists.bell-labs.com
> Cc: Rohan Mahy
> Subject: RE: [SIP] Session-timer with = INFO
>
> Some things to think about.
>
> I believe INFO is _not_ to be used to modify = the state of a session.
> I
> suppose a debate is possible about = session-timer affecting session
> state - present vs. future and if INFO is only = restricted to one.  But
> it's
> probably best to leave it alone.  Also, = the INV-200-ACK exchange
> allows multiple parties to agree on the = duration of the session.  If
> the
> recipient of the INFO request wants a smaller = value (because its
> heartbeat interval is shorter) for the session = timer it would have to
> send its own INFO request (unless you plan to = keep the proposed
> Session-expires header and its use in a 200 = OK).  Now four
> messages are needed.  In addition, there = may be proxy issues when
> using INFO.  There's other behavior = described in the draft too.
>
> > -----Original Message-----
> > From: Christer Holmberg [mailto:christer.holmbe= rg@lmf.ericsson.se]
> > Sent: Monday, October 16, 2000 3:42 = PM
> > To: sip@lists.bell-labs.com
> > Cc: Rohan Mahy
> > Subject: Re: [SIP] Session-timer with = INFO
> >
> >
> >
> > Hi,
> >
> > Thanks for the comments!
> >
> > >If the UA crashed and rebooted and = forgot about the old session, it
>
> > would
> > >respond with either a 481 call leg = doesn't exist (you would know
> the
> > call
> > >is down), or a 501 (you know the UA is = up, but is the call?)
> > >
> > >thanks,
> > >-rohan
> >
> > I think that would be good, because then = we could inform the user
> that
> > the call doesn't exist anymore.
> >
> > Let's assume the UAS crashes, reboots and = the UAC sends the
> > session-timer re-INVITE. If the UAS has = forgotten about the old
> > session
> > it would consider the re-INVITE as a new = INVITE, for a new session.
> It
> > would try to establish a new session - and = we could suddenly start
> > receiving provisional 18x responses (with = or without SDP bodies),
> > and/or
> > a 200 response with a SDP body, to the = session-timer re-INVITE. What
>
> > do
> > we do then?
>
> Well, you could ignore the provisional = responses (you know the other
> end
> is confused) and let the session get = re-established or decide to
> terminate
> the session with CANCEL/BYE.
>
> Regards,
> Bert
>
> >
> > Regards,
> >
> > Christer Holmberg
> > Ericsson Finland
> >
> >
> >
> >
> >
> >
> >
> > >
> > > At 10:55 AM 10/16/00 , Christer = Holmberg wrote:
> > > >
> > > >Hi,
> > > >
> > > >First, this mail is NOT a = proposal for a change. I would just
> like
> > to
> > > >hear some opinions - or maybe it = has already been discussed on
> the
> > list?
> > > >
> > > >The INFO Method RFC says that for = INFO requests without a message
>
> > body,
> > > >a server supporting INFO MUST = respond with response code 200. So,
>
> > my
> > > >question is: why couldn't INFO be = used for the session-timer
> > > >functionality? Is the ACK the = (re-)INVITE provides really
> necessary
> > for
> > > >the purpose?
> > > >
> > > >And, like the session-timer is = defined now, the other party would
>
> > not
> > > >even have to support the INFO = method, because a 501 Not
> Implemented
> > > >would be sent, and the sender of = the INFO would know the session
> is
> > > >"alive".
> > > >
> > > >Just some thoughts... Please let = me know if there is something I
> > haven't
> > > >taken into consideration.
> > > >
> > > >Regards,
> > > >
> > > >Christer Holmberg
> > > >Ericsson Finland
> > > >
> >
>
> = _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip

------_=_NextPart_001_01C037BC.3BD5A390-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 16 22:08:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA19466 for ; Mon, 16 Oct 2000 22:08:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E02EC44338; Mon, 16 Oct 2000 21:08:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sina.com (unknown [202.106.187.165]) by lists.bell-labs.com (Postfix) with SMTP id EB3A844336 for ; Mon, 16 Oct 2000 21:07:43 -0400 (EDT) Received: (qmail 13800 invoked by uid 99); 17 Oct 2000 02:10:43 -0000 Message-ID: <20001017021043.13799.qmail@sina.com> From: snowbirder To: sip@lists.bell-labs.com X-Mailer: SinaMail 3.0Beta (FireToad) X-Priority: 3 Subject: [SIP] un-subscribed Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue Oct 17 02:10:43 2000 un-subscribed ______________________________________ =================================================================== ÐÂÀËÃâ·Ñµç×ÓÓÊÏä http://mail.sina.com.cn ÐÂÀËÍƳö°ÂÔ˶ÌÐÅÏ¢ÊÖ»úµã²¥·þÎñ http://sms.sina.com.cn/ _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 16 22:09:14 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA19491 for ; Mon, 16 Oct 2000 22:09:13 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id DDD1F44376; Mon, 16 Oct 2000 21:08:10 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sina.com (unknown [202.106.187.163]) by lists.bell-labs.com (Postfix) with SMTP id EB87644336 for ; Mon, 16 Oct 2000 21:07:50 -0400 (EDT) Received: (qmail 22631 invoked by uid 99); 17 Oct 2000 02:13:48 -0000 Message-ID: <20001017021348.22630.qmail@sina.com> From: snowbirder To: sip@lists.bell-labs.com X-Mailer: SinaMail 3.0Beta (FireToad) X-Priority: 3 Subject: [SIP] un-subscribed Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue Oct 17 02:13:48 2000 un-subscribed ______________________________________ =================================================================== ÐÂÀËÃâ·Ñµç×ÓÓÊÏä http://mail.sina.com.cn ÐÂÀËÍƳö°ÂÔ˶ÌÐÅÏ¢ÊÖ»úµã²¥·þÎñ http://sms.sina.com.cn/ _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 17 01:57:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA28666 for ; Tue, 17 Oct 2000 01:57:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6314544338; Tue, 17 Oct 2000 00:57:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lists.bell-labs.com (Postfix) with ESMTP id 8523D44336 for ; Tue, 17 Oct 2000 00:56:22 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id e9H5uHt17545 for ; Tue, 17 Oct 2000 07:56:17 +0200 (MEST) 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 IAA02190 for ; Tue, 17 Oct 2000 08:56:17 +0300 (EET DST) Received: from lmf.ericsson.se (E005004B52C74-udp423992.lmf.ericsson.se [131.160.30.29]) by greymse1.lmf.ericsson.se (8.9.3 (PHNE_18979)/8.8.6) with ESMTP id IAA11004 for ; Tue, 17 Oct 2000 08:56:16 +0300 (EETDST) Message-ID: <39EBE9FD.460BB9D9@lmf.ericsson.se> From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Content-Type: multipart/mixed; boundary="------------6AF032ACAD78A23050729B2D" Subject: [SIP] Contiguos CSeq number Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 17 Oct 2000 08:56:13 +0300 This is a multi-part message in MIME format. --------------6AF032ACAD78A23050729B2D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, I have a question about the CSeq number value. Consider the following case: A UAC sends a request to a UAS using CSeq=1. The UAC then sends another request to the same UAS using CSeq=2. However, for some reason the UAS never gets the request. It may, for example, be terminated by an intermediate proxy, sending a response to it, or it may be cancelled before it reaches the UAS. After that, the UAC sends a third request, using CSeq=3, to the UAS. So, the UAS will receive two requests, the first and the third, but not the second. Chapter 6.20 in the RFCbis says that the CSeq number must be contiguous. However, in this case the UAS will never receive the second request. Should it "wait" for it (it will never arrive...) or what is the purpose of the line in the RFCbis? Regards, Christer Holmberg Ericsson Finland --------------6AF032ACAD78A23050729B2D Content-Type: text/x-vcard; charset=us-ascii; name="christer.holmberg.vcf" Content-Description: Card for Christer Holmberg Content-Disposition: attachment; filename="christer.holmberg.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Holmberg;Christer tel;cell:+358-40-5604412 tel;work:+358-9-2992943 x-mozilla-html:FALSE org:Ericsson;Advanced Signalling Research Laboratory adr:;;;;;; version:2.1 email;internet:christer.holmberg@lmf.ericsson.se title:System Designer fn:Christer Holmberg end:vcard --------------6AF032ACAD78A23050729B2D-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 17 04:42:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA06090 for ; Tue, 17 Oct 2000 04:42:04 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 08A4944338; Tue, 17 Oct 2000 03:42:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by lists.bell-labs.com (Postfix) with ESMTP id 8F81744336 for ; Tue, 17 Oct 2000 03:41:32 -0400 (EDT) Received: from daebh01nok.americas.nokia.com (daebh01nok.americas.nokia.com [172.18.242.182]) by mgw-x1.nokia.com (8.10.2/8.10.2/Nokia) with ESMTP id e9GFQnK02668; Mon, 16 Oct 2000 18:26:50 +0300 (EET DST) Received: by daebh01nok with Internet Mail Service (5.5.2652.78) id <483HKX4M>; Mon, 16 Oct 2000 10:23:09 -0500 Message-ID: From: Cliff.Harris@nokia.com To: vkg@lucent.com, jdrosen@dynamicsoft.com Cc: sip@lists.bell-labs.com, sip-implementors@cs.columbia.edu Subject: RE: [SIP] CANCEL/200 OK/BYE MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 16 Oct 2000 10:19:42 -0500 > -----Original Message----- > From: EXT Vijay K. Gurbani [mailto:vkg@lucent.com] [ . . . ] > I think the spec should state that a UAC MUST send a BYE iff after > having sent a CANCEL (for an in-progress INVITE), it got a 200 class > response to the INVITE (which means that the 200 OK and > CANCEL "crossed > each other on the wire"). > > Thanks, > > - vijay > -- > Vijay K. Gurbani vkg@lucent.com vkg@research.bell-labs.com > vkg@acm.org > Internet Software Group/Intelligent Network and Messaging Systems > Lucent Technologies/Bell Labs Innovations, 263 Shuman Blvd, Rm 1A-413 > Naperville, Illinois 60566 Voice: +1 630 224 0216 Fax: +1 > 630 713 0184 > The note in section 4.2.5 of the RFC-bis draft makes it fairly clear that BYE may be used instead of CANCEL. One very good reason for using BYE instead of CANCEL is that BYE may have an attachment and CANCEL may not. In the SIP-T case, if the UAC wants to include an attached PSTN message when the caller hangs up before the far end has answered, BYE has to be used. I guess there are issues with tags and routes and all that. I don't know if the spec addresses this, but in my naive view it would make sense if a proxy that received a BYE without a tag sent it to all possible destinations, to ensure that the UAS that received the INVITE will also get the BYE. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 17 05:05:00 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA06188 for ; Tue, 17 Oct 2000 05:04:59 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D79ED44338; Tue, 17 Oct 2000 04:05:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from drago1.ubiquity.net (unknown [194.202.146.92]) by lists.bell-labs.com (Postfix) with SMTP id 954B244336 for ; Tue, 17 Oct 2000 04:04:16 -0400 (EDT) Received: from gecko.ubiquity.co.uk by drago1.ubiquity.net via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 17 Oct 2000 09:04:44 UT Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id KAA07486; Tue, 17 Oct 2000 10:02:31 +0100 (BST) Message-ID: <39EC15A7.2D7D20E0@ubiquity.net> From: Neil Deason Organization: Ubiquity Software Corporation Limited X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "Rigaldies, Bertrand" Cc: "SIP WG (E-mail)" Subject: Re: [SIP] SIP CGI and CPL status? References: <1D2D2C552C4CD4118BC50006293834D7446D70@mail_1.comdial.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 17 Oct 2000 10:02:31 +0100 Content-Transfer-Encoding: 7bit "Rigaldies, Bertrand" wrote: > > Greetings! We're considering implementing the SIP CGI and CPL service > creation environments as specified in > http://www.cs.columbia.edu/~library/TR-repository/reports/reports-1999/cucs- > 010-99.pdf. I'm trying to appreciate the endorsement of SIP CGI and CPL > within the IP Telephony community: Are these two service creation > environments being pursued by anyone? Thank you for any comment on that. At the 5th SIP bakeoff there were at least 3 CPL implementations, from Dymanicsoft, Indigo and Ubiquity. Bear in mind that all of CPL, CGI or Servlets are still only at best "work in progress" not standards. The CPL requirements are a RFC but the language definition is only at Internet Draft stage. The main SIP Servlet draft expired in March 2000. I am not sure of the exact status of SIP-CGI. For wider vendor have a look through the links off: http://www.pulver.com/sip/products.html Cheers, Neil. -- Ubiquity Software Corporation, UK http://www.ubiquity.net _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 17 06:02:00 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA06518 for ; Tue, 17 Oct 2000 06:01:59 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2C15044338; Tue, 17 Oct 2000 05:02:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lists.bell-labs.com (Postfix) with ESMTP id 1387044336 for ; Tue, 17 Oct 2000 05:01:01 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id e9HA0sZ15674; Tue, 17 Oct 2000 12:00:54 +0200 (MEST) 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 NAA22075; Tue, 17 Oct 2000 13:00:52 +0300 (EET DST) Received: from lmf.ericsson.se (E005004B52C74-udp423992.lmf.ericsson.se [131.160.30.29]) by greymse1.lmf.ericsson.se (8.9.3 (PHNE_18979)/8.8.6) with ESMTP id NAA18310; Tue, 17 Oct 2000 13:00:51 +0300 (EETDST) Message-ID: <39EC2350.A27E8BEF@lmf.ericsson.se> From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Cc: Lars Berggren Subject: Re: [SIP] Session-timer with INFO References: Content-Type: multipart/mixed; boundary="------------3DB0CE78900B9316709F02A3" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 17 Oct 2000 13:00:48 +0300 This is a multi-part message in MIME format. --------------3DB0CE78900B9316709F02A3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, >>Hi, >> >>First, this mail is NOT a proposal for a change. I would just like to >>hear some opinions - or maybe it has already been discussed on the list? >> >>The INFO Method RFC says that for INFO requests without a message body, >>a server supporting INFO MUST respond with response code 200. So, my >>question is: why couldn't INFO be used for the session-timer >>functionality? Is the ACK the (re-)INVITE provides really necessary for >>the purpose? >> >>And, like the session-timer is defined now, the other party would not >>even have to support the INFO method, because a 501 Not Implemented >>would be sent, and the sender of the INFO would know the session is >>"alive". >> >>Just some thoughts... Please let me know if there is something I haven't >>taken into consideration. >> > >I think the re-INVITE mechanism is far more better because the >information about what session is refreshed is carried in the SDP of the >re-INVITE. The INFO approach has the significant disadvantage that >proxies that use the session timer might have to store a *lot* of state >information about each session. That is not true. The session is identified using the Call-ID. In fact, another advantage of using INFO is that you don't have to send a message body at all. Using re-INVITE, you must send a copy of the original message, and the UAS must check if the SDP is a copy (session-timer) or if it is a new SDP, when the session should be modified. Again, we save resources. Comments? Regards, Christer Holmberg Ericsson Finland > > Regards /Lars > > > Regards, > > > > Christer Holmberg > > Ericsson Finland > > Lars Berggren > Intertex Data AB tel: +46-8-6282828 > Sundbyberg, Sweden fax: +46-8-6286414 --------------3DB0CE78900B9316709F02A3 Content-Type: text/x-vcard; charset=us-ascii; name="christer.holmberg.vcf" Content-Description: Card for Christer Holmberg Content-Disposition: attachment; filename="christer.holmberg.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Holmberg;Christer tel;cell:+358-40-5604412 tel;work:+358-9-2992943 x-mozilla-html:FALSE org:Ericsson;Advanced Signalling Research Laboratory adr:;;;;;; version:2.1 email;internet:christer.holmberg@lmf.ericsson.se title:System Designer fn:Christer Holmberg end:vcard --------------3DB0CE78900B9316709F02A3-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 17 06:05:59 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA06529 for ; Tue, 17 Oct 2000 06:05:59 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 490E54434C; Tue, 17 Oct 2000 05:06:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lists.bell-labs.com (Postfix) with ESMTP id 3D02D44336 for ; Tue, 17 Oct 2000 05:05:09 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id e9HA53Z16663 for ; Tue, 17 Oct 2000 12:05:03 +0200 (MEST) 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 NAA22574 for ; Tue, 17 Oct 2000 13:05:01 +0300 (EET DST) Received: from localhost (root@localhost) by greymse1.lmf.ericsson.se (8.9.3 (PHNE_18979)/8.8.6) with ESMTP id NAA19513 for ; Tue, 17 Oct 2000 13:05:00 +0300 (EETDST) From: Gonzalo.Camarillo@lmf.ericsson.se X-OpenMail-Hops: 1 Message-Id: MIME-Version: 1.0 To: sip@lists.bell-labs.com Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline ;Creation-Date="Tue, 17 Oct 2000 12:56:05 +0300" ;Modification-Date="Tue, 17 Oct 2000 13:04:52 +0300" Content-Transfer-Encoding: 7bit Subject: [SIP] CANCEL and stateless proxies Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 17 Oct 2000 13:04:53 +0300 Content-Transfer-Encoding: 7bit Hi, A CANCEL request for a previous INVITE follows the same path as the INVITE. This way the CANCEL request arrives to the same set of hosts as the INVITE. Stateful proxies storing transaction state perform this routing fine. What about stateless proxies? The CANCEL might be routed in a different way than the previous INVITE. This issue is somehow related to the "BYE after a INVITE" issue. It is preferable to send a CANCEL rather than a BYE after a INVITE because stateful proxies storing transaction state will route the CANCEL properly. The BYE might be routed in a wrong way. My question is: the same way proxies storing just transaction state (not call state) might route a BYE to a different host than the previous INVITE, a stateless proxy might route a CANCEL in a wrong way. What am I missing? Thanks, Gonzalo _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 17 06:28:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA06628 for ; Tue, 17 Oct 2000 06:28:02 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2329B44348; Tue, 17 Oct 2000 05:28:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lists.bell-labs.com (Postfix) with ESMTP id 38D1644336 for ; Tue, 17 Oct 2000 05:27:43 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id e9HARWZ21193 for ; Tue, 17 Oct 2000 12:27:33 +0200 (MEST) 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 NAA27759 for ; Tue, 17 Oct 2000 13:27:30 +0300 (EET DST) Received: from localhost (root@localhost) by greymse1.lmf.ericsson.se (8.9.3 (PHNE_18979)/8.8.6) with ESMTP id NAA03849 for ; Tue, 17 Oct 2000 13:27:30 +0300 (EETDST) From: Gonzalo.Camarillo@lmf.ericsson.se X-OpenMail-Hops: 1 Message-Id: MIME-Version: 1.0 To: sip@lists.bell-labs.com Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline ;Creation-Date="Tue, 17 Oct 2000 13:15:31 +0300" ;Modification-Date="Tue, 17 Oct 2000 13:27:26 +0300" Content-Transfer-Encoding: 7bit Subject: [SIP] 100 responses Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 17 Oct 2000 13:27:27 +0300 Content-Transfer-Encoding: 7bit Hi, Page 73 of draft-ietf-sip-rfc2543bis-02.ps says: "100 responses SHOULD NOT be forwarded, other 1xx responses MAY be forwarded, possible after..." Shouldn't it say that 100 responses SHOULD NOT be forwarded by statefull proxies but MUST be forwarded by stateless proxies? Regards, Gonzalo _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 17 07:13:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA07721 for ; Tue, 17 Oct 2000 07:13:02 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5E68444348; Tue, 17 Oct 2000 06:13:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from felix.intertex.se (unknown [195.22.82.2]) by lists.bell-labs.com (Postfix) with ESMTP id E8FAB44336 for ; Tue, 17 Oct 2000 03:06:00 -0400 (EDT) From: Lars Berggren To: Christer Holmberg Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Session-timer with INFO In-Reply-To: <39EB40FB.4CDB19CC@lmf.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 17 Oct 2000 10:06:06 +0200 (CEST) On Mon, 16 Oct 2000, Christer Holmberg wrote: > > Hi, > > First, this mail is NOT a proposal for a change. I would just like to > hear some opinions - or maybe it has already been discussed on the list? > > The INFO Method RFC says that for INFO requests without a message body, > a server supporting INFO MUST respond with response code 200. So, my > question is: why couldn't INFO be used for the session-timer > functionality? Is the ACK the (re-)INVITE provides really necessary for > the purpose? > > And, like the session-timer is defined now, the other party would not > even have to support the INFO method, because a 501 Not Implemented > would be sent, and the sender of the INFO would know the session is > "alive". > > Just some thoughts... Please let me know if there is something I haven't > taken into consideration. > I think the re-INVITE mechanism is far more better because the information about what session is refreshed is carried in the SDP of the re-INVITE. The INFO approach has the significant disadvantage that proxies that use the session timer might have to store a *lot* of state information about each session. Regards /Lars > Regards, > > Christer Holmberg > Ericsson Finland Lars Berggren Intertex Data AB tel: +46-8-6282828 Sundbyberg, Sweden fax: +46-8-6286414 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 17 07:16:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA07777 for ; Tue, 17 Oct 2000 07:16:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 44D3E44353; Tue, 17 Oct 2000 06:16:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mail.speedventures.com (unknown [212.75.74.99]) by lists.bell-labs.com (Postfix) with ESMTP id D2E0944348 for ; Tue, 17 Oct 2000 06:15:20 -0400 (EDT) Received: from HASH ([192.168.27.115]) by mail.speedventures.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id VCKN31CK; Tue, 17 Oct 2000 13:11:15 +0200 From: "Hisham Khartabil" To: , Subject: RE: [SIP] CANCEL and stateless proxies 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.2919.6700 In-Reply-To: Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 17 Oct 2000 14:14:11 +0300 Content-Transfer-Encoding: 7bit Hi, The INVITE and the CANCEL are independent transactions. It doesn't really matter if they follow the same routing path or not. It is the UAS that needs to know that a request is being cancelled. The 487 response, for the INVITE, returned by the callee (UAS) upon reception of the CANCEL will traverse back using the Via headers in the INVITE. The 200 for the CANCEL does the same. The solves the statefull proxy problem. Stateless proxies don't keep state anyway. Regards, Hisham Hotsip -----Original Message----- From: sip-admin@lists.bell-labs.com [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Gonzalo.Camarillo@lmf.ericsson.se Sent: Tuesday, 17 October 2000 1:05 PM To: sip@lists.bell-labs.com Subject: [SIP] CANCEL and stateless proxies Hi, A CANCEL request for a previous INVITE follows the same path as the INVITE. This way the CANCEL request arrives to the same set of hosts as the INVITE. Stateful proxies storing transaction state perform this routing fine. What about stateless proxies? The CANCEL might be routed in a different way than the previous INVITE. This issue is somehow related to the "BYE after a INVITE" issue. It is preferable to send a CANCEL rather than a BYE after a INVITE because stateful proxies storing transaction state will route the CANCEL properly. The BYE might be routed in a wrong way. My question is: the same way proxies storing just transaction state (not call state) might route a BYE to a different host than the previous INVITE, a stateless proxy might route a CANCEL in a wrong way. What am I missing? Thanks, Gonzalo _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 17 07:47:00 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA08393 for ; Tue, 17 Oct 2000 07:47:00 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id CD3E644338; Tue, 17 Oct 2000 06:47:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id AA19B44336 for ; Tue, 17 Oct 2000 06:46:08 -0400 (EDT) Received: from dynamicsoft.com (ip39.honxr1.ras.tele.dk [195.249.119.39]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id HAA13450; Tue, 17 Oct 2000 07:48:07 -0400 (EDT) Message-ID: <39EC3B5A.A3646FDC@dynamicsoft.com> From: Anders Kristensen Organization: dynamicsoft X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 To: Christer Holmberg Cc: SIP Subject: Re: [SIP] Session-timer with INFO References: <4.1.20001016115728.00c3cc00@imop.cisco.com> <39EB59FE.8AEF772E@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 17 Oct 2000 13:43:22 +0200 Content-Transfer-Encoding: 7bit We had this whole discussion about a year ago. Unfortunately the archives doesn't seem to go that far back, but it seems pointless to repeat that discussion. Is there an archive somewhere for the old list? Anders Christer Holmberg wrote: > > Hi, > > Thanks for the comments! > > >If the UA crashed and rebooted and forgot about the old session, it would > >respond with either a 481 call leg doesn't exist (you would know the call > >is down), or a 501 (you know the UA is up, but is the call?) > > > >thanks, > >-rohan > > I think that would be good, because then we could inform the user that > the call doesn't exist anymore. > > Let's assume the UAS crashes, reboots and the UAC sends the > session-timer re-INVITE. If the UAS has forgotten about the old session > it would consider the re-INVITE as a new INVITE, for a new session. It > would try to establish a new session - and we could suddenly start > receiving provisional 18x responses (with or without SDP bodies), and/or > a 200 response with a SDP body, to the session-timer re-INVITE. What do > we do then? > > Regards, > > Christer Holmberg > Ericsson Finland > > > > > At 10:55 AM 10/16/00 , Christer Holmberg wrote: > > > > > >Hi, > > > > > >First, this mail is NOT a proposal for a change. I would just like to > > >hear some opinions - or maybe it has already been discussed on the list? > > > > > >The INFO Method RFC says that for INFO requests without a message body, > > >a server supporting INFO MUST respond with response code 200. So, my > > >question is: why couldn't INFO be used for the session-timer > > >functionality? Is the ACK the (re-)INVITE provides really necessary for > > >the purpose? > > > > > >And, like the session-timer is defined now, the other party would not > > >even have to support the INFO method, because a 501 Not Implemented > > >would be sent, and the sender of the INFO would know the session is > > >"alive". > > > > > >Just some thoughts... Please let me know if there is something I haven't > > >taken into consideration. > > > > > >Regards, > > > > > >Christer Holmberg > > >Ericsson Finland > > > -- Anders Kristensen _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 17 09:12:07 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA10820 for ; Tue, 17 Oct 2000 09:12:07 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C79CC44338; Tue, 17 Oct 2000 08:12:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lists.bell-labs.com (Postfix) with ESMTP id EC62544336 for ; Tue, 17 Oct 2000 08:11:40 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id e9HDBYt24838; Tue, 17 Oct 2000 15:11:34 +0200 (MEST) 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 QAA10354; Tue, 17 Oct 2000 16:11:31 +0300 (EET DST) Received: from lmf.ericsson.se (E005004B52C74-udp423992.lmf.ericsson.se [131.160.30.29]) by greymse1.lmf.ericsson.se (8.9.3 (PHNE_18979)/8.8.6) with ESMTP id QAA13563; Tue, 17 Oct 2000 16:11:29 +0300 (EETDST) Message-ID: <39EC4FFE.90FADFE3@lmf.ericsson.se> From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: SIP Cc: Anders Kristensen Subject: Re: [SIP] Session-timer with INFO References: <4.1.20001016115728.00c3cc00@imop.cisco.com> <39EB59FE.8AEF772E@lmf.ericsson.se> <39EC3B5A.A3646FDC@dynamicsoft.com> Content-Type: multipart/mixed; boundary="------------156A100DAD1A3DC2B2740E73" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 17 Oct 2000 16:11:26 +0300 This is a multi-part message in MIME format. --------------156A100DAD1A3DC2B2740E73 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, I found the archive, and the thread. The discussion was very much about the fact that by using re-INVITEs the session can be "automatically" re-established if the UAS has booted, and I guess this works fine as long as we don't get any 18x responses, which may include ringtones, messages and who knows what (we may even receive a 3xx Redirect message) And, if the UAC uses INFO, and receive 481 Call leg/Transaction Does Not Exist (e.g. if the UAS has booted), it can choose to send a re-INVITE, and be prepared to receive 18x messages, to reestablish the session. Also, I don't think the UAS will crash that often, compared to what we would save by not having to send ACKs etc. Regards, Christer Holmberg Ericsson Finland Anders Kristensen wrote: > > We had this whole discussion about a year ago. Unfortunately the > archives doesn't seem to go that far back, but it seems pointless to > repeat that discussion. Is there an archive somewhere for the old list? > > Anders > > Christer Holmberg wrote: > > > > Hi, > > > > Thanks for the comments! > > > > >If the UA crashed and rebooted and forgot about the old session, it would > > >respond with either a 481 call leg doesn't exist (you would know the call > > >is down), or a 501 (you know the UA is up, but is the call?) > > > > > >thanks, > > >-rohan > > > > I think that would be good, because then we could inform the user that > > the call doesn't exist anymore. > > > > Let's assume the UAS crashes, reboots and the UAC sends the > > session-timer re-INVITE. If the UAS has forgotten about the old session > > it would consider the re-INVITE as a new INVITE, for a new session. It > > would try to establish a new session - and we could suddenly start > > receiving provisional 18x responses (with or without SDP bodies), and/or > > a 200 response with a SDP body, to the session-timer re-INVITE. What do > > we do then? > > > > Regards, > > > > Christer Holmberg > > Ericsson Finland > > > > > > > > At 10:55 AM 10/16/00 , Christer Holmberg wrote: > > > > > > > >Hi, > > > > > > > >First, this mail is NOT a proposal for a change. I would just like to > > > >hear some opinions - or maybe it has already been discussed on the list? > > > > > > > >The INFO Method RFC says that for INFO requests without a message body, > > > >a server supporting INFO MUST respond with response code 200. So, my > > > >question is: why couldn't INFO be used for the session-timer > > > >functionality? Is the ACK the (re-)INVITE provides really necessary for > > > >the purpose? > > > > > > > >And, like the session-timer is defined now, the other party would not > > > >even have to support the INFO method, because a 501 Not Implemented > > > >would be sent, and the sender of the INFO would know the session is > > > >"alive". > > > > > > > >Just some thoughts... Please let me know if there is something I haven't > > > >taken into consideration. > > > > > > > >Regards, > > > > > > > >Christer Holmberg > > > >Ericsson Finland > > > > > > -- > Anders Kristensen --------------156A100DAD1A3DC2B2740E73 Content-Type: text/x-vcard; charset=us-ascii; name="christer.holmberg.vcf" Content-Description: Card for Christer Holmberg Content-Disposition: attachment; filename="christer.holmberg.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Holmberg;Christer tel;cell:+358-40-5604412 tel;work:+358-9-2992943 x-mozilla-html:FALSE org:Ericsson;Advanced Signalling Research Laboratory adr:;;;;;; version:2.1 email;internet:christer.holmberg@lmf.ericsson.se title:System Designer fn:Christer Holmberg end:vcard --------------156A100DAD1A3DC2B2740E73-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 17 09:20:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA10949 for ; Tue, 17 Oct 2000 09:20:05 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0EF0F44338; Tue, 17 Oct 2000 08:20:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 9363544336 for ; Tue, 17 Oct 2000 08:19:55 -0400 (EDT) Received: from dynamicsoft.com (ip89.honxr1.ras.tele.dk [195.249.119.89]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id JAA14095; Tue, 17 Oct 2000 09:21:57 -0400 (EDT) Message-ID: <39EC5159.A01DF89B@dynamicsoft.com> From: Anders Kristensen Organization: dynamicsoft X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 To: Christer Holmberg Cc: SIP Subject: Re: [SIP] Session-timer with INFO References: <4.1.20001016115728.00c3cc00@imop.cisco.com> <39EB59FE.8AEF772E@lmf.ericsson.se> <39EC3B5A.A3646FDC@dynamicsoft.com> <39EC4FFE.90FADFE3@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 17 Oct 2000 15:17:13 +0200 Content-Transfer-Encoding: 7bit I actually agree with you (except I would have used a new method rather than INFO). I just don't think it's very likely, given that the arguments are largely unchanged, that people will be willing to modify the session timer mechanism at this late stage. Anyway, maybe you should post the archive pointer and then we can at least have a fully informed discussion. Anders Christer Holmberg wrote: > > Hi, > > I found the archive, and the thread. The discussion was very much about > the fact that by using re-INVITEs the session can be "automatically" > re-established if the UAS has booted, and I guess this works fine as > long as we don't get any 18x responses, which may include ringtones, > messages and who knows what (we may even receive a 3xx Redirect message) > And, if the UAC uses INFO, and receive 481 Call leg/Transaction Does Not > Exist (e.g. if the UAS has booted), it can choose to send a re-INVITE, > and be prepared to receive 18x messages, to reestablish the session. > > Also, I don't think the UAS will crash that often, compared to what we > would save by not having to send ACKs etc. > > Regards, > > Christer Holmberg > Ericsson Finland > > Anders Kristensen wrote: > > > > We had this whole discussion about a year ago. Unfortunately the > > archives doesn't seem to go that far back, but it seems pointless to > > repeat that discussion. Is there an archive somewhere for the old list? > > > > Anders > > > > Christer Holmberg wrote: > > > > > > Hi, > > > > > > Thanks for the comments! > > > > > > >If the UA crashed and rebooted and forgot about the old session, it would > > > >respond with either a 481 call leg doesn't exist (you would know the call > > > >is down), or a 501 (you know the UA is up, but is the call?) > > > > > > > >thanks, > > > >-rohan > > > > > > I think that would be good, because then we could inform the user that > > > the call doesn't exist anymore. > > > > > > Let's assume the UAS crashes, reboots and the UAC sends the > > > session-timer re-INVITE. If the UAS has forgotten about the old session > > > it would consider the re-INVITE as a new INVITE, for a new session. It > > > would try to establish a new session - and we could suddenly start > > > receiving provisional 18x responses (with or without SDP bodies), and/or > > > a 200 response with a SDP body, to the session-timer re-INVITE. What do > > > we do then? > > > > > > Regards, > > > > > > Christer Holmberg > > > Ericsson Finland > > > > > > > > > > > At 10:55 AM 10/16/00 , Christer Holmberg wrote: > > > > > > > > > >Hi, > > > > > > > > > >First, this mail is NOT a proposal for a change. I would just like to > > > > >hear some opinions - or maybe it has already been discussed on the list? > > > > > > > > > >The INFO Method RFC says that for INFO requests without a message body, > > > > >a server supporting INFO MUST respond with response code 200. So, my > > > > >question is: why couldn't INFO be used for the session-timer > > > > >functionality? Is the ACK the (re-)INVITE provides really necessary for > > > > >the purpose? > > > > > > > > > >And, like the session-timer is defined now, the other party would not > > > > >even have to support the INFO method, because a 501 Not Implemented > > > > >would be sent, and the sender of the INFO would know the session is > > > > >"alive". > > > > > > > > > >Just some thoughts... Please let me know if there is something I haven't > > > > >taken into consideration. > > > > > > > > > >Regards, > > > > > > > > > >Christer Holmberg > > > > >Ericsson Finland > > > > > > > > > -- > > Anders Kristensen _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 17 09:50:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA11619 for ; Tue, 17 Oct 2000 09:50:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id CE1A944338; Tue, 17 Oct 2000 08:50:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lists.bell-labs.com (Postfix) with ESMTP id A0CA944336 for ; Tue, 17 Oct 2000 08:49:04 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id e9HDmst29427; Tue, 17 Oct 2000 15:48:54 +0200 (MEST) 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 QAA13098; Tue, 17 Oct 2000 16:48:52 +0300 (EET DST) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.29]) by greymse1.lmf.ericsson.se (8.9.3 (PHNE_18979)/8.8.6) with ESMTP id QAA20298; Tue, 17 Oct 2000 16:48:51 +0300 (EETDST) Message-ID: <39EC58C0.FCE5B7A2@lmf.ericsson.se> From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: SIP Cc: Anders Kristensen Subject: Re: [SIP] Session-timer with INFO References: <4.1.20001016115728.00c3cc00@imop.cisco.com> <39EB59FE.8AEF772E@lmf.ericsson.se> <39EC3B5A.A3646FDC@dynamicsoft.com> <39EC4FFE.90FADFE3@lmf.ericsson.se> <39EC5159.A01DF89B@dynamicsoft.com> Content-Type: multipart/mixed; boundary="------------3DA38E2F8D7F3FD3129A1B05" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 17 Oct 2000 16:48:48 +0300 This is a multi-part message in MIME format. --------------3DA38E2F8D7F3FD3129A1B05 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, >I actually agree with you (except I would have used a new method rather >than INFO). That is of course an option. I just thought that INFO, with no message body, would work fine, since the only thing the UAS has to do is to send a response (no communication with the user/application is required). >I just don't think it's very likely, given that the arguments are largely unchanged, that people will be >willing to modify the session timer mechanism at this late stage. There are different ways of doing it. IF you would choose to change the current specification, basically the only thing you would have to do is to change the re-INVITEs to INFOs (or whatever method you choose to use). The negotiation mechanism of the timer value, the extension headers etc. would remain. Of course, a UA who wishes to send INFOs would also have to support the method. Another way would be to define a new mechanism - "session ping", "session-timer light", or whatever you want to call it :) >Anyway, maybe you should post the archive pointer and then we can at least have a fully informed discussion. The link to the archieve is... http://www.bell-labs.com/mailing-lists/sip/20000/subject.html ...and the subject is 'Session timer comments'. Regards, Christer Holmberg Ericsson Finland > > Anders > > Christer Holmberg wrote: > > > > Hi, > > > > I found the archive, and the thread. The discussion was very much about > > the fact that by using re-INVITEs the session can be "automatically" > > re-established if the UAS has booted, and I guess this works fine as > > long as we don't get any 18x responses, which may include ringtones, > > messages and who knows what (we may even receive a 3xx Redirect message) > > And, if the UAC uses INFO, and receive 481 Call leg/Transaction Does Not > > Exist (e.g. if the UAS has booted), it can choose to send a re-INVITE, > > and be prepared to receive 18x messages, to reestablish the session. > > > > Also, I don't think the UAS will crash that often, compared to what we > > would save by not having to send ACKs etc. > > > > Regards, > > > > Christer Holmberg > > Ericsson Finland > > > > Anders Kristensen wrote: > > > > > > We had this whole discussion about a year ago. Unfortunately the > > > archives doesn't seem to go that far back, but it seems pointless to > > > repeat that discussion. Is there an archive somewhere for the old list? > > > > > > Anders > > > > > > Christer Holmberg wrote: > > > > > > > > Hi, > > > > > > > > Thanks for the comments! > > > > > > > > >If the UA crashed and rebooted and forgot about the old session, it would > > > > >respond with either a 481 call leg doesn't exist (you would know the call > > > > >is down), or a 501 (you know the UA is up, but is the call?) > > > > > > > > > >thanks, > > > > >-rohan > > > > > > > > I think that would be good, because then we could inform the user that > > > > the call doesn't exist anymore. > > > > > > > > Let's assume the UAS crashes, reboots and the UAC sends the > > > > session-timer re-INVITE. If the UAS has forgotten about the old session > > > > it would consider the re-INVITE as a new INVITE, for a new session. It > > > > would try to establish a new session - and we could suddenly start > > > > receiving provisional 18x responses (with or without SDP bodies), and/or > > > > a 200 response with a SDP body, to the session-timer re-INVITE. What do > > > > we do then? > > > > > > > > Regards, > > > > > > > > Christer Holmberg > > > > Ericsson Finland > > > > > > > > > > > > > > At 10:55 AM 10/16/00 , Christer Holmberg wrote: > > > > > > > > > > > >Hi, > > > > > > > > > > > >First, this mail is NOT a proposal for a change. I would just like to > > > > > >hear some opinions - or maybe it has already been discussed on the list? > > > > > > > > > > > >The INFO Method RFC says that for INFO requests without a message body, > > > > > >a server supporting INFO MUST respond with response code 200. So, my > > > > > >question is: why couldn't INFO be used for the session-timer > > > > > >functionality? Is the ACK the (re-)INVITE provides really necessary for > > > > > >the purpose? > > > > > > > > > > > >And, like the session-timer is defined now, the other party would not > > > > > >even have to support the INFO method, because a 501 Not Implemented > > > > > >would be sent, and the sender of the INFO would know the session is > > > > > >"alive". > > > > > > > > > > > >Just some thoughts... Please let me know if there is something I haven't > > > > > >taken into consideration. > > > > > > > > > > > >Regards, > > > > > > > > > > > >Christer Holmberg > > > > > >Ericsson Finland > > > > > > > > > > > > -- > > > Anders Kristensen --------------3DA38E2F8D7F3FD3129A1B05 Content-Type: text/x-vcard; charset=us-ascii; name="christer.holmberg.vcf" Content-Description: Card for Christer Holmberg Content-Disposition: attachment; filename="christer.holmberg.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Holmberg;Christer tel;cell:+358-40-5604412 tel;work:+358-9-2992943 x-mozilla-html:FALSE org:Ericsson;Advanced Signalling Research Laboratory adr:;;;;;; version:2.1 email;internet:christer.holmberg@lmf.ericsson.se title:System Designer fn:Christer Holmberg end:vcard --------------3DA38E2F8D7F3FD3129A1B05-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 17 09:52:26 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA11694 for ; Tue, 17 Oct 2000 09:52:26 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id CB5D544360; Tue, 17 Oct 2000 08:51:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from pentagon.cisco.com (pentagon.cisco.com [161.44.199.141]) by lists.bell-labs.com (Postfix) with ESMTP id B892A44336 for ; Tue, 17 Oct 2000 08:50:02 -0400 (EDT) Received: from cia.cisco.com (mirapoint@cia.cisco.com [161.44.199.157]) by pentagon.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA24433; Tue, 17 Oct 2000 09:49:44 -0400 (EDT) Received: from mhammer-nt.cisco.com (va-dhcp198-137.cisco.com [161.44.198.137]) by cia.cisco.com (Mirapoint) with ESMTP id ACP10953; Tue, 17 Oct 2000 09:49:42 -0400 (EDT) Message-Id: <4.3.2.7.2.20001017094755.00b438f0@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Christer Holmberg , sip@lists.bell-labs.com From: hammer michael Subject: Re: [SIP] Session-timer with INFO Cc: Brian Stucker In-Reply-To: <39EB7368.794876C8@lmf.ericsson.se> References: <36FA02BD7083D411BC9E0000F8073E43E70643@crchy271.us.nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 17 Oct 2000 09:54:45 -0700 Is this the Internet version of "let them eat cake?" Signal-spam is not more palatable than the normal variety. Is there a response code that can indicate the sentiment: I don't support this method, don't try it again? It might also be good to make sure that such undesirable sub-methods are indicated as "Unsupported." If that sub-method is well-defined, then that header parameter should be applicable. Mike At 12:30 AM 10/17/2000 +0300, Christer Holmberg wrote: >Hi, > > >Good points. Here's one more problem you may want to consider. > >Whenever you invoke a ping-style method of deciding if a session is > >alive, you open up problems due to network jitter and bandwidth. For > >instance, you could easily have a packet delayed at an endpoint due to > >a large file transfer starting up, or some other bandwidth consuming > >event. In this case, your ping could be delayed long enough to cause > >the session to drop for no good reason. > >Well, this could be the case no matter which method (INVITE, INFO, or >whatever...) you use in the heartbeat request... > > >You're also creating the potential for artificial problems in wireless > >networks by using a ping-method to keep a session alive. During a > >handover there may be a period where packets are in effect "muted" for > >a short period of time. The mute period may not, by itself be long > >enough to trigger a ping-timer to pop and kill the session, but if the > >ping was near the edge of the time envelope to be accepted as > >"on-time" anyhow, once again, your session could very easily drop when > >the media was operating just fine. > >Also, keep in mind, the longer you set the ping timer for, the more > >network resources you will likely waste over time because of the > >additional latentcy in discovering a "dead" session. > >Just to clarify, this "ping-method" IS already defined for SIP >(draft-ietf-sip-session-timer-02.txt), and re-INVITEs are used to ping. >My idea was about replacing the re-INVITE with INFO, which mean we would >actually save resources since we don't have to send ACK every time. > > >This method has one other nasty side-effect. You'd be wasting network > >resources on an event that will likely not occur very often. After > >all, every INFO exchange except the very last one that invalidates the > >session could have very well not been sent without any negative impact > >on the session (otherwise they would have been the last one). So > >you've got proxies and UAs, and other transport resources being tied > >up processing packets that by and large are providing no value, and > >they're chewing up bandwidth budget that other services could be using > >instead. > >That is an interesting point, and it is valid also for a number of other >SIP extensions where extra messages are sent (e.g. PRACK), but it is >another discussion. > > >Please keep in mind that not everyone is looking at implementing SIP > >on a 10Mbit+ hardwired LAN (or has to scale up to tremendous numbers > >of users), pinging and triangle-routing can be the death-knell of > >these sorts of networks. > >Who said "bandwidth is free"? :) > > >Because of all of this, I think it would be a very bad idea for a UA > >to send an INFO to a client who repeatedly tells him "I don't > >understand INFO" to see if he's alive. > >The number of messages on the network will be the same no matter if we >send an INVITE which he understands, or an INFO he may not understand. >Also, when we receive the response for the INVITE we also have to send >back an ACK, which is not the case when INFO is used. > > >He may not understand INFO because that particular network doesn't > deem >the bandwidth required for this mechanism as being best used for > that >purpose. If someone tells you "don't send me this method" then > don't send >it to them. > >Again, this has nothing to do with the bandwith issue. Even if I send >re-INVITEs, which the other party understands, he can not tell me not to >send any more re-INVITEs. > > >Otherwise your implementation may be viewed as favorably as the record > >clubs that used to require you to send them a card every month telling > >them not to send you anything by some groups. > >Well, it's not up to me to decide when and if an operator will use the >session-timer, as defined in the draft, or not - I am just trying to >make it as good (and less resource consuming) if he choses to. > >Regards, > >Christer Holmberg >Ericsson Finland > > > > > > Brian Stucker > > Nortel Networks > > > > -----Original Message----- > > From: Culpepper, Bert [mailto:bert.culpepper@intervoice-brite.com] > > Sent: Monday, October 16, 2000 3:38 PM > > To: Christer Holmberg; sip@lists.bell-labs.com > > Cc: Rohan Mahy > > Subject: RE: [SIP] Session-timer with INFO > > > > Some things to think about. > > > > I believe INFO is _not_ to be used to modify the state of a session. > > I > > suppose a debate is possible about session-timer affecting session > > state - present vs. future and if INFO is only restricted to one. But > > it's > > probably best to leave it alone. Also, the INV-200-ACK exchange > > allows multiple parties to agree on the duration of the session. If > > the > > recipient of the INFO request wants a smaller value (because its > > heartbeat interval is shorter) for the session timer it would have to > > send its own INFO request (unless you plan to keep the proposed > > Session-expires header and its use in a 200 OK). Now four > > messages are needed. In addition, there may be proxy issues when > > using INFO. There's other behavior described in the draft too. > > > > > -----Original Message----- > > > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > > > Sent: Monday, October 16, 2000 3:42 PM > > > To: sip@lists.bell-labs.com > > > Cc: Rohan Mahy > > > Subject: Re: [SIP] Session-timer with INFO > > > > > > > > > > > > Hi, > > > > > > Thanks for the comments! > > > > > > >If the UA crashed and rebooted and forgot about the old session, it > > > > > would > > > >respond with either a 481 call leg doesn't exist (you would know > > the > > > call > > > >is down), or a 501 (you know the UA is up, but is the call?) > > > > > > > >thanks, > > > >-rohan > > > > > > I think that would be good, because then we could inform the user > > that > > > the call doesn't exist anymore. > > > > > > Let's assume the UAS crashes, reboots and the UAC sends the > > > session-timer re-INVITE. If the UAS has forgotten about the old > > > session > > > it would consider the re-INVITE as a new INVITE, for a new session. > > It > > > would try to establish a new session - and we could suddenly start > > > receiving provisional 18x responses (with or without SDP bodies), > > > and/or > > > a 200 response with a SDP body, to the session-timer re-INVITE. What > > > > > do > > > we do then? > > > > Well, you could ignore the provisional responses (you know the other > > end > > is confused) and let the session get re-established or decide to > > terminate > > the session with CANCEL/BYE. > > > > Regards, > > Bert > > > > > > > > Regards, > > > > > > Christer Holmberg > > > Ericsson Finland > > > > > > > > > > > > > > > > > > > > > > > > > > > > > At 10:55 AM 10/16/00 , Christer Holmberg wrote: > > > > > > > > > >Hi, > > > > > > > > > >First, this mail is NOT a proposal for a change. I would just > > like > > > to > > > > >hear some opinions - or maybe it has already been discussed on > > the > > > list? > > > > > > > > > >The INFO Method RFC says that for INFO requests without a message > > > > > body, > > > > >a server supporting INFO MUST respond with response code 200. So, > > > > > my > > > > >question is: why couldn't INFO be used for the session-timer > > > > >functionality? Is the ACK the (re-)INVITE provides really > > necessary > > > for > > > > >the purpose? > > > > > > > > > >And, like the session-timer is defined now, the other party would > > > > > not > > > > >even have to support the INFO method, because a 501 Not > > Implemented > > > > >would be sent, and the sender of the INFO would know the session > > is > > > > >"alive". > > > > > > > > > >Just some thoughts... Please let me know if there is something I > > > haven't > > > > >taken into consideration. > > > > > > > > > >Regards, > > > > > > > > > >Christer Holmberg > > > > >Ericsson Finland > > > > > > > > > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 17 10:01:13 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12126 for ; Tue, 17 Oct 2000 10:01:12 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 38D8B44360; Tue, 17 Oct 2000 09:01:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lists.bell-labs.com (Postfix) with ESMTP id 9FF7244336 for ; Tue, 17 Oct 2000 09:00:23 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id e9HE0It10494; Tue, 17 Oct 2000 16:00:18 +0200 (MEST) 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 RAA13827; Tue, 17 Oct 2000 17:00:17 +0300 (EET DST) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.29]) by greymse1.lmf.ericsson.se (8.9.3 (PHNE_18979)/8.8.6) with ESMTP id RAA23412; Tue, 17 Oct 2000 17:00:15 +0300 (EETDST) Message-ID: <39EC5B6D.57668369@lmf.ericsson.se> From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Cc: hammer michael Subject: Re: [SIP] Session-timer with INFO References: <36FA02BD7083D411BC9E0000F8073E43E70643@crchy271.us.nortel.com> <4.3.2.7.2.20001017094755.00b438f0@cia.cisco.com> Content-Type: multipart/mixed; boundary="------------1344596780628EB1AAE0F140" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 17 Oct 2000 17:00:13 +0300 This is a multi-part message in MIME format. --------------1344596780628EB1AAE0F140 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, If I send you an INFO, or any other method that you don't support, you can for example send a 501 Not Implemented response, and include an Allow header with the methods you support. Of course, you can't stop the UAC of sending the method again, if he chooses to... You can not, however, tell an UAC not to send you re-INVITEs, because then you would also forbid the UAC to send you INVITEs - and I don't think you want to do that. Also, the specification says that a UA MUST be able to receive INVITEs (which included re-INVITEs), so... Regards, Christer Holmberg Ericsson Finland hammer michael wrote: > > Is this the Internet version of "let them eat cake?" Signal-spam is not > more palatable than the normal variety. > > Is there a response code that can indicate the sentiment: I don't support > this method, don't try it again? It might also be good to make sure that > such undesirable sub-methods are indicated as "Unsupported." If that > sub-method is well-defined, then that header parameter should be applicable. > > Mike > > At 12:30 AM 10/17/2000 +0300, Christer Holmberg wrote: > > >Hi, > > > > >Good points. Here's one more problem you may want to consider. > > >Whenever you invoke a ping-style method of deciding if a session is > > >alive, you open up problems due to network jitter and bandwidth. For > > >instance, you could easily have a packet delayed at an endpoint due to > > >a large file transfer starting up, or some other bandwidth consuming > > >event. In this case, your ping could be delayed long enough to cause > > >the session to drop for no good reason. > > > >Well, this could be the case no matter which method (INVITE, INFO, or > >whatever...) you use in the heartbeat request... > > > > >You're also creating the potential for artificial problems in wireless > > >networks by using a ping-method to keep a session alive. During a > > >handover there may be a period where packets are in effect "muted" for > > >a short period of time. The mute period may not, by itself be long > > >enough to trigger a ping-timer to pop and kill the session, but if the > > >ping was near the edge of the time envelope to be accepted as > > >"on-time" anyhow, once again, your session could very easily drop when > > >the media was operating just fine. > > >Also, keep in mind, the longer you set the ping timer for, the more > > >network resources you will likely waste over time because of the > > >additional latentcy in discovering a "dead" session. > > > >Just to clarify, this "ping-method" IS already defined for SIP > >(draft-ietf-sip-session-timer-02.txt), and re-INVITEs are used to ping. > >My idea was about replacing the re-INVITE with INFO, which mean we would > >actually save resources since we don't have to send ACK every time. > > > > >This method has one other nasty side-effect. You'd be wasting network > > >resources on an event that will likely not occur very often. After > > >all, every INFO exchange except the very last one that invalidates the > > >session could have very well not been sent without any negative impact > > >on the session (otherwise they would have been the last one). So > > >you've got proxies and UAs, and other transport resources being tied > > >up processing packets that by and large are providing no value, and > > >they're chewing up bandwidth budget that other services could be using > > >instead. > > > >That is an interesting point, and it is valid also for a number of other > >SIP extensions where extra messages are sent (e.g. PRACK), but it is > >another discussion. > > > > >Please keep in mind that not everyone is looking at implementing SIP > > >on a 10Mbit+ hardwired LAN (or has to scale up to tremendous numbers > > >of users), pinging and triangle-routing can be the death-knell of > > >these sorts of networks. > > > >Who said "bandwidth is free"? :) > > > > >Because of all of this, I think it would be a very bad idea for a UA > > >to send an INFO to a client who repeatedly tells him "I don't > > >understand INFO" to see if he's alive. > > > >The number of messages on the network will be the same no matter if we > >send an INVITE which he understands, or an INFO he may not understand. > >Also, when we receive the response for the INVITE we also have to send > >back an ACK, which is not the case when INFO is used. > > > > >He may not understand INFO because that particular network doesn't > > deem >the bandwidth required for this mechanism as being best used for > > that >purpose. If someone tells you "don't send me this method" then > > don't send >it to them. > > > >Again, this has nothing to do with the bandwith issue. Even if I send > >re-INVITEs, which the other party understands, he can not tell me not to > >send any more re-INVITEs. > > > > >Otherwise your implementation may be viewed as favorably as the record > > >clubs that used to require you to send them a card every month telling > > >them not to send you anything by some groups. > > > >Well, it's not up to me to decide when and if an operator will use the > >session-timer, as defined in the draft, or not - I am just trying to > >make it as good (and less resource consuming) if he choses to. > > > >Regards, > > > >Christer Holmberg > >Ericsson Finland > > > > > > > > > > Brian Stucker > > > Nortel Networks > > > > > > -----Original Message----- > > > From: Culpepper, Bert [mailto:bert.culpepper@intervoice-brite.com] > > > Sent: Monday, October 16, 2000 3:38 PM > > > To: Christer Holmberg; sip@lists.bell-labs.com > > > Cc: Rohan Mahy > > > Subject: RE: [SIP] Session-timer with INFO > > > > > > Some things to think about. > > > > > > I believe INFO is _not_ to be used to modify the state of a session. > > > I > > > suppose a debate is possible about session-timer affecting session > > > state - present vs. future and if INFO is only restricted to one. But > > > it's > > > probably best to leave it alone. Also, the INV-200-ACK exchange > > > allows multiple parties to agree on the duration of the session. If > > > the > > > recipient of the INFO request wants a smaller value (because its > > > heartbeat interval is shorter) for the session timer it would have to > > > send its own INFO request (unless you plan to keep the proposed > > > Session-expires header and its use in a 200 OK). Now four > > > messages are needed. In addition, there may be proxy issues when > > > using INFO. There's other behavior described in the draft too. > > > > > > > -----Original Message----- > > > > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > > > > Sent: Monday, October 16, 2000 3:42 PM > > > > To: sip@lists.bell-labs.com > > > > Cc: Rohan Mahy > > > > Subject: Re: [SIP] Session-timer with INFO > > > > > > > > > > > > > > > > Hi, > > > > > > > > Thanks for the comments! > > > > > > > > >If the UA crashed and rebooted and forgot about the old session, it > > > > > > > would > > > > >respond with either a 481 call leg doesn't exist (you would know > > > the > > > > call > > > > >is down), or a 501 (you know the UA is up, but is the call?) > > > > > > > > > >thanks, > > > > >-rohan > > > > > > > > I think that would be good, because then we could inform the user > > > that > > > > the call doesn't exist anymore. > > > > > > > > Let's assume the UAS crashes, reboots and the UAC sends the > > > > session-timer re-INVITE. If the UAS has forgotten about the old > > > > session > > > > it would consider the re-INVITE as a new INVITE, for a new session. > > > It > > > > would try to establish a new session - and we could suddenly start > > > > receiving provisional 18x responses (with or without SDP bodies), > > > > and/or > > > > a 200 response with a SDP body, to the session-timer re-INVITE. What > > > > > > > do > > > > we do then? > > > > > > Well, you could ignore the provisional responses (you know the other > > > end > > > is confused) and let the session get re-established or decide to > > > terminate > > > the session with CANCEL/BYE. > > > > > > Regards, > > > Bert > > > > > > > > > > > Regards, > > > > > > > > Christer Holmberg > > > > Ericsson Finland > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > At 10:55 AM 10/16/00 , Christer Holmberg wrote: > > > > > > > > > > > >Hi, > > > > > > > > > > > >First, this mail is NOT a proposal for a change. I would just > > > like > > > > to > > > > > >hear some opinions - or maybe it has already been discussed on > > > the > > > > list? > > > > > > > > > > > >The INFO Method RFC says that for INFO requests without a message > > > > > > > body, > > > > > >a server supporting INFO MUST respond with response code 200. So, > > > > > > > my > > > > > >question is: why couldn't INFO be used for the session-timer > > > > > >functionality? Is the ACK the (re-)INVITE provides really > > > necessary > > > > for > > > > > >the purpose? > > > > > > > > > > > >And, like the session-timer is defined now, the other party would > > > > > > > not > > > > > >even have to support the INFO method, because a 501 Not > > > Implemented > > > > > >would be sent, and the sender of the INFO would know the session > > > is > > > > > >"alive". > > > > > > > > > > > >Just some thoughts... Please let me know if there is something I > > > > haven't > > > > > >taken into consideration. > > > > > > > > > > > >Regards, > > > > > > > > > > > >Christer Holmberg > > > > > >Ericsson Finland > > > > > > > > > > > > > > > > _______________________________________________ > > > SIP mailing list > > > SIP@lists.bell-labs.com > > > http://lists.bell-labs.com/mailman/listinfo/sip --------------1344596780628EB1AAE0F140 Content-Type: text/x-vcard; charset=us-ascii; name="christer.holmberg.vcf" Content-Description: Card for Christer Holmberg Content-Disposition: attachment; filename="christer.holmberg.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Holmberg;Christer tel;cell:+358-40-5604412 tel;work:+358-9-2992943 x-mozilla-html:FALSE org:Ericsson;Advanced Signalling Research Laboratory adr:;;;;;; version:2.1 email;internet:christer.holmberg@lmf.ericsson.se title:System Designer fn:Christer Holmberg end:vcard --------------1344596780628EB1AAE0F140-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 17 10:05:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12246 for ; Tue, 17 Oct 2000 10:05:02 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8603B4436E; Tue, 17 Oct 2000 09:03:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lists.bell-labs.com (Postfix) with ESMTP id 18EC24436E for ; Tue, 17 Oct 2000 09:02:40 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id e9HE2YZ00106 for ; Tue, 17 Oct 2000 16:02:35 +0200 (MEST) 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 RAA14005; Tue, 17 Oct 2000 17:02:34 +0300 (EET DST) Received: from localhost (root@localhost) by greymse1.lmf.ericsson.se (8.9.3 (PHNE_18979)/8.8.6) with ESMTP id RAA24034; Tue, 17 Oct 2000 17:02:33 +0300 (EETDST) From: Gonzalo.Camarillo@lmf.ericsson.se X-OpenMail-Hops: 1 Message-Id: In-Reply-To: Subject: [SIP] CANCEL and stateless proxies MIME-Version: 1.0 To: Gonzalo.Camarillo@lmf.ericsson.se Cc: sip@lists.bell-labs.com Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline ;Creation-Date="Tue, 17 Oct 2000 16:46:38 +0300" ;Modification-Date="Tue, 17 Oct 2000 17:02:31 +0300" Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 17 Oct 2000 17:02:32 +0300 Content-Transfer-Encoding: 7bit Hi again, I will give a particular example of the general question I asked in my previous mail. We have a sales department with two persons working: Bob and Alice. They have a staless SIP proxy server. Bob works from 8:00 to 12:00 and Alice from 12:00 to 16:00. Therefore, all the incoming INVITEs with Request-URI sales@company.com are routed to Bob@ws1.company.com from 8 to 12 and to Alice@ws2.company.com from 12 to 16. An INVITE arrives to this stateless SIP server right before 12:00. It is routed to Bob. Then, a CANCEL arrives, but it is routed to Alice. (If instead of a CANCEL a BYE would have sent we have the same problem). Now we have Bob's UAS ringing all the day because we cannot stop it. I hope this example clarifies my previous question (see previous mail), Thanks, Gonzalo > Hi, > > A CANCEL request for a previous INVITE follows the same path as > the INVITE. This > way the CANCEL request arrives to the same set of hosts as the > INVITE. > > Stateful proxies storing transaction state perform this routing > fine. > > What about stateless proxies? The CANCEL might be routed in a > different way than > the previous INVITE. > > This issue is somehow related to the "BYE after a INVITE" > issue. It is > preferable to send a CANCEL rather than a BYE after a INVITE > because stateful > proxies storing transaction state will route the CANCEL > properly. The BYE might > be routed in a wrong way. > > My question is: the same way proxies storing just transaction > state (not call > state) might route a BYE to a different host than the previous > INVITE, a > stateless proxy might route a CANCEL in a wrong way. What am I > missing? > > Thanks, > > Gonzalo > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 17 10:11:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12383 for ; Tue, 17 Oct 2000 10:11:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3B4A744374; Tue, 17 Oct 2000 09:11:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from wiproecmx2.wipro.com (wiproecmx2.wipro.com [164.164.31.6]) by lists.bell-labs.com (Postfix) with ESMTP id 65BB34436E for ; Tue, 17 Oct 2000 09:10:14 -0400 (EDT) Received: from ecvwall1.wipro.com (ecvwall1.wipro.com [192.168.181.23]) by wiproecmx2.wipro.com (8.9.3/8.9.3) with SMTP id TAA23428 for ; Tue, 17 Oct 2000 19:49:18 GMT Received: from wslexch.wipsys.soft.net ([192.219.223.59]) by kmglmail.mail.wipro.com (Netscape Messaging Server 3.6) with ESMTP id AAA69F8; Tue, 17 Oct 2000 19:39:55 +0530 Received: by wslexch.mail.wipro.com with Internet Mail Service (5.5.2650.21) id <4YBM5BZJ>; Tue, 17 Oct 2000 19:41:31 +0530 Message-ID: <53BA505BEC72D21194400000E216A244037A251C@wslexch.mail.wipro.com> From: Subramania Sivaram To: Robert Sparks , sip@lists.bell-labs.com Subject: RE: [SIP] draft-ietf-sip-cc-transfer-01 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 17 Oct 2000 19:41:30 +0530 I happened to read this draft today. I have a fundamental question on why the REFER is needed to achieve transfer. To mimic today's behaviour in the PSTN, won't the following be sufficient Transferor puts transferee on hold via a RE-INVITE. Transferor does an INVITE to transfer target. Transferor does a re-INVITE to both transferee & transfer target to give each other's IP address (much like 3rd party call control scenario). Regards, Sivaram. > -----Original Message----- > From: Robert Sparks [SMTP:rsparks@dynamicsoft.com] > Sent: Tuesday, September 19, 2000 12:08 AM > To: sip@lists.bell-labs.com > Subject: [SIP] draft-ietf-sip-cc-transfer-01 > > > The attached revision to sip-cc-transfer has been submitted to the > internet-drafts repository. > > This revision addresses the following: > > . Separated definition of the REFER method and headers from the definition > of its use to achieve transfer. > . Replaced the syntax of the Referred-By header to align with > sip-ietf-sip-guidelines. > . Added short forms of Refer-To and Referred-By as recommended by > sip-ietf-sip-guidelines. > . Allows REFERs outside the scope of an existing call-leg. > > I've tried to reflect most of the feedback received since the Pittsburg > meeting. Please > review - if I've missed something, let me know. > > RjS << File: draft-ietf-sip-cc-transfer-01.txt >> _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 17 10:25:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12710 for ; Tue, 17 Oct 2000 10:25:05 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 213684436A; Tue, 17 Oct 2000 09:25:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lists.bell-labs.com (Postfix) with ESMTP id 105A444338 for ; Tue, 17 Oct 2000 09:24:59 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id e9HEOjt10656; Tue, 17 Oct 2000 16:24:46 +0200 (MEST) 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 RAA15995; Tue, 17 Oct 2000 17:24:42 +0300 (EET DST) Received: from localhost (root@localhost) by greymse1.lmf.ericsson.se (8.9.3 (PHNE_18979)/8.8.6) with ESMTP id RAA01236; Tue, 17 Oct 2000 17:24:40 +0300 (EETDST) From: Gonzalo.Camarillo@lmf.ericsson.se X-OpenMail-Hops: 1 Message-Id: In-Reply-To: Subject: RE: [SIP] CANCEL/200 OK/BYE MIME-Version: 1.0 To: Cliff.Harris@nokia.com Cc: sip@lists.bell-labs.com, sip-implementors@cs.columbia.edu, vkg@lucent.com, jdrosen@dynamicsoft.com Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline ;Creation-Date="Tue, 17 Oct 2000 17:19:54 +0300" ;Modification-Date="Tue, 17 Oct 2000 17:24:38 +0300" Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 17 Oct 2000 17:24:38 +0300 Content-Transfer-Encoding: 7bit > > -----Original Message----- > > From: EXT Vijay K. Gurbani [mailto:vkg@lucent.com] > [ . . . ] > > I think the spec should state that a UAC MUST send a BYE iff after > > having sent a CANCEL (for an in-progress INVITE), it got a 200 class > > response to the INVITE (which means that the 200 OK and > > CANCEL "crossed > > each other on the wire"). > > > > Thanks, > > > > - vijay > > -- > > Vijay K. Gurbani vkg@lucent.com vkg@research.bell-labs.com > > vkg@acm.org > > Internet Software Group/Intelligent Network and Messaging Systems > > Lucent Technologies/Bell Labs Innovations, 263 Shuman Blvd, Rm 1A-413 > > Naperville, Illinois 60566 Voice: +1 630 224 0216 Fax: +1 > > 630 713 0184 > > > > The note in section 4.2.5 of the RFC-bis draft makes it fairly clear that > BYE may be used instead of CANCEL. > > One very good reason for using BYE instead of CANCEL is that BYE may have an > attachment and CANCEL may not. In the SIP-T case, if the UAC wants to > include an attached PSTN message when the caller hangs up before the far end > has answered, BYE has to be used. Well, this is not that simple. There are still open issues here that we are currently resolving. The new mapping draft will contain the solutions chosen. > > I guess there are issues with tags and routes and all that. I don't know if > the spec addresses this, but in my naive view it would make sense if a proxy > that received a BYE without a tag sent it to all possible destinations, to > ensure that the UAS that received the INVITE will also get the BYE. The problem is that a stateful proxy (transaction stateful) does not know where the INVITE went. INVITE and BYE are two unrelated transactions. Stateful proxies will route correctly the CANCEL though, because CANCELs can be related to INVITEs examining the Cseq. Regards, Gonzalo > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 17 10:30:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12830 for ; Tue, 17 Oct 2000 10:30:04 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E12E04437F; Tue, 17 Oct 2000 09:30:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from pentagon.cisco.com (pentagon.cisco.com [161.44.199.141]) by lists.bell-labs.com (Postfix) with ESMTP id 0C42F44338 for ; Tue, 17 Oct 2000 09:29:13 -0400 (EDT) Received: from cia.cisco.com (mirapoint@cia.cisco.com [161.44.199.157]) by pentagon.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA25255; Tue, 17 Oct 2000 10:29:08 -0400 (EDT) Received: from mhammer-nt.cisco.com (va-dhcp198-137.cisco.com [161.44.198.137]) by cia.cisco.com (Mirapoint) with ESMTP id ACP11515; Tue, 17 Oct 2000 10:29:08 -0400 (EDT) Message-Id: <4.3.2.7.2.20001017103200.00b46730@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Christer Holmberg , sip@lists.bell-labs.com From: hammer michael Subject: Re: [SIP] Session-timer with INFO In-Reply-To: <39EC5B6D.57668369@lmf.ericsson.se> References: <36FA02BD7083D411BC9E0000F8073E43E70643@crchy271.us.nortel.com> <4.3.2.7.2.20001017094755.00b438f0@cia.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 17 Oct 2000 10:34:10 -0700 Thus you are in support of not trying to implicitly use a method to do what a subordinate capability should be explicitly defined to do? Mike At 05:00 PM 10/17/2000 +0300, Christer Holmberg wrote: >Hi, > >If I send you an INFO, or any other method that you don't support, you >can for example send a 501 Not Implemented response, and include an >Allow header with the methods you support. Of course, you can't stop the >UAC of sending the method again, if he chooses to... > >You can not, however, tell an UAC not to send you re-INVITEs, because >then you would also forbid the UAC to send you INVITEs - and I don't >think you want to do that. Also, the specification says that a UA MUST >be able to receive INVITEs (which included re-INVITEs), so... > >Regards, > >Christer Holmberg >Ericsson Finland > > >hammer michael wrote: > > > > Is this the Internet version of "let them eat cake?" Signal-spam is not > > more palatable than the normal variety. > > > > Is there a response code that can indicate the sentiment: I don't support > > this method, don't try it again? It might also be good to make sure that > > such undesirable sub-methods are indicated as "Unsupported." If that > > sub-method is well-defined, then that header parameter should be > applicable. > > > > Mike > > > > At 12:30 AM 10/17/2000 +0300, Christer Holmberg wrote: > > > > >Hi, > > > > > > >Good points. Here's one more problem you may want to consider. > > > >Whenever you invoke a ping-style method of deciding if a session is > > > >alive, you open up problems due to network jitter and bandwidth. For > > > >instance, you could easily have a packet delayed at an endpoint due to > > > >a large file transfer starting up, or some other bandwidth consuming > > > >event. In this case, your ping could be delayed long enough to cause > > > >the session to drop for no good reason. > > > > > >Well, this could be the case no matter which method (INVITE, INFO, or > > >whatever...) you use in the heartbeat request... > > > > > > >You're also creating the potential for artificial problems in wireless > > > >networks by using a ping-method to keep a session alive. During a > > > >handover there may be a period where packets are in effect "muted" for > > > >a short period of time. The mute period may not, by itself be long > > > >enough to trigger a ping-timer to pop and kill the session, but if the > > > >ping was near the edge of the time envelope to be accepted as > > > >"on-time" anyhow, once again, your session could very easily drop when > > > >the media was operating just fine. > > > >Also, keep in mind, the longer you set the ping timer for, the more > > > >network resources you will likely waste over time because of the > > > >additional latentcy in discovering a "dead" session. > > > > > >Just to clarify, this "ping-method" IS already defined for SIP > > >(draft-ietf-sip-session-timer-02.txt), and re-INVITEs are used to ping. > > >My idea was about replacing the re-INVITE with INFO, which mean we would > > >actually save resources since we don't have to send ACK every time. > > > > > > >This method has one other nasty side-effect. You'd be wasting network > > > >resources on an event that will likely not occur very often. After > > > >all, every INFO exchange except the very last one that invalidates the > > > >session could have very well not been sent without any negative impact > > > >on the session (otherwise they would have been the last one). So > > > >you've got proxies and UAs, and other transport resources being tied > > > >up processing packets that by and large are providing no value, and > > > >they're chewing up bandwidth budget that other services could be using > > > >instead. > > > > > >That is an interesting point, and it is valid also for a number of other > > >SIP extensions where extra messages are sent (e.g. PRACK), but it is > > >another discussion. > > > > > > >Please keep in mind that not everyone is looking at implementing SIP > > > >on a 10Mbit+ hardwired LAN (or has to scale up to tremendous numbers > > > >of users), pinging and triangle-routing can be the death-knell of > > > >these sorts of networks. > > > > > >Who said "bandwidth is free"? :) > > > > > > >Because of all of this, I think it would be a very bad idea for a UA > > > >to send an INFO to a client who repeatedly tells him "I don't > > > >understand INFO" to see if he's alive. > > > > > >The number of messages on the network will be the same no matter if we > > >send an INVITE which he understands, or an INFO he may not understand. > > >Also, when we receive the response for the INVITE we also have to send > > >back an ACK, which is not the case when INFO is used. > > > > > > >He may not understand INFO because that particular network doesn't > > > deem >the bandwidth required for this mechanism as being best used for > > > that >purpose. If someone tells you "don't send me this method" then > > > don't send >it to them. > > > > > >Again, this has nothing to do with the bandwith issue. Even if I send > > >re-INVITEs, which the other party understands, he can not tell me not to > > >send any more re-INVITEs. > > > > > > >Otherwise your implementation may be viewed as favorably as the record > > > >clubs that used to require you to send them a card every month telling > > > >them not to send you anything by some groups. > > > > > >Well, it's not up to me to decide when and if an operator will use the > > >session-timer, as defined in the draft, or not - I am just trying to > > >make it as good (and less resource consuming) if he choses to. > > > > > >Regards, > > > > > >Christer Holmberg > > >Ericsson Finland > > > > > > > > > > > > > > Brian Stucker > > > > Nortel Networks > > > > > > > > -----Original Message----- > > > > From: Culpepper, Bert [mailto:bert.culpepper@intervoice-brite.com] > > > > Sent: Monday, October 16, 2000 3:38 PM > > > > To: Christer Holmberg; sip@lists.bell-labs.com > > > > Cc: Rohan Mahy > > > > Subject: RE: [SIP] Session-timer with INFO > > > > > > > > Some things to think about. > > > > > > > > I believe INFO is _not_ to be used to modify the state of a session. > > > > I > > > > suppose a debate is possible about session-timer affecting session > > > > state - present vs. future and if INFO is only restricted to one. But > > > > it's > > > > probably best to leave it alone. Also, the INV-200-ACK exchange > > > > allows multiple parties to agree on the duration of the session. If > > > > the > > > > recipient of the INFO request wants a smaller value (because its > > > > heartbeat interval is shorter) for the session timer it would have to > > > > send its own INFO request (unless you plan to keep the proposed > > > > Session-expires header and its use in a 200 OK). Now four > > > > messages are needed. In addition, there may be proxy issues when > > > > using INFO. There's other behavior described in the draft too. > > > > > > > > > -----Original Message----- > > > > > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > > > > > Sent: Monday, October 16, 2000 3:42 PM > > > > > To: sip@lists.bell-labs.com > > > > > Cc: Rohan Mahy > > > > > Subject: Re: [SIP] Session-timer with INFO > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > Thanks for the comments! > > > > > > > > > > >If the UA crashed and rebooted and forgot about the old session, it > > > > > > > > > would > > > > > >respond with either a 481 call leg doesn't exist (you would know > > > > the > > > > > call > > > > > >is down), or a 501 (you know the UA is up, but is the call?) > > > > > > > > > > > >thanks, > > > > > >-rohan > > > > > > > > > > I think that would be good, because then we could inform the user > > > > that > > > > > the call doesn't exist anymore. > > > > > > > > > > Let's assume the UAS crashes, reboots and the UAC sends the > > > > > session-timer re-INVITE. If the UAS has forgotten about the old > > > > > session > > > > > it would consider the re-INVITE as a new INVITE, for a new session. > > > > It > > > > > would try to establish a new session - and we could suddenly start > > > > > receiving provisional 18x responses (with or without SDP bodies), > > > > > and/or > > > > > a 200 response with a SDP body, to the session-timer re-INVITE. What > > > > > > > > > do > > > > > we do then? > > > > > > > > Well, you could ignore the provisional responses (you know the other > > > > end > > > > is confused) and let the session get re-established or decide to > > > > terminate > > > > the session with CANCEL/BYE. > > > > > > > > Regards, > > > > Bert > > > > > > > > > > > > > > Regards, > > > > > > > > > > Christer Holmberg > > > > > Ericsson Finland > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > At 10:55 AM 10/16/00 , Christer Holmberg wrote: > > > > > > > > > > > > > >Hi, > > > > > > > > > > > > > >First, this mail is NOT a proposal for a change. I would just > > > > like > > > > > to > > > > > > >hear some opinions - or maybe it has already been discussed on > > > > the > > > > > list? > > > > > > > > > > > > > >The INFO Method RFC says that for INFO requests without a message > > > > > > > > > body, > > > > > > >a server supporting INFO MUST respond with response code 200. So, > > > > > > > > > my > > > > > > >question is: why couldn't INFO be used for the session-timer > > > > > > >functionality? Is the ACK the (re-)INVITE provides really > > > > necessary > > > > > for > > > > > > >the purpose? > > > > > > > > > > > > > >And, like the session-timer is defined now, the other party would > > > > > > > > > not > > > > > > >even have to support the INFO method, because a 501 Not > > > > Implemented > > > > > > >would be sent, and the sender of the INFO would know the session > > > > is > > > > > > >"alive". > > > > > > > > > > > > > >Just some thoughts... Please let me know if there is something I > > > > > haven't > > > > > > >taken into consideration. > > > > > > > > > > > > > >Regards, > > > > > > > > > > > > > >Christer Holmberg > > > > > > >Ericsson Finland > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > SIP mailing list > > > > SIP@lists.bell-labs.com > > > > http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 17 10:37:09 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA13049 for ; Tue, 17 Oct 2000 10:37:09 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 02A294437F; Tue, 17 Oct 2000 09:36:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from rwcxch01.clarent.com (unknown [208.205.112.2]) by lists.bell-labs.com (Postfix) with ESMTP id 6C54644338 for ; Tue, 17 Oct 2000 09:35:40 -0400 (EDT) Received: by RWCXCH01 with Internet Mail Service (5.5.2650.21) id ; Tue, 17 Oct 2000 07:40:35 -0700 Received: from rwcjfmule01 (10.1.151.27 [10.1.151.27]) by rwcxch02.clarent.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 4V3FM33G; Tue, 17 Oct 2000 07:33:27 -0700 From: Jean-Francois Mule Reply-To: Jean-Francois Mule To: sip@lists.bell-labs.com, sip-implementors@cs.columbia.edu Subject: [SIP] SIP and T.38 fax calls - Internet Draft Message-ID: <00a401c03847$5d0e5df0$0100007f@rwcjfmule01> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00A5_01C0380C.B0AF85F0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 17 Oct 2000 07:34:31 -0700 This is a multi-part message in MIME format. ------=_NextPart_000_00A5_01C0380C.B0AF85F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit A new Internet-Draft has been submitted, dealing with real time fax calls and SIP: call flows and BCP. Comments and suggestions are very much appreciated. Regards, Jean-Francois Mule -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Tuesday, October 17, 2000 3:47 AM Subject: I-D ACTION:draft-mule-sip-t38callflows-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : SIP T.38 Call Flow Examples And Best Current Practice Author(s) : J. Mule Filename : draft-mule-sip-t38callflows-00.txt Pages : 19 Date : 16-Oct-00 This document gives examples of SIP call flows for T.38 Internet fax communications (SIP, the Session Initiation Protocol is defined in RFC2543 [2] and T.38 is an ITU-T Recommendation [3]). Elements in these call flows include SIP User Agents, SIP Proxy Servers, and Gateways to the PSTN (Public Switch Telephone Network). This document introduces best current practices for T.38 fax calls: a call starts with audio capabilities, and, upon fax tone detection, T.38 fax capabilities are negotiated. The T.38 fax call scenarios include the detection of T.38 fax transmission by the receiving side, or the emitting side, or both (in the latter case, a 'glare' effect may appear). The current version of this document only covers the case when the fax tone is detected by the receiving side (other cases were left for discussion and may be included in the future). Call flow diagrams and message details are shown. A list of IANA defined SDP attribute names for T.38 is summarized in section 5. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-mule-sip-t38callflows-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-mule-sip-t38callflows-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-mule-sip-t38callflows-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_000_00A5_01C0380C.B0AF85F0 Content-Type: message/rfc822 Content-Disposition: attachment Subject: Date: Tue, 17 Oct 2000 07:21:17 -0700 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00A1_01C0380C.B0ADFF50" X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 This is a multi-part message in MIME format. ------=_NextPart_000_00A1_01C0380C.B0ADFF50 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit ------=_NextPart_000_00A1_01C0380C.B0ADFF50 Content-Type: application/octet-stream; name="ATT37675.txt" Content-Disposition: attachment; filename="ATT37675.txt" Content-Transfer-Encoding: 7bit Content-type: message/external-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001016145559.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-mule-sip-t38callflows-00.txt ------=_NextPart_000_00A1_01C0380C.B0ADFF50 Content-Type: message/external-body; name="ATT00089.dat" Content-Disposition: attachment; filename="ATT00089.dat" Content-Transfer-Encoding: 7bit ------=_NextPart_000_00A1_01C0380C.B0ADFF50-- ------=_NextPart_000_00A5_01C0380C.B0AF85F0-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 17 10:58:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA13471 for ; Tue, 17 Oct 2000 10:58:03 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B8D774436A; Tue, 17 Oct 2000 09:58:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from felix.intertex.se (unknown [195.22.82.2]) by lists.bell-labs.com (Postfix) with ESMTP id A452E44338 for ; Tue, 17 Oct 2000 09:29:51 -0400 (EDT) From: Lars Berggren To: Christer Holmberg Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Session-timer with INFO In-Reply-To: <39EC2350.A27E8BEF@lmf.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 17 Oct 2000 16:29:58 +0200 (CEST) On Tue, 17 Oct 2000, Christer Holmberg wrote: > > Hi, > > > >>Hi, > >> > >>First, this mail is NOT a proposal for a change. I would just like to > >>hear some opinions - or maybe it has already been discussed on the list? > >> > >>The INFO Method RFC says that for INFO requests without a message body, > >>a server supporting INFO MUST respond with response code 200. So, my > >>question is: why couldn't INFO be used for the session-timer > >>functionality? Is the ACK the (re-)INVITE provides really necessary for > >>the purpose? > >> > >>And, like the session-timer is defined now, the other party would not > >>even have to support the INFO method, because a 501 Not Implemented > >>would be sent, and the sender of the INFO would know the session is > >>"alive". > >> > >>Just some thoughts... Please let me know if there is something I haven't > >>taken into consideration. > >> > > > >I think the re-INVITE mechanism is far more better because the >information about what session is refreshed is carried in the SDP of the > >re-INVITE. The INFO approach has the significant disadvantage that >proxies that use the session timer might have to store a *lot* of state > >information about each session. > > That is not true. The session is identified using the Call-ID. The call-id is the SIP-identifier of a session, yes. But, SIP initiates a multimedia session and if the proxy is doing stuff (like allocating some sort of network resources for a limited period of time) related to the multimedia session and is interested in knowing when that session ends it might add a session timer. Now, if all the information that set up the session gets repeated in the re-INVITE the proxy does not have to store call-id etc together with the multimedia session parameters to track which multimedia session the SIP-message refers to. Regards, /Lars > > In fact, another advantage of using INFO is that you don't have to send > a message body at all. Using re-INVITE, you must send a copy of the > original message, and the UAS must check if the SDP is a copy > (session-timer) or if it is a new SDP, when the session should be > modified. Again, we save resources. Comments? > > Regards, > > Christer Holmberg > Ericsson Finland > > > > > > > Regards /Lars > > > > > Regards, > > > > > > Christer Holmberg > > > Ericsson Finland > > > > Lars Berggren > > Intertex Data AB tel: +46-8-6282828 > > Sundbyberg, Sweden fax: +46-8-6286414 Lars Berggren Intertex Data AB tel: +46-8-6282828 Sundbyberg, Sweden fax: +46-8-6286414 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 17 11:00:13 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA13541 for ; Tue, 17 Oct 2000 11:00:12 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5839944389; Tue, 17 Oct 2000 09:59:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 4496C44336 for ; Tue, 17 Oct 2000 09:58:33 -0400 (EDT) Received: from CINQUECENTO ([63.110.3.156]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with SMTP id KAA15507; Tue, 17 Oct 2000 10:52:27 -0400 (EDT) From: "Robert Sparks" To: "Subramania Sivaram" , Subject: RE: [SIP] draft-ietf-sip-cc-transfer-01 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal In-Reply-To: <53BA505BEC72D21194400000E216A244037A251C@wslexch.mail.wipro.com> Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 17 Oct 2000 09:47:43 -0500 Content-Transfer-Encoding: 7bit What you describe gives the other two parties each other's addresses for media exchange, not signalling. The transferor would have to continue to play as a signalling "middle-man" for the duration of the call. RjS p.s. - note that one of the other parties has to support a delayed-sdp invite, i.e. negotiating the session in the 200 OK and ACK, for the setup you describe to do what you want. > -----Original Message----- > From: Subramania Sivaram [mailto:sivaram.subr@wipro.com] > Sent: Tuesday, October 17, 2000 9:12 AM > To: Robert Sparks; sip@lists.bell-labs.com > Subject: RE: [SIP] draft-ietf-sip-cc-transfer-01 > > > I happened to read this draft today. I have a fundamental question on why > the REFER is needed to > achieve transfer. To mimic today's behaviour in the PSTN, won't the > following be sufficient > > Transferor puts transferee on hold via a RE-INVITE. > Transferor does an INVITE to transfer target. > Transferor does a re-INVITE to both transferee & transfer target to give > each other's IP address (much like > 3rd party call control scenario). > > Regards, > Sivaram. > > > -----Original Message----- > > From: Robert Sparks [SMTP:rsparks@dynamicsoft.com] > > Sent: Tuesday, September 19, 2000 12:08 AM > > To: sip@lists.bell-labs.com > > Subject: [SIP] draft-ietf-sip-cc-transfer-01 > > > > > > The attached revision to sip-cc-transfer has been submitted to the > > internet-drafts repository. > > > > This revision addresses the following: > > > > . Separated definition of the REFER method and headers from the > definition > > of its use to achieve transfer. > > . Replaced the syntax of the Referred-By header to align with > > sip-ietf-sip-guidelines. > > . Added short forms of Refer-To and Referred-By as recommended by > > sip-ietf-sip-guidelines. > > . Allows REFERs outside the scope of an existing call-leg. > > > > I've tried to reflect most of the feedback received since the Pittsburg > > meeting. Please > > review - if I've missed something, let me know. > > > > RjS << File: draft-ietf-sip-cc-transfer-01.txt >> > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 17 11:25:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA14073 for ; Tue, 17 Oct 2000 11:25:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B1D9644340; Tue, 17 Oct 2000 10:25:04 -0400 (EDT) Delivered-To: sip@share.research.bell-labs.com Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by lists.bell-labs.com (Postfix) with SMTP id 9C4864437F for ; Tue, 17 Oct 2000 10:16:06 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Tue Oct 17 11:14:13 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 3C8C644380; Tue, 17 Oct 2000 11:01:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ans.ih.lucent.com (ans.ih.lucent.com [135.2.78.5]) by lists.bell-labs.com (Postfix) with SMTP id DE5B84437D for ; Tue, 17 Oct 2000 11:01:03 -0400 (EDT) Received: by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id KAA19673; Tue, 17 Oct 2000 10:00:46 -0500 Cc: jdrosen@dynamicsoft.com, sip@lists.bell-labs.com, sip-implementors@cs.columbia.edu Received: from lucent.com by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id KAA19648; Tue, 17 Oct 2000 10:00:44 -0500 Message-ID: <39EC6999.9578143@lucent.com> From: "Vijay K. Gurbani" Reply-To: vkg@lucent.com Organization: Intelligent Network/Messaging Systems & Internet Software Group X-Mailer: Mozilla 4.61 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Cliff.Harris@nokia.com Original-CC: jdrosen@dynamicsoft.com, sip@lists.bell-labs.com, sip-implementors@cs.columbia.edu Subject: Re: [SIP] CANCEL/200 OK/BYE References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 17 Oct 2000 10:00:41 -0500 Content-Transfer-Encoding: 7bit Cliff.Harris@nokia.com wrote: > > > -----Original Message----- > > From: EXT Vijay K. Gurbani [mailto:vkg@lucent.com] > [ . . . ] > > I think the spec should state that a UAC MUST send a BYE iff after > > having sent a CANCEL (for an in-progress INVITE), it got a 200 class > > response to the INVITE (which means that the 200 OK and > > CANCEL "crossed > > each other on the wire"). [...] > The note in section 4.2.5 of the RFC-bis draft makes it fairly clear > that BYE may be used instead of CANCEL. I am not sure I understand that paragraph; or let me rephrase -- based on my understanding of the paragraph, I don't agree with it. Unless a UAC has received a 200 OK for an INVITE, there is no session (or a call) established yet. Now, if the UAC hangs up before receiving a 200 OK, it SHOULD send out a CANCEL to the next downstream server, not a BYE. If the next downstream server happens to be a proxy, the CANCEL will reach the same destinations that the INVITE did, which is what we would want to happen, I would think. If the next downstream server is the intended UAS, the CANCEL should halt its state-machine so it does not send a 200 OK (in case it already has by the time it gets the CANCEL, the CANCEL has no effect on its state machine and the UAC will ACK the 200 OK and THEN send a BYE -- the route has been established through the 200 OK so the BYE can reach it's intended destination without further "forking"). > One very good reason for using BYE instead of CANCEL is that BYE may > have an attachment and CANCEL may not. In the SIP-T case, if the UAC > wants to include an attached PSTN message when the caller hangs up > before the far end has answered, BYE has to be used. Out of curisority, why can't the attachment be sent within the CANCEL? > I guess there are issues with tags and routes and all that. I don't > know if the spec addresses this, but in my naive view it would make > sense if a proxy that received a BYE without a tag sent it to all > possible destinations, to ensure that the UAS that received the INVITE > will also get the BYE. What you describe above is "forking" the BYE request. IMHO, "forking" the INVITE makes eminent sense; I am not convinced that forking of other requests (namely, BYE, OPTIONS and CANCEL) makes equal sense. What is the effect of forking an OPTIONS request (if that is the VERY FIRST request to arrive at a forking proxy?) I bought up this point on the list a few weeks ago (interested parties can search the archive). - vijay -- Vijay K. Gurbani vkg@lucent.com vkg@research.bell-labs.com vkg@acm.org Internet Software Group/Intelligent Network and Messaging Systems Lucent Technologies/Bell Labs Innovations, 263 Shuman Blvd, Rm 1A-413 Naperville, Illinois 60566 Voice: +1 630 224 0216 Fax: +1 630 713 0184 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 17 12:26:19 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA15823 for ; Tue, 17 Oct 2000 12:26:18 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4762644338; Tue, 17 Oct 2000 11:26:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lists.bell-labs.com (Postfix) with ESMTP id BBE3544336 for ; Tue, 17 Oct 2000 11:25:11 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id e9HGP2Z06131; Tue, 17 Oct 2000 18:25:03 +0200 (MEST) 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 TAA21462; Tue, 17 Oct 2000 19:24:59 +0300 (EET DST) Received: from lmf.ericsson.se (E0080C77A56E4.lmf.ericsson.se [131.160.105.66]) by greymse1.lmf.ericsson.se (8.9.3 (PHNE_18979)/8.8.6) with ESMTP id TAA17288; Tue, 17 Oct 2000 19:24:55 +0300 (EETDST) Message-ID: <39EC7D46.1C2451E8@lmf.ericsson.se> From: Gonzalo Camarillo Organization: Ericsson X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: vkg@lucent.com Cc: sip@lists.bell-labs.com Subject: Re: [SIP] CANCEL and stateless proxies References: <39EC76EB.8484D0A4@lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 17 Oct 2000 19:24:38 +0300 Content-Transfer-Encoding: 7bit Hi, "Vijay K. Gurbani" wrote: > Gonzalo: > > Just to be sure, I think your issue is different than the one I am > currently battling with, correct? Your issue appears to be sending a > BYE (or CANCEL) after a successful INVITE (i.e. UAC got 200 OK). Mine > is terminating the INVITE before getting a final response. If the UAC has already gotten a 200 OK there is no issue, because BYE will be routed based on the Record-Route header received. The issue I describe here (see another mail in this thread for an example) appears when the UAC does not have a Record-Route header + a tag in the To field to route the call. Actually this is very much related to your "battle". Best regards, Gonzalo > > > My question is: the same way proxies storing just transaction > > state (not call state) might route a BYE to a different host than the > > previous INVITE, a stateless proxy might route a CANCEL in a wrong > > way. What am I missing? > > A BYE, following a successful INVITE transaction will follow the route > established in the 200 OK (bis, Section 11.2, Callee Issues Response, > "...The UAS MUST add a Contact header in the response. It contains the > address where the callee would like to be contacted for subsequent > transactions."). So it appears to me that the BYE, even if processed > by a stateless proxy, should end up at a consistent destination due to > the Contact (or Route list, if a proxy Record-Route'd) headers. > > You may be right about the CANCEL wandering to a different host if > routed through a stateless proxy. Thus, after a successful INVITE, BYE > IS the way to go, not CANCEL. > > Regards, > > - vijay > -- > Vijay K. Gurbani vkg@lucent.com vkg@research.bell-labs.com vkg@acm.org > Internet Software Group/Intelligent Network and Messaging Systems > Lucent Technologies/Bell Labs Innovations, 263 Shuman Blvd, Rm 1A-413 > Naperville, Illinois 60566 Voice: +1 630 224 0216 Fax: +1 630 713 0184 -- 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 31 18 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 17 12:52:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA16553 for ; Tue, 17 Oct 2000 12:52:02 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E5FC14433D; Tue, 17 Oct 2000 11:52:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from is1-55.antd.nist.gov (is1-60.antd.nist.gov [129.6.60.251]) by lists.bell-labs.com (Postfix) with ESMTP id CC26544338 for ; Tue, 17 Oct 2000 11:51:18 -0400 (EDT) Received: from nist.gov (IDENT:mranga@stinkbug.antd.nist.gov [129.6.55.9]) by is1-55.antd.nist.gov (8.9.3/8.9.3) with ESMTP id MAA03539; Tue, 17 Oct 2000 12:46:42 -0400 (EDT) Message-ID: <39EC8381.60C5047D@nist.gov> From: "M. Ranganathan" Reply-To: mranga@nist.gov Organization: NIST advanced networking technologies group X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Content-Type: text/plain; charset=iso-8859-1 Subject: [SIP] nit-pickey JAIN-SIP questions Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 17 Oct 2000 12:51:13 -0400 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id MAA16553 Hi Chris / other authors of the JAIN-SIP spec ! The following questions may be a little nit-pickey. However, I prefer to be minimialistic when defining a spec: 1. I know that the sip RFC talks about different header classifications such as GeneralHeader, EntityHeader, RequestHeader and ResponseHeader. However, in my opinion (perhaps this is a wrong opinion - in which case please educate me on this one), this is more of a logical separation than a necessary one for any implementation to follow. Why does the API have to divide things the same way? ( I am suggesting shrinking the class hierarchy by 1 level. - no big deal, just minimialism at work) 2. The Header structure in the JAIN API has public final integers that are basically identifiers for the classes that inherit from it. I assume the intent is to let the client query the type of class so that it can know whether the Header is a GeneralHeader, RequestHeader etc. Why do you need the integers to identify the type of header a client can use introspection to find the class. This way you can also eliminate getHeaderType() (rely on the caller to use introspection). 3. Does the token value in various headers refer to the string from which the header was generated? More questions to follow while I ponder implementation.... Regards Ranga -- M.Ranganathan NIST Advanced Networking Technologies Group, 100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899. Tel: 301 975 3664 Fax: 301 590 0932 ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÒ ùšŠX§‚X¬µ"þX¬¶ÏÛzYÿ•¦ìýÊ&†ÛiÿÿåŠËlý·¥—ùZnÏÜ¢oæj)fjåŠËbú? From sip-admin@lists.bell-labs.com Tue Oct 17 12:56:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA16689 for ; Tue, 17 Oct 2000 12:56:05 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9F6B344338; Tue, 17 Oct 2000 11:56:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ss3000e.cselt.it (ss3000e.cselt.it [163.162.41.5]) by lists.bell-labs.com (Postfix) with ESMTP id 059E444336 for ; Tue, 17 Oct 2000 11:55:29 -0400 (EDT) Received: from rabadan.cselt.it (rabadan.cselt.it [163.162.4.12]) by ss3000e.cselt.it (PMDF V5.2-31 #43137) with ESMTP id <0G2L00JDJ2YGK2@ss3000e.cselt.it> for sip@lists.bell-labs.com; Tue, 17 Oct 2000 18:54:16 +0200 (MET DST) Received: by rabadan.cselt.it with Internet Mail Service (5.5.2650.21) id <47JRMKXZ>; Tue, 17 Oct 2000 18:58:04 +0200 Content-return: allowed From: Canal Gianni Subject: RE: [SIP] Conferencing To: "'sip@lists.bell-labs.com'" Message-id: MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 17 Oct 2000 18:55:10 +0200 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA16689 Hi, considering "conference control" like the feature to allow conference participants (with apropriate rights) to change the status of the conference session e.g. inviting/dropping participants, I doubt that in the mentioned model there is a real "conference control", am I wrong? A conference control should allow scenarios like (e.g.) the following: 1) user A decides to set up a conference session (this could be done as suggested). User A is the chair. 2) user A wants to invite user B and user C to the same session 3) user A wants to drop user B to the session 4) user C wants to invite user D to the session (A could be requested to grant C to do this) 5) user C wants to drop D to the session (A could be requested to grant C to do this) 6) user C wants to quit the session (A could be requested to grant C to do this) 7) user A wants to exit the session (A could be requested to pass the chairmanship to another participant) 8) user A wants to quit the session (all the other participant are dropped) 9) ... Has this already been covered by some drafts? If so .. sorry to bother you ... If not, could it be interesting to investigate how to use SIP in these scenarios? (we worked about conferencing modeling in other contexts thus we have a lot of scenarios to investigate.) Best Regards from flooded Italy Gianni > ---------- > From: Jonathan Rosenberg[SMTP:jdrosen@dynamicsoft.com] > Sent: mercoledì 11 ottobre 2000 20.24 > To: 'Aparna.Vemuri@Level3.com'; 'sip@lists.bell-labs.com' > Subject: RE: [SIP] Conferencing > > In the dial-up conference model, the request URI is really the only usable > identifier that can describe the conference. > > Think of it as exactly the way conferences work in the PSTN; you dial a > number plus a passcode (whcih is just an extension of the number, needed > because of the limited number of phone numbers available), and that number > represents the conference. Same here. A conferencing server should mix > together everyone who calls the same request URI; that would be the nature > of the resource defined by the collection of URIs on the conference > server. > As an example, a conference server might define: > > *-adhoc@conferences.com > > where * is anything, to represent ad-hoc conferences which don't even need > to be pre-established. > > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 17 13:20:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA17205 for ; Tue, 17 Oct 2000 13:20:03 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6CFE14433B; Tue, 17 Oct 2000 12:20:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cisco.com (bounty.cisco.com [161.44.3.204]) by lists.bell-labs.com (Postfix) with ESMTP id D5E5C44336 for ; Tue, 17 Oct 2000 12:19:30 -0400 (EDT) Received: from cisco.com (blanc.cisco.com [161.44.3.203]) by cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id NAA10180; Tue, 17 Oct 2000 13:18:54 -0400 (EDT) Message-ID: <39EC89F4.CACDCD09@cisco.com> From: Bryan Byerly X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Christer Holmberg , jdrosen@cisco.com, henning@cisco.com Cc: byerly@cisco.com, stlevy@cisco.com, jryang@cisco.com, sip@lists.bell-labs.com Subject: Re: [SIP] From header to ISUP CgPN mapping References: <39EB69C3.4A7F24C@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 17 Oct 2000 13:18:45 -0400 Content-Transfer-Encoding: 7bit Hi guys, What do you guys think about using the Diversion header (http://www.ietf.org/internet-drafts/draft-levy-sip-diversion-00.txt) instead of Also-From? It seems like a natural replacement to me. Thanks! Bryan Christer Holmberg wrote: > Hi, > > This is something I've also been looking into. > > One way would be to add a new header (e.g. Also-From). That header could > be inserted by a proxy that does know the request may end up in a > gateway. The UA may not know that, so he could put whatever string in > the user part of the From header (e.g. his e-mail address). If the proxy > then knows the UAs telephone number, for example by using some kind of > database lookup, which is needed by the gateway - for any possible > A-number procedure - the proxy can add that to the request. > > Another way would be to just define a URI parameter for the From header, > but the bad thing about that is that it can not be inserted by a proxy > if it was not in the request from the UA (since the From header must not > be changed) by a proxy, or any other intermediate node. > > Note, that this response is according to Clive's mail. I do NOT support > the idea of ALSO-TO headers, multiple FROM/TO headers and whatever was > proposed in the previous mails :) > > Regards, > > Christer Holmberg > Ericsson Finland > > clive.dellard@bt.com wrote: > > > > I agree with what you say, however, if you consider a call originating from > > a SIP device (telephone or softphone) that ends up going through a gateway > > to the PSTN then it is a different story. > > Neither the user or the UAC can know where a call will end up, therefore the > > ability to be able to provide both SIP address and SIP Telephone number > > would be useful to providing a complete service as then an appropriate > > calling address is available wherever the call ends up. In the scenario I > > described the gateway could chose the Telephone number (ok I know there are > > verification issues but that's another story). > > Something like Simon's idea of an "ALSO-FROM" seems a good idea to me (this > > is similar to "two number delivery" in the ISDN CLIP service) older versions > > would just ignore the ALSO-FROM and it wouldn't affect the significance of > > the FROM and TO headers. > > > > Clive > > > > > -----Original Message----- > > > From: Jonathan Rosenberg [SMTP:jdrosen@dynamicsoft.com] > > > Sent: Wednesday, October 11, 2000 7:41 PM > > > To: 'clive.dellard@bt.com'; 'sip@lists.bell-labs.com' > > > Subject: RE: [SIP] From header to ISUP CgPN mapping > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: clive.dellard@bt.com [mailto:clive.dellard@bt.com] > > > > Sent: Wednesday, October 11, 2000 12:17 PM > > > > To: sip@lists.bell-labs.com > > > > Subject: [SIP] From header to ISUP CgPN mapping > > > > > > > > > > > > In the call flows document draft-ietf-sip-call-flows-01.txt, > > > > scenario 4.1.1, > > > > the message detail and text show User A using a SIP telephone > > > > number rather > > > > than a SIP address in the From header. The text at the > > > > beginning of section > > > > 4 also says "that User A still uses his/her SIP URL in the > > > > Contact header, > > > > since the call could be redirected back to the SIP network." > > > > This implies that User A has pre-knowledge that the call is > > > > going to route > > > > to the PSTN and has the ability to chose the address to be > > > > used in the From > > > > header. > > > > > > No. > > > > > > The From header is the logical identity of the user making the call. Since > > > the call is coming through a gateway, that user is some user on a PSTN > > > terminal somewhere. The identity in this case can either be a tel URL, or > > > a > > > SIP URL at the domain of the originating network. > > > > > > The Contact is used for signaling addressing. Its not a logical > > > identifier. > > > It answers the question "where should I send SIP messages to for the rest > > > of > > > this call". The SIP spec says this is supposed to be a SIP URL preferably > > > with a complete hostname, so that there are no ambiguities about where to > > > send requests. > > > > > > Neither of these have anything to do with knowing where the call is going. > > > > > > -Jonathan R. > > > > > > --- > > > Jonathan D. Rosenberg 72 Eagle Rock Ave. > > > Chief Scientist First Floor > > > dynamicsoft East Hanover, NJ 07936 > > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > > > http://www.dynamicsoft.com > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 17 14:21:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA18649 for ; Tue, 17 Oct 2000 14:21:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 25CBD44338; Tue, 17 Oct 2000 13:21:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 59ADC44336 for ; Tue, 17 Oct 2000 13:20:24 -0400 (EDT) Received: from dynamicsoft.com (useraa88.ie.uudial.com [212.120.133.89]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id OAA18444; Tue, 17 Oct 2000 14:22:26 -0400 (EDT) Message-ID: <39EC9870.417BBB7E@dynamicsoft.com> From: Chris Harris Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: mranga@nist.gov Cc: sip@lists.bell-labs.com, jainsip@sun.com Subject: Re: [SIP] nit-pickey JAIN-SIP questions References: <39EC8381.60C5047D@nist.gov> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 17 Oct 2000 19:20:32 +0100 Content-Transfer-Encoding: 8bit Some very good questions indeed! "M. Ranganathan" wrote: > Hi Chris / other authors of the JAIN-SIP spec ! > > The following questions may be a little nit-pickey. However, I prefer > to be minimialistic when defining a spec: > > 1. I know that the sip RFC talks about different header classifications > such as GeneralHeader, EntityHeader, RequestHeader and ResponseHeader. > However, in my opinion (perhaps this is a wrong opinion - in which case > please educate me on this one), > this is more of a logical separation than a necessary one for any > implementation to follow. Why does the API have to divide things the > same way? ( I am suggesting shrinking the class hierarchy by 1 level. - > no big deal, just minimialism at work) The main reason for these four classes is to represent extension headers which are not covered by the API header classes. Let's say the underlying implementation knows about a general header that is not in the API. The default behaviour is to regard an unrecognised header as an entity header, but surely the underlying implementation should be able to say to the application (which may or may not understand this header) which type of header it is. (This applies from the application to the implementation too). Also, an implementation may indicate to an application that a particular unrecognised header is a request header, and so should not be included in a response. These reasons may not warrant the extra level in the hierarchy - see next response... > > > 2. The Header structure in the JAIN API has public final integers > that are basically identifiers for the classes that inherit from it. I > assume the intent is to let the client query the type of class so that > it can know whether the Header is a GeneralHeader, RequestHeader etc. > Why do you need the integers to identify the type of header a client can > use introspection to find the class. This way you can also eliminate > getHeaderType() (rely on the caller to use introspection). Introspection would certainly work perfectly - I just wanted to have a more convenient way for the user to determine the header type. But, as I understand it introspection is not exactly cheap compared to a simple accessor method call. Looking at it now - the getHeaderType method on the Header class makes the four classes obsolete. (Unless introspection is preferable in an API, in which case the getHeaderType method should go) Actually this makes me realise something about the Message and Header classes - the constructors pass the Message's method or Header's token (see below) to the super constructor. The API internally uses the getMethod and getToken methods to determine the message or header type, rather than introspection - which assumes that the implementor or user will use the correct class (e.g. InviteMessage rather than RequestMessage, CallIdHeader rather than Header or GeneralHeader). I used these methods for performance reasons, but now that I think about it, there is nothing stopping them from using the wrong class - so if a RequestMessage object is encountered with a method "INVITE" it is incorrect to assume that this is also an InviteMessage object - introspection is the only real way to know which class it is using. If introspection reveals that it uses the correct class that's OK - cast to InviteMessage, but if it's not, then what? - should you create an InviteMessage object based on the RequestMessage object so you can use the extra methods? > > > 3. Does the token value in various headers refer to the string from > which the header was generated? The token is the name of the header e.g. "Call-Id" - "token" was a poor choice - perhaps "OptionTag" would be more appropriate? > > > More questions to follow while I ponder implementation.... > > Regards > > Ranga > > -- > M.Ranganathan > NIST Advanced Networking Technologies Group, > 100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899. > Tel: 301 975 3664 Fax: 301 590 0932 > > Hƒæj)bž b²Ôˆ>X¬¶ÆÞ–YZnÇ(šm§ÿåŠËlmée•¦ìr‰¿™¨¥™©ÿ–+-ŠwèþÈ© _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 17 15:06:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA19440 for ; Tue, 17 Oct 2000 15:06:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 060FE44338; Tue, 17 Oct 2000 14:06:03 -0400 (EDT) Delivered-To: sip@share.research.bell-labs.com Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by lists.bell-labs.com (Postfix) with SMTP id 1B2BA44336 for ; Tue, 17 Oct 2000 11:12:07 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Tue Oct 17 12:10:48 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 7901944380; Tue, 17 Oct 2000 11:57:39 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ans.ih.lucent.com (ans.ih.lucent.com [135.2.78.5]) by lists.bell-labs.com (Postfix) with SMTP id 36B994437D for ; Tue, 17 Oct 2000 11:57:39 -0400 (EDT) Received: by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id KAA20449; Tue, 17 Oct 2000 10:57:35 -0500 Cc: sip@lists.bell-labs.com, Vijay Gurbani Received: from lucent.com by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id KAA20439; Tue, 17 Oct 2000 10:57:34 -0500 Message-ID: <39EC76EB.8484D0A4@lucent.com> From: "Vijay K. Gurbani" Reply-To: vkg@lucent.com Organization: Intelligent Network/Messaging Systems & Internet Software Group X-Mailer: Mozilla 4.61 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Gonzalo.Camarillo@lmf.ericsson.se Original-CC: sip@lists.bell-labs.com, Vijay Gurbani Subject: Re: [SIP] CANCEL and stateless proxies References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 17 Oct 2000 10:57:31 -0500 Content-Transfer-Encoding: 7bit Gonzalo.Camarillo@lmf.ericsson.se wrote: > > Hi, > > A CANCEL request for a previous INVITE follows the same path as > the INVITE. This way the CANCEL request arrives to the same set of > hosts as the INVITE. > > Stateful proxies storing transaction state perform this routing > fine. > > What about stateless proxies? The CANCEL might be routed in a > different way than the previous INVITE. > > This issue is somehow related to the "BYE after a INVITE" issue. It is > preferable to send a CANCEL rather than a BYE after a INVITE because > stateful proxies storing transaction state will route the CANCEL > properly. The BYE might be routed in a wrong way. Gonzalo: Just to be sure, I think your issue is different than the one I am currently battling with, correct? Your issue appears to be sending a BYE (or CANCEL) after a successful INVITE (i.e. UAC got 200 OK). Mine is terminating the INVITE before getting a final response. > My question is: the same way proxies storing just transaction > state (not call state) might route a BYE to a different host than the > previous INVITE, a stateless proxy might route a CANCEL in a wrong > way. What am I missing? A BYE, following a successful INVITE transaction will follow the route established in the 200 OK (bis, Section 11.2, Callee Issues Response, "...The UAS MUST add a Contact header in the response. It contains the address where the callee would like to be contacted for subsequent transactions."). So it appears to me that the BYE, even if processed by a stateless proxy, should end up at a consistent destination due to the Contact (or Route list, if a proxy Record-Route'd) headers. You may be right about the CANCEL wandering to a different host if routed through a stateless proxy. Thus, after a successful INVITE, BYE IS the way to go, not CANCEL. Regards, - vijay -- Vijay K. Gurbani vkg@lucent.com vkg@research.bell-labs.com vkg@acm.org Internet Software Group/Intelligent Network and Messaging Systems Lucent Technologies/Bell Labs Innovations, 263 Shuman Blvd, Rm 1A-413 Naperville, Illinois 60566 Voice: +1 630 224 0216 Fax: +1 630 713 0184 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 17 15:44:32 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA19930 for ; Tue, 17 Oct 2000 15:44:31 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8C57A44341; Tue, 17 Oct 2000 14:44:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lists.bell-labs.com (Postfix) with ESMTP id 8D32B44336 for ; Tue, 17 Oct 2000 14:43:32 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id e9HJhRt01548; Tue, 17 Oct 2000 21:43:27 +0200 (MEST) 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 WAA27801; Tue, 17 Oct 2000 22:43:26 +0300 (EET DST) Received: from lmf.ericsson.se (E005004B52C74-udp424598.lmf.ericsson.se [131.160.106.10]) by greymse1.lmf.ericsson.se (8.9.3 (PHNE_18979)/8.8.6) with ESMTP id WAA08342; Tue, 17 Oct 2000 22:43:21 +0300 (EETDST) Message-ID: <39ECABD9.75B6EE66@lmf.ericsson.se> From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Cc: hammer michael Subject: Re: [SIP] Session-timer with INFO References: <36FA02BD7083D411BC9E0000F8073E43E70643@crchy271.us.nortel.com> <4.3.2.7.2.20001017094755.00b438f0@cia.cisco.com> <4.3.2.7.2.20001017103200.00b46730@cia.cisco.com> Content-Type: multipart/mixed; boundary="------------103A3E39BAF4EA61789FBB4F" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 17 Oct 2000 22:43:21 +0300 This is a multi-part message in MIME format. --------------103A3E39BAF4EA61789FBB4F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, >Thus you are in support of not trying to implicitly use a method to do >what a subordinate capability should be explicitly defined to do? I didn't say that. Of course it is nice if we can get-two-things-by-doing-one, but in this case I just see some issues. Again, first there is the thing that by using re-INVITEs we will generate ACKs. Second, which I think is related to your mail, is when the UAS boots, and the re-INVITE is seen as a new INVITE to establish a new session. We may get 18x responses before the final response, and the final response can be a 3xx, 4xx, 5xx or 6xx response, and in some cases it may be very difficult for the UAC to behave in a good way. If we use INFO, and receive 481, the UAS knows that the session doesn't exist anymore, and can do whatever is needed, and then, if wanted, send a new INVITE to re-establish the call. It gives the UAC more control, and the UAC may, for some reason, even want to know if a session died. Regards, Christer Holmberg Ericsson Finland > > Mike > > At 05:00 PM 10/17/2000 +0300, Christer Holmberg wrote: > > >Hi, > > > >If I send you an INFO, or any other method that you don't support, you > >can for example send a 501 Not Implemented response, and include an > >Allow header with the methods you support. Of course, you can't stop the > >UAC of sending the method again, if he chooses to... > > > >You can not, however, tell an UAC not to send you re-INVITEs, because > >then you would also forbid the UAC to send you INVITEs - and I don't > >think you want to do that. Also, the specification says that a UA MUST > >be able to receive INVITEs (which included re-INVITEs), so... > > > >Regards, > > > >Christer Holmberg > >Ericsson Finland > > > > > >hammer michael wrote: > > > > > > Is this the Internet version of "let them eat cake?" Signal-spam is not > > > more palatable than the normal variety. > > > > > > Is there a response code that can indicate the sentiment: I don't support > > > this method, don't try it again? It might also be good to make sure that > > > such undesirable sub-methods are indicated as "Unsupported." If that > > > sub-method is well-defined, then that header parameter should be > > applicable. > > > > > > Mike > > > > > > At 12:30 AM 10/17/2000 +0300, Christer Holmberg wrote: > > > > > > >Hi, > > > > > > > > >Good points. Here's one more problem you may want to consider. > > > > >Whenever you invoke a ping-style method of deciding if a session is > > > > >alive, you open up problems due to network jitter and bandwidth. For > > > > >instance, you could easily have a packet delayed at an endpoint due to > > > > >a large file transfer starting up, or some other bandwidth consuming > > > > >event. In this case, your ping could be delayed long enough to cause > > > > >the session to drop for no good reason. > > > > > > > >Well, this could be the case no matter which method (INVITE, INFO, or > > > >whatever...) you use in the heartbeat request... > > > > > > > > >You're also creating the potential for artificial problems in wireless > > > > >networks by using a ping-method to keep a session alive. During a > > > > >handover there may be a period where packets are in effect "muted" for > > > > >a short period of time. The mute period may not, by itself be long > > > > >enough to trigger a ping-timer to pop and kill the session, but if the > > > > >ping was near the edge of the time envelope to be accepted as > > > > >"on-time" anyhow, once again, your session could very easily drop when > > > > >the media was operating just fine. > > > > >Also, keep in mind, the longer you set the ping timer for, the more > > > > >network resources you will likely waste over time because of the > > > > >additional latentcy in discovering a "dead" session. > > > > > > > >Just to clarify, this "ping-method" IS already defined for SIP > > > >(draft-ietf-sip-session-timer-02.txt), and re-INVITEs are used to ping. > > > >My idea was about replacing the re-INVITE with INFO, which mean we would > > > >actually save resources since we don't have to send ACK every time. > > > > > > > > >This method has one other nasty side-effect. You'd be wasting network > > > > >resources on an event that will likely not occur very often. After > > > > >all, every INFO exchange except the very last one that invalidates the > > > > >session could have very well not been sent without any negative impact > > > > >on the session (otherwise they would have been the last one). So > > > > >you've got proxies and UAs, and other transport resources being tied > > > > >up processing packets that by and large are providing no value, and > > > > >they're chewing up bandwidth budget that other services could be using > > > > >instead. > > > > > > > >That is an interesting point, and it is valid also for a number of other > > > >SIP extensions where extra messages are sent (e.g. PRACK), but it is > > > >another discussion. > > > > > > > > >Please keep in mind that not everyone is looking at implementing SIP > > > > >on a 10Mbit+ hardwired LAN (or has to scale up to tremendous numbers > > > > >of users), pinging and triangle-routing can be the death-knell of > > > > >these sorts of networks. > > > > > > > >Who said "bandwidth is free"? :) > > > > > > > > >Because of all of this, I think it would be a very bad idea for a UA > > > > >to send an INFO to a client who repeatedly tells him "I don't > > > > >understand INFO" to see if he's alive. > > > > > > > >The number of messages on the network will be the same no matter if we > > > >send an INVITE which he understands, or an INFO he may not understand. > > > >Also, when we receive the response for the INVITE we also have to send > > > >back an ACK, which is not the case when INFO is used. > > > > > > > > >He may not understand INFO because that particular network doesn't > > > > deem >the bandwidth required for this mechanism as being best used for > > > > that >purpose. If someone tells you "don't send me this method" then > > > > don't send >it to them. > > > > > > > >Again, this has nothing to do with the bandwith issue. Even if I send > > > >re-INVITEs, which the other party understands, he can not tell me not to > > > >send any more re-INVITEs. > > > > > > > > >Otherwise your implementation may be viewed as favorably as the record > > > > >clubs that used to require you to send them a card every month telling > > > > >them not to send you anything by some groups. > > > > > > > >Well, it's not up to me to decide when and if an operator will use the > > > >session-timer, as defined in the draft, or not - I am just trying to > > > >make it as good (and less resource consuming) if he choses to. > > > > > > > >Regards, > > > > > > > >Christer Holmberg > > > >Ericsson Finland > > > > > > > > > > > > > > > > > > Brian Stucker > > > > > Nortel Networks > > > > > > > > > > -----Original Message----- > > > > > From: Culpepper, Bert [mailto:bert.culpepper@intervoice-brite.com] > > > > > Sent: Monday, October 16, 2000 3:38 PM > > > > > To: Christer Holmberg; sip@lists.bell-labs.com > > > > > Cc: Rohan Mahy > > > > > Subject: RE: [SIP] Session-timer with INFO > > > > > > > > > > Some things to think about. > > > > > > > > > > I believe INFO is _not_ to be used to modify the state of a session. > > > > > I > > > > > suppose a debate is possible about session-timer affecting session > > > > > state - present vs. future and if INFO is only restricted to one. But > > > > > it's > > > > > probably best to leave it alone. Also, the INV-200-ACK exchange > > > > > allows multiple parties to agree on the duration of the session. If > > > > > the > > > > > recipient of the INFO request wants a smaller value (because its > > > > > heartbeat interval is shorter) for the session timer it would have to > > > > > send its own INFO request (unless you plan to keep the proposed > > > > > Session-expires header and its use in a 200 OK). Now four > > > > > messages are needed. In addition, there may be proxy issues when > > > > > using INFO. There's other behavior described in the draft too. > > > > > > > > > > > -----Original Message----- > > > > > > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > > > > > > Sent: Monday, October 16, 2000 3:42 PM > > > > > > To: sip@lists.bell-labs.com > > > > > > Cc: Rohan Mahy > > > > > > Subject: Re: [SIP] Session-timer with INFO > > > > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > Thanks for the comments! > > > > > > > > > > > > >If the UA crashed and rebooted and forgot about the old session, it > > > > > > > > > > > would > > > > > > >respond with either a 481 call leg doesn't exist (you would know > > > > > the > > > > > > call > > > > > > >is down), or a 501 (you know the UA is up, but is the call?) > > > > > > > > > > > > > >thanks, > > > > > > >-rohan > > > > > > > > > > > > I think that would be good, because then we could inform the user > > > > > that > > > > > > the call doesn't exist anymore. > > > > > > > > > > > > Let's assume the UAS crashes, reboots and the UAC sends the > > > > > > session-timer re-INVITE. If the UAS has forgotten about the old > > > > > > session > > > > > > it would consider the re-INVITE as a new INVITE, for a new session. > > > > > It > > > > > > would try to establish a new session - and we could suddenly start > > > > > > receiving provisional 18x responses (with or without SDP bodies), > > > > > > and/or > > > > > > a 200 response with a SDP body, to the session-timer re-INVITE. What > > > > > > > > > > > do > > > > > > we do then? > > > > > > > > > > Well, you could ignore the provisional responses (you know the other > > > > > end > > > > > is confused) and let the session get re-established or decide to > > > > > terminate > > > > > the session with CANCEL/BYE. > > > > > > > > > > Regards, > > > > > Bert > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > Christer Holmberg > > > > > > Ericsson Finland > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > At 10:55 AM 10/16/00 , Christer Holmberg wrote: > > > > > > > > > > > > > > > >Hi, > > > > > > > > > > > > > > > >First, this mail is NOT a proposal for a change. I would just > > > > > like > > > > > > to > > > > > > > >hear some opinions - or maybe it has already been discussed on > > > > > the > > > > > > list? > > > > > > > > > > > > > > > >The INFO Method RFC says that for INFO requests without a message > > > > > > > > > > > body, > > > > > > > >a server supporting INFO MUST respond with response code 200. So, > > > > > > > > > > > my > > > > > > > >question is: why couldn't INFO be used for the session-timer > > > > > > > >functionality? Is the ACK the (re-)INVITE provides really > > > > > necessary > > > > > > for > > > > > > > >the purpose? > > > > > > > > > > > > > > > >And, like the session-timer is defined now, the other party would > > > > > > > > > > > not > > > > > > > >even have to support the INFO method, because a 501 Not > > > > > Implemented > > > > > > > >would be sent, and the sender of the INFO would know the session > > > > > is > > > > > > > >"alive". > > > > > > > > > > > > > > > >Just some thoughts... Please let me know if there is something I > > > > > > haven't > > > > > > > >taken into consideration. > > > > > > > > > > > > > > > >Regards, > > > > > > > > > > > > > > > >Christer Holmberg > > > > > > > >Ericsson Finland > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > SIP mailing list > > > > > SIP@lists.bell-labs.com > > > > > http://lists.bell-labs.com/mailman/listinfo/sip --------------103A3E39BAF4EA61789FBB4F Content-Type: text/x-vcard; charset=us-ascii; name="christer.holmberg.vcf" Content-Description: Card for Christer Holmberg Content-Disposition: attachment; filename="christer.holmberg.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Holmberg;Christer tel;cell:+358-40-5604412 tel;work:+358-9-2992943 x-mozilla-html:FALSE org:Ericsson;Advanced Signalling Research Laboratory adr:;;;;;; version:2.1 email;internet:christer.holmberg@lmf.ericsson.se title:System Designer fn:Christer Holmberg end:vcard --------------103A3E39BAF4EA61789FBB4F-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 17 15:50:10 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA20099 for ; Tue, 17 Oct 2000 15:50:10 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id AFE9844341; Tue, 17 Oct 2000 14:50:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lists.bell-labs.com (Postfix) with ESMTP id 8DA9044338 for ; Tue, 17 Oct 2000 14:49:58 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id e9HJnrt02199; Tue, 17 Oct 2000 21:49:53 +0200 (MEST) 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 WAA27951; Tue, 17 Oct 2000 22:49:52 +0300 (EET DST) Received: from lmf.ericsson.se (E005004B52C74-udp424598.lmf.ericsson.se [131.160.106.10]) by greymse1.lmf.ericsson.se (8.9.3 (PHNE_18979)/8.8.6) with ESMTP id WAA08811; Tue, 17 Oct 2000 22:49:49 +0300 (EETDST) Message-ID: <39ECAD54.ADB04609@lmf.ericsson.se> From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Cc: Lars Berggren Subject: Re: [SIP] Session-timer with INFO References: Content-Type: multipart/mixed; boundary="------------7316E3C974577A82AFBE7EA2" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 17 Oct 2000 22:49:40 +0300 This is a multi-part message in MIME format. --------------7316E3C974577A82AFBE7EA2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, >>>I think the re-INVITE mechanism is far more better because the >information about what session is refreshed >>>is carried in the SDP of the re-INVITE. The INFO approach has the significant disadvantage that >proxies >>>that use the session timer might have to store a *lot* of state information about each session. >>That is not true. The session is identified using the Call-ID. >The call-id is the SIP-identifier of a session, yes. But, SIP >initiates a multimedia session and if the proxy is doing stuff (like >allocating some sort of network resources for a limited period of >time) related to the multimedia session and is interested in knowing when >that session ends it might add a session timer. Now, if all the >information that set up the session gets repeated in the re-INVITE the >proxy does not have to store call-id etc together with the multimedia >session parameters to track which multimedia session the >SIP-message refers to. Well, that is true, but that is a very application specific issue. I don't think it's a big problem for the proxy to store the necessary session data (the endpoints have to store it too, to be able to resend it in the re-INVITEs), together with the Call-Id (you need to store the Call-ID in any case), compared to the fact that you save lots of resources, both in the network and due to the fact that the logic of the endpoints gets more simple. Regards, Christer Holmberg Ericsson Finland > > Regards, > > /Lars > > > > > In fact, another advantage of using INFO is that you don't have to send > > a message body at all. Using re-INVITE, you must send a copy of the > > original message, and the UAS must check if the SDP is a copy > > (session-timer) or if it is a new SDP, when the session should be > > modified. Again, we save resources. Comments? > > > > Regards, > > > > Christer Holmberg > > Ericsson Finland > > > > > > > > > > > > Regards /Lars > > > > > > > Regards, > > > > > > > > Christer Holmberg > > > > Ericsson Finland > > > > > > Lars Berggren > > > Intertex Data AB tel: +46-8-6282828 > > > Sundbyberg, Sweden fax: +46-8-6286414 > > Lars Berggren > Intertex Data AB tel: +46-8-6282828 > Sundbyberg, Sweden fax: +46-8-6286414 --------------7316E3C974577A82AFBE7EA2 Content-Type: text/x-vcard; charset=us-ascii; name="christer.holmberg.vcf" Content-Description: Card for Christer Holmberg Content-Disposition: attachment; filename="christer.holmberg.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Holmberg;Christer tel;cell:+358-40-5604412 tel;work:+358-9-2992943 x-mozilla-html:FALSE org:Ericsson;Advanced Signalling Research Laboratory adr:;;;;;; version:2.1 email;internet:christer.holmberg@lmf.ericsson.se title:System Designer fn:Christer Holmberg end:vcard --------------7316E3C974577A82AFBE7EA2-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 17 16:14:15 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA20357 for ; Tue, 17 Oct 2000 16:14:03 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id AA2A044338; Tue, 17 Oct 2000 15:14:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lists.bell-labs.com (Postfix) with ESMTP id 4570244336 for ; Tue, 17 Oct 2000 15:13:42 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id e9HKDaZ12760; Tue, 17 Oct 2000 22:13:37 +0200 (MEST) 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 XAA28749; Tue, 17 Oct 2000 23:13:36 +0300 (EET DST) Received: from lmf.ericsson.se (E005004B52C74-udp424598.lmf.ericsson.se [131.160.106.10]) by greymse1.lmf.ericsson.se (8.9.3 (PHNE_18979)/8.8.6) with ESMTP id XAA10773; Tue, 17 Oct 2000 23:13:34 +0300 (EETDST) Message-ID: <39ECB2ED.ECCE60A8@lmf.ericsson.se> From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Cc: Bryan Byerly , jdrosen@cisco.com, henning@cisco.com, stlevy@cisco.com, jryang@cisco.com Subject: Re: [SIP] From header to ISUP CgPN mapping References: <39EB69C3.4A7F24C@lmf.ericsson.se> <39EC89F4.CACDCD09@cisco.com> Content-Type: multipart/mixed; boundary="------------B66E35DE06E8A3AD3472B6EE" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 17 Oct 2000 23:13:33 +0300 This is a multi-part message in MIME format. --------------B66E35DE06E8A3AD3472B6EE Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, Using the Diversion header, you can inform an endpoint of which Request-URIs have been used before the Request-URI of that specific endpoint was used. The case I am talking about, however, is when we can insert an "alias" header for the From header, using a telephone number, if the From header is, for example, an e-mail address. Using this new header, let us call is Also-From, a proxy (or the calling endpoint itself) may also insert a telephone number, which can then be used by PSTN Gateways for any kind of A-number analysing. One could argue that the caller should always include a telephone number in the From header, but the caller may not know that the call will end up on the PSTN side, so... I DO like the Diversion draft very much, though, but it doesn't solve this specific problem :) Regards, Christer Holmberg Ericsson Finland Bryan Byerly wrote: > > Hi guys, > > What do you guys think about using the Diversion header > (http://www.ietf.org/internet-drafts/draft-levy-sip-diversion-00.txt) instead of > Also-From? > It seems like a natural replacement to me. > > Thanks! > Bryan > > Christer Holmberg wrote: > > > Hi, > > > > This is something I've also been looking into. > > > > One way would be to add a new header (e.g. Also-From). That header could > > be inserted by a proxy that does know the request may end up in a > > gateway. The UA may not know that, so he could put whatever string in > > the user part of the From header (e.g. his e-mail address). If the proxy > > then knows the UAs telephone number, for example by using some kind of > > database lookup, which is needed by the gateway - for any possible > > A-number procedure - the proxy can add that to the request. > > > > Another way would be to just define a URI parameter for the From header, > > but the bad thing about that is that it can not be inserted by a proxy > > if it was not in the request from the UA (since the From header must not > > be changed) by a proxy, or any other intermediate node. > > > > Note, that this response is according to Clive's mail. I do NOT support > > the idea of ALSO-TO headers, multiple FROM/TO headers and whatever was > > proposed in the previous mails :) > > > > Regards, > > > > Christer Holmberg > > Ericsson Finland > > > > clive.dellard@bt.com wrote: > > > > > > I agree with what you say, however, if you consider a call originating from > > > a SIP device (telephone or softphone) that ends up going through a gateway > > > to the PSTN then it is a different story. > > > Neither the user or the UAC can know where a call will end up, therefore the > > > ability to be able to provide both SIP address and SIP Telephone number > > > would be useful to providing a complete service as then an appropriate > > > calling address is available wherever the call ends up. In the scenario I > > > described the gateway could chose the Telephone number (ok I know there are > > > verification issues but that's another story). > > > Something like Simon's idea of an "ALSO-FROM" seems a good idea to me (this > > > is similar to "two number delivery" in the ISDN CLIP service) older versions > > > would just ignore the ALSO-FROM and it wouldn't affect the significance of > > > the FROM and TO headers. > > > > > > Clive > > > > > > > -----Original Message----- > > > > From: Jonathan Rosenberg [SMTP:jdrosen@dynamicsoft.com] > > > > Sent: Wednesday, October 11, 2000 7:41 PM > > > > To: 'clive.dellard@bt.com'; 'sip@lists.bell-labs.com' > > > > Subject: RE: [SIP] From header to ISUP CgPN mapping > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: clive.dellard@bt.com [mailto:clive.dellard@bt.com] > > > > > Sent: Wednesday, October 11, 2000 12:17 PM > > > > > To: sip@lists.bell-labs.com > > > > > Subject: [SIP] From header to ISUP CgPN mapping > > > > > > > > > > > > > > > In the call flows document draft-ietf-sip-call-flows-01.txt, > > > > > scenario 4.1.1, > > > > > the message detail and text show User A using a SIP telephone > > > > > number rather > > > > > than a SIP address in the From header. The text at the > > > > > beginning of section > > > > > 4 also says "that User A still uses his/her SIP URL in the > > > > > Contact header, > > > > > since the call could be redirected back to the SIP network." > > > > > This implies that User A has pre-knowledge that the call is > > > > > going to route > > > > > to the PSTN and has the ability to chose the address to be > > > > > used in the From > > > > > header. > > > > > > > > No. > > > > > > > > The From header is the logical identity of the user making the call. Since > > > > the call is coming through a gateway, that user is some user on a PSTN > > > > terminal somewhere. The identity in this case can either be a tel URL, or > > > > a > > > > SIP URL at the domain of the originating network. > > > > > > > > The Contact is used for signaling addressing. Its not a logical > > > > identifier. > > > > It answers the question "where should I send SIP messages to for the rest > > > > of > > > > this call". The SIP spec says this is supposed to be a SIP URL preferably > > > > with a complete hostname, so that there are no ambiguities about where to > > > > send requests. > > > > > > > > Neither of these have anything to do with knowing where the call is going. > > > > > > > > -Jonathan R. > > > > > > > > --- > > > > Jonathan D. Rosenberg 72 Eagle Rock Ave. > > > > Chief Scientist First Floor > > > > dynamicsoft East Hanover, NJ 07936 > > > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > > > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > > > > http://www.dynamicsoft.com > > > > > > _______________________________________________ > > > SIP mailing list > > > SIP@lists.bell-labs.com > > > http://lists.bell-labs.com/mailman/listinfo/sip --------------B66E35DE06E8A3AD3472B6EE Content-Type: text/x-vcard; charset=us-ascii; name="christer.holmberg.vcf" Content-Description: Card for Christer Holmberg Content-Disposition: attachment; filename="christer.holmberg.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Holmberg;Christer tel;cell:+358-40-5604412 tel;work:+358-9-2992943 x-mozilla-html:FALSE org:Ericsson;Advanced Signalling Research Laboratory adr:;;;;;; version:2.1 email;internet:christer.holmberg@lmf.ericsson.se title:System Designer fn:Christer Holmberg end:vcard --------------B66E35DE06E8A3AD3472B6EE-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 17 16:36:07 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA20695 for ; Tue, 17 Oct 2000 16:36:06 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8B54A44341; Tue, 17 Oct 2000 15:36:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cisco.com (bounty.cisco.com [161.44.3.204]) by lists.bell-labs.com (Postfix) with ESMTP id 9434F4433F for ; Tue, 17 Oct 2000 15:35:52 -0400 (EDT) Received: from cisco.com (blanc.cisco.com [161.44.3.203]) by cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id QAA26218; Tue, 17 Oct 2000 16:35:34 -0400 (EDT) Message-ID: <39ECB80C.53F661F1@cisco.com> From: Bryan Byerly X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Christer Holmberg Cc: sip@lists.bell-labs.com, byerly@cisco.com, stlevy@cisco.com, jryang@cisco.com Subject: Re: [SIP] From header to ISUP CgPN mapping References: <39EB69C3.4A7F24C@lmf.ericsson.se> <39EC89F4.CACDCD09@cisco.com> <39ECB2ED.ECCE60A8@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 17 Oct 2000 16:35:25 -0400 Content-Transfer-Encoding: 7bit ok. Thanks for clearing that up. A follow-up question: How does/does Also-From header differ from the Remote-Party-Id header (draft-dcsgroup-sip-privacy-02.txt)? Thanks for your help! Bryan Christer Holmberg wrote: > Hi, > > Using the Diversion header, you can inform an endpoint of which > Request-URIs have been used before the Request-URI of that specific > endpoint was used. > > The case I am talking about, however, is when we can insert an "alias" > header for the From header, using a telephone number, if the From header > is, for example, an e-mail address. Using this new header, let us call > is Also-From, a proxy (or the calling endpoint itself) may also insert a > telephone number, which can then be used by PSTN Gateways for any kind > of A-number analysing. One could argue that the caller should always > include a telephone number in the From header, but the caller may not > know that the call will end up on the PSTN side, so... > > I DO like the Diversion draft very much, though, but it doesn't solve > this specific problem :) > > Regards, > > Christer Holmberg > Ericsson Finland > > Bryan Byerly wrote: > > > > Hi guys, > > > > What do you guys think about using the Diversion header > > (http://www.ietf.org/internet-drafts/draft-levy-sip-diversion-00.txt) instead of > > Also-From? > > It seems like a natural replacement to me. > > > > Thanks! > > Bryan > > > > Christer Holmberg wrote: > > > > > Hi, > > > > > > This is something I've also been looking into. > > > > > > One way would be to add a new header (e.g. Also-From). That header could > > > be inserted by a proxy that does know the request may end up in a > > > gateway. The UA may not know that, so he could put whatever string in > > > the user part of the From header (e.g. his e-mail address). If the proxy > > > then knows the UAs telephone number, for example by using some kind of > > > database lookup, which is needed by the gateway - for any possible > > > A-number procedure - the proxy can add that to the request. > > > > > > Another way would be to just define a URI parameter for the From header, > > > but the bad thing about that is that it can not be inserted by a proxy > > > if it was not in the request from the UA (since the From header must not > > > be changed) by a proxy, or any other intermediate node. > > > > > > Note, that this response is according to Clive's mail. I do NOT support > > > the idea of ALSO-TO headers, multiple FROM/TO headers and whatever was > > > proposed in the previous mails :) > > > > > > Regards, > > > > > > Christer Holmberg > > > Ericsson Finland > > > > > > clive.dellard@bt.com wrote: > > > > > > > > I agree with what you say, however, if you consider a call originating from > > > > a SIP device (telephone or softphone) that ends up going through a gateway > > > > to the PSTN then it is a different story. > > > > Neither the user or the UAC can know where a call will end up, therefore the > > > > ability to be able to provide both SIP address and SIP Telephone number > > > > would be useful to providing a complete service as then an appropriate > > > > calling address is available wherever the call ends up. In the scenario I > > > > described the gateway could chose the Telephone number (ok I know there are > > > > verification issues but that's another story). > > > > Something like Simon's idea of an "ALSO-FROM" seems a good idea to me (this > > > > is similar to "two number delivery" in the ISDN CLIP service) older versions > > > > would just ignore the ALSO-FROM and it wouldn't affect the significance of > > > > the FROM and TO headers. > > > > > > > > Clive > > > > > > > > > -----Original Message----- > > > > > From: Jonathan Rosenberg [SMTP:jdrosen@dynamicsoft.com] > > > > > Sent: Wednesday, October 11, 2000 7:41 PM > > > > > To: 'clive.dellard@bt.com'; 'sip@lists.bell-labs.com' > > > > > Subject: RE: [SIP] From header to ISUP CgPN mapping > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: clive.dellard@bt.com [mailto:clive.dellard@bt.com] > > > > > > Sent: Wednesday, October 11, 2000 12:17 PM > > > > > > To: sip@lists.bell-labs.com > > > > > > Subject: [SIP] From header to ISUP CgPN mapping > > > > > > > > > > > > > > > > > > In the call flows document draft-ietf-sip-call-flows-01.txt, > > > > > > scenario 4.1.1, > > > > > > the message detail and text show User A using a SIP telephone > > > > > > number rather > > > > > > than a SIP address in the From header. The text at the > > > > > > beginning of section > > > > > > 4 also says "that User A still uses his/her SIP URL in the > > > > > > Contact header, > > > > > > since the call could be redirected back to the SIP network." > > > > > > This implies that User A has pre-knowledge that the call is > > > > > > going to route > > > > > > to the PSTN and has the ability to chose the address to be > > > > > > used in the From > > > > > > header. > > > > > > > > > > No. > > > > > > > > > > The From header is the logical identity of the user making the call. Since > > > > > the call is coming through a gateway, that user is some user on a PSTN > > > > > terminal somewhere. The identity in this case can either be a tel URL, or > > > > > a > > > > > SIP URL at the domain of the originating network. > > > > > > > > > > The Contact is used for signaling addressing. Its not a logical > > > > > identifier. > > > > > It answers the question "where should I send SIP messages to for the rest > > > > > of > > > > > this call". The SIP spec says this is supposed to be a SIP URL preferably > > > > > with a complete hostname, so that there are no ambiguities about where to > > > > > send requests. > > > > > > > > > > Neither of these have anything to do with knowing where the call is going. > > > > > > > > > > -Jonathan R. > > > > > > > > > > --- > > > > > Jonathan D. Rosenberg 72 Eagle Rock Ave. > > > > > Chief Scientist First Floor > > > > > dynamicsoft East Hanover, NJ 07936 > > > > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > > > > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > > > > > http://www.dynamicsoft.com > > > > > > > > _______________________________________________ > > > > SIP mailing list > > > > SIP@lists.bell-labs.com > > > > http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 17 17:01:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA21280 for ; Tue, 17 Oct 2000 17:01:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 64C3A44346; Tue, 17 Oct 2000 16:01:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lists.bell-labs.com (Postfix) with ESMTP id 2EE9944341 for ; Tue, 17 Oct 2000 16:00:50 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id e9HL0ft21365; Tue, 17 Oct 2000 23:00:45 +0200 (MEST) 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 AAA00041; Wed, 18 Oct 2000 00:00:40 +0300 (EET DST) Received: from lmf.ericsson.se (E005004B52C74-udp424598.lmf.ericsson.se [131.160.106.10]) by greymse1.lmf.ericsson.se (8.9.3 (PHNE_18979)/8.8.6) with ESMTP id AAA14278; Wed, 18 Oct 2000 00:00:37 +0300 (EETDST) Message-ID: <39ECBDEC.8919464B@lmf.ericsson.se> From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Cc: Bryan Byerly , stlevy@cisco.com, jryang@cisco.com Subject: Re: [SIP] From header to ISUP CgPN mapping References: <39EB69C3.4A7F24C@lmf.ericsson.se> <39EC89F4.CACDCD09@cisco.com> <39ECB2ED.ECCE60A8@lmf.ericsson.se> <39ECB80C.53F661F1@cisco.com> Content-Type: multipart/mixed; boundary="------------C90C8B46E5E0DC796CBBDAEC" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 18 Oct 2000 00:00:28 +0300 This is a multi-part message in MIME format. --------------C90C8B46E5E0DC796CBBDAEC Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, >ok. Thanks for clearing that up. > >A follow-up question: >How does/does Also-From header differ from the Remote-Party-Id header >(draft-dcsgroup-sip-privacy-02.txt)? Well, it could perhaps be possible to use that header, but the whole concept of that draft is a little different than just adding an telephone number alias to the caller, and by supporting it I guess you would have to do more implementation than necessary for this specfic need. Also, depending on what is put in Remote-Party-Id header, it is not even sure it would solve the problem. Regards, Christer Holmberg Ericsson Finland > Thanks for your help! > Bryan > > Christer Holmberg wrote: > > > Hi, > > > > Using the Diversion header, you can inform an endpoint of which > > Request-URIs have been used before the Request-URI of that specific > > endpoint was used. > > > > The case I am talking about, however, is when we can insert an "alias" > > header for the From header, using a telephone number, if the From header > > is, for example, an e-mail address. Using this new header, let us call > > is Also-From, a proxy (or the calling endpoint itself) may also insert a > > telephone number, which can then be used by PSTN Gateways for any kind > > of A-number analysing. One could argue that the caller should always > > include a telephone number in the From header, but the caller may not > > know that the call will end up on the PSTN side, so... > > > > I DO like the Diversion draft very much, though, but it doesn't solve > > this specific problem :) > > > > Regards, > > > > Christer Holmberg > > Ericsson Finland > > > > Bryan Byerly wrote: > > > > > > Hi guys, > > > > > > What do you guys think about using the Diversion header > > > (http://www.ietf.org/internet-drafts/draft-levy-sip-diversion-00.txt) instead of > > > Also-From? > > > It seems like a natural replacement to me. > > > > > > Thanks! > > > Bryan > > > > > > Christer Holmberg wrote: > > > > > > > Hi, > > > > > > > > This is something I've also been looking into. > > > > > > > > One way would be to add a new header (e.g. Also-From). That header could > > > > be inserted by a proxy that does know the request may end up in a > > > > gateway. The UA may not know that, so he could put whatever string in > > > > the user part of the From header (e.g. his e-mail address). If the proxy > > > > then knows the UAs telephone number, for example by using some kind of > > > > database lookup, which is needed by the gateway - for any possible > > > > A-number procedure - the proxy can add that to the request. > > > > > > > > Another way would be to just define a URI parameter for the From header, > > > > but the bad thing about that is that it can not be inserted by a proxy > > > > if it was not in the request from the UA (since the From header must not > > > > be changed) by a proxy, or any other intermediate node. > > > > > > > > Note, that this response is according to Clive's mail. I do NOT support > > > > the idea of ALSO-TO headers, multiple FROM/TO headers and whatever was > > > > proposed in the previous mails :) > > > > > > > > Regards, > > > > > > > > Christer Holmberg > > > > Ericsson Finland > > > > > > > > clive.dellard@bt.com wrote: > > > > > > > > > > I agree with what you say, however, if you consider a call originating from > > > > > a SIP device (telephone or softphone) that ends up going through a gateway > > > > > to the PSTN then it is a different story. > > > > > Neither the user or the UAC can know where a call will end up, therefore the > > > > > ability to be able to provide both SIP address and SIP Telephone number > > > > > would be useful to providing a complete service as then an appropriate > > > > > calling address is available wherever the call ends up. In the scenario I > > > > > described the gateway could chose the Telephone number (ok I know there are > > > > > verification issues but that's another story). > > > > > Something like Simon's idea of an "ALSO-FROM" seems a good idea to me (this > > > > > is similar to "two number delivery" in the ISDN CLIP service) older versions > > > > > would just ignore the ALSO-FROM and it wouldn't affect the significance of > > > > > the FROM and TO headers. > > > > > > > > > > Clive > > > > > > > > > > > -----Original Message----- > > > > > > From: Jonathan Rosenberg [SMTP:jdrosen@dynamicsoft.com] > > > > > > Sent: Wednesday, October 11, 2000 7:41 PM > > > > > > To: 'clive.dellard@bt.com'; 'sip@lists.bell-labs.com' > > > > > > Subject: RE: [SIP] From header to ISUP CgPN mapping > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: clive.dellard@bt.com [mailto:clive.dellard@bt.com] > > > > > > > Sent: Wednesday, October 11, 2000 12:17 PM > > > > > > > To: sip@lists.bell-labs.com > > > > > > > Subject: [SIP] From header to ISUP CgPN mapping > > > > > > > > > > > > > > > > > > > > > In the call flows document draft-ietf-sip-call-flows-01.txt, > > > > > > > scenario 4.1.1, > > > > > > > the message detail and text show User A using a SIP telephone > > > > > > > number rather > > > > > > > than a SIP address in the From header. The text at the > > > > > > > beginning of section > > > > > > > 4 also says "that User A still uses his/her SIP URL in the > > > > > > > Contact header, > > > > > > > since the call could be redirected back to the SIP network." > > > > > > > This implies that User A has pre-knowledge that the call is > > > > > > > going to route > > > > > > > to the PSTN and has the ability to chose the address to be > > > > > > > used in the From > > > > > > > header. > > > > > > > > > > > > No. > > > > > > > > > > > > The From header is the logical identity of the user making the call. Since > > > > > > the call is coming through a gateway, that user is some user on a PSTN > > > > > > terminal somewhere. The identity in this case can either be a tel URL, or > > > > > > a > > > > > > SIP URL at the domain of the originating network. > > > > > > > > > > > > The Contact is used for signaling addressing. Its not a logical > > > > > > identifier. > > > > > > It answers the question "where should I send SIP messages to for the rest > > > > > > of > > > > > > this call". The SIP spec says this is supposed to be a SIP URL preferably > > > > > > with a complete hostname, so that there are no ambiguities about where to > > > > > > send requests. > > > > > > > > > > > > Neither of these have anything to do with knowing where the call is going. > > > > > > > > > > > > -Jonathan R. > > > > > > > > > > > > --- > > > > > > Jonathan D. Rosenberg 72 Eagle Rock Ave. > > > > > > Chief Scientist First Floor > > > > > > dynamicsoft East Hanover, NJ 07936 > > > > > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > > > > > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > > > > > > http://www.dynamicsoft.com > > > > > > > > > > _______________________________________________ > > > > > SIP mailing list > > > > > SIP@lists.bell-labs.com > > > > > http://lists.bell-labs.com/mailman/listinfo/sip --------------C90C8B46E5E0DC796CBBDAEC Content-Type: text/x-vcard; charset=us-ascii; name="christer.holmberg.vcf" Content-Description: Card for Christer Holmberg Content-Disposition: attachment; filename="christer.holmberg.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Holmberg;Christer tel;cell:+358-40-5604412 tel;work:+358-9-2992943 x-mozilla-html:FALSE org:Ericsson;Advanced Signalling Research Laboratory adr:;;;;;; version:2.1 email;internet:christer.holmberg@lmf.ericsson.se title:System Designer fn:Christer Holmberg end:vcard --------------C90C8B46E5E0DC796CBBDAEC-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 17 17:35:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA21605 for ; Tue, 17 Oct 2000 17:35:04 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9E05144338; Tue, 17 Oct 2000 16:35:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lists.bell-labs.com (Postfix) with ESMTP id 7A65F44336 for ; Tue, 17 Oct 2000 16:34:41 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id e9HLYat25354 for ; Tue, 17 Oct 2000 23:34:36 +0200 (MEST) 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 AAA01224 for ; Wed, 18 Oct 2000 00:34:35 +0300 (EET DST) Received: from lmf.ericsson.se (E005004B52C74-udp424598.lmf.ericsson.se [131.160.106.10]) by greymse1.lmf.ericsson.se (8.9.3 (PHNE_18979)/8.8.6) with ESMTP id AAA16799 for ; Wed, 18 Oct 2000 00:34:34 +0300 (EETDST) Message-ID: <39ECC5E9.793C1179@lmf.ericsson.se> From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Content-Type: multipart/mixed; boundary="------------9D2BEE50C05CB9BB89893CEC" Subject: [SIP] Question on SIP Caller Preferences draft Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 18 Oct 2000 00:34:33 +0300 This is a multi-part message in MIME format. --------------9D2BEE50C05CB9BB89893CEC Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, I would like to clarify one issue in the SIP Caller Preferences draft (draft-ietf-sip-callerprefs-02.txt). The case is when I talk to a SIP server acting as both proxy and redirect. I want it to be able to send me 3xx responses ("redirect"), and I want it to be able to act like a proxy ("proxy"). Also, if it forks a request, and receives a 3xx response, I want it to be forwarded back to me ("no-recurse"). The draft says (chapter 5.5 Request-Disposition) that the recurese-feature is ignored if redirect has been requested, so I can not use the following header: Request-Disposition: proxy, redirect, no-recurse Should I instead use two different headers in the message? I.e.: Request-Disposition: proxy, no-recurse Request-Disposition: redirect (Note: I left the parallel- and fork-feature from the example on purpose) Regards, Christer Holmberg Ericsson Finland --------------9D2BEE50C05CB9BB89893CEC Content-Type: text/x-vcard; charset=us-ascii; name="christer.holmberg.vcf" Content-Description: Card for Christer Holmberg Content-Disposition: attachment; filename="christer.holmberg.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Holmberg;Christer tel;cell:+358-40-5604412 tel;work:+358-9-2992943 x-mozilla-html:FALSE org:Ericsson;Advanced Signalling Research Laboratory adr:;;;;;; version:2.1 email;internet:christer.holmberg@lmf.ericsson.se title:System Designer fn:Christer Holmberg end:vcard --------------9D2BEE50C05CB9BB89893CEC-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 17 17:47:00 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA21694 for ; Tue, 17 Oct 2000 17:47:00 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6F87044338; Tue, 17 Oct 2000 16:47:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cvis29.marconicomms.com (cvis29.marconicomms.com [195.99.244.61]) by lists.bell-labs.com (Postfix) with ESMTP id 43DEF44336 for ; Tue, 17 Oct 2000 16:46:08 -0400 (EDT) Received: from cvis01.gpt.co.uk (unverified) by cvis29.marconicomms.com (Content Technologies SMTPRS 4.1.5) with ESMTP id ; Tue, 17 Oct 2000 16:49:24 +0100 Received: from marconicomms.com by cvis01.gpt.co.uk with SMTP (8.8.8+Sun/cvms-28) id QAA13682; Tue, 17 Oct 2000 16:48:54 +0100 (BST) Received: by marconicomms.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 8025697B.0056D7B4 ; Tue, 17 Oct 2000 16:48:33 +0100 X-Lotus-FromDomain: MCMAIN@MCEXT From: "Keith Robinson" To: Jonathan Rosenberg Cc: "'Brett Tate'" , "'Neil Deason'" , "'sip-implementors@cs.columbia.edu'" , "'sip@lists.bell-labs.com'" Message-ID: <8025697B.0056D145.00@marconicomms.com> Subject: RE: [SIP] Incorrect behaviour when using a local outbound proxy Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 17 Oct 2000 16:48:25 +0100 I think the SIP spec (bis-02) is ambiguous on the contents of the Request-URI which has (will) lead to different implementations; in section 2, the following is written : "SIP URLs are used within SIP messages to indicate the originator (From), current destination (Request-URI) .............." and in section 4.3 the following is written : "It [Request-URI] indicates the user or service to which this request is being addressed" From the point of view of a UA, the current destination may be a very different thing from the user or service being addressed. Using the current destination definition, a UA may well put the address of the local outbound proxy into the Request-URI, using the definition as per 4.3 would lead them to putting in the logical identity of the user (or service). When refering to current destination, does it mean the next hop destination or the current logical destination ? Thanks, Keith Robinson. Jonathan Rosenberg on 13/10/2000 22:17:46 To: "'Brett Tate'" , "'Neil Deason'" cc: "'sip-implementors@cs.columbia.edu'" , "'sip@lists.bell-labs.com'" (bcc: Keith Robinson/MAIN/MC1) Subject: RE: [SIP] Incorrect behaviour when using a local outbound proxy > -----Original Message----- > From: Brett Tate [mailto:brett@broadsoft.com] > Sent: Friday, October 13, 2000 12:32 PM > To: Neil Deason > Cc: sip-implementors@cs.columbia.edu; sip@lists.bell-labs.com > Subject: Re: [SIP] Incorrect behaviour when using a local > outbound proxy > > > > > > In testing labs I am seeing a worrying number of UA > > > > implementations making the same mistake of sending requests > > > > to a Proxy where the Request-URI is in the form > > > > sip:user@. I think some of the confusion may > > > > be traced back to early SIP message flows which showed this > > > > behaviour. I urge implementers to rectify this situation as > > > > we are seeing this cause a great deal of confusion to > > > > the first commercial adopters of SIP technology. These people > > > > are not SIP protocol experts and just expect this technology > > > > to work. > > > > > > > > It is often seen when using a local out bound proxy. The > > > > situation is that the UA takes a configuration parameter > > > > for the local proxy. You can then dial by keying in just the > > > > user part of a SIP URL. The UA then builds a complete URL by > > > > adding the Proxy's address and sends the message to the proxy. > > > > The Proxy then receives an INVITE of the form > > > > sip:user@proxy-ip - according to the protocol spec the Proxy > > > > will route this request to the server at the given IP address. > > > > This is obviously itself so an illegal loop is created. A > > > > > > An outbound proxy for userA can be configured > > > to translate upon a received outgoing message > > > from known userA however it wishes. UserA > > > dialing *69 on a phone can be sent to outbound > > > proxy with Request-URI of *69@outboundProxy-Ip. > > > Assuming the outbound proxy knows userA, it can > > > change the Request-URI into the last "known" > > > user@host that called userA. > > > > According to the SIP spec sip:*69@outboundProxy-Ip > > does not map onto the last incoming caller's sip URL > > this is specialised logic. It may exist but a truly > > interoperable UA must still be able to work if it > > doesn't. > > > > The point I was really trying to make is that a UA > > should not write Request-URIs out to be the destination > > of where they are being sent in the hostport when using > > a local outbound proxy. > > > > Say I want to dial sip:jsmith@another-domain.com but > > the UA configured with a local outbound proxy setting > > of proxy.this-domain.com actually sends the INVITE > > out as:- > > > > INVITE sip:jsmith@proxy.this-domain.com SIP/2.0 > > To: sip:jsmith@another-domain.com > > From: sip:PoorUser@this-domain.com > > .... > > > > A proxy receiving the above request assumes > that the user is trying to reach the Request-URI. > By becoming aware the need to act as an > outbound proxy, the Request-URI can be changed > by the outbound proxy. When any proxy or user > agent receives the initial INVITE, the user@hostport > of "To" should only really mean what was supposedly > dialed/entered to reach you (and call-leg identification). > > If the user agent was trying to reach > sip:jsmith@another-domain.com, > it should be in the Request-URI. And the > message should be sent to > proxy.this-domain.com if it wants to use it > as an outbound proxy. There are two cases here that are being intermixed. In case one, the originating UA wants to reach a user with a specific username AND domain name, and that domain name is totally outside the network of the originating UA. For example, if I want to reach joe@foo.com, and I'm within bar.com. In case two, I'm on a gateway and I dial a number. There is not really a destination domain associated with this number. What should it be? In case one, it is absolutely INCORRECT to modify the request URI to be my local domain. When sending the request to my local proxy, it would look like: INVITE sip:joe@foo.com SIP/2.0 and then be sent NOT to foo.com, but to my local proxy. Changing the request URI to bar.com to reach the local proxy is an error; user joe is not within that namespace. However, in case two, the destination number can rightly be considered to be within the domain of the orginating caller. Thats because it knows how to reach phone numbers. Remember, just because a proxy for bar.com gets a request with a URI thats some-name@bar.com, does not mean a user some-name must have registered with a REGISTER. It means that the proxy for bar.com knows what to do with the user some-name. Its perfectly fine for this proxy to treat numbers in the user part of its domain as telephone numbers, especially if they are indicated as such with user=phone, and then route them to a gateway with some phone routing database. So, in that case, if I'm in bar.com, and I dial a number - 5551212, its reasonable to send that to my own proxy with the URI 5551212@bar.com. In this case its not even really a local-outbound proxy anymore. Using the IP address of the proxy is also OK IFF the proxy is configured to know that requests with that given IP address represent "its domain of ownership". Using the domain name is better for lots of reasons, though, including SRV usage. Whether this is allowed is a matter of configuration. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 17 18:03:00 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA21835 for ; Tue, 17 Oct 2000 18:03:00 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4ED0144340; Tue, 17 Oct 2000 17:03:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 5A49044336 for ; Tue, 17 Oct 2000 17:02:52 -0400 (EDT) Received: from athletics ([63.110.3.179]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with SMTP id SAA21234; Tue, 17 Oct 2000 18:04:56 -0400 (EDT) From: "Steve Donovan" To: "Christer Holmberg" , Cc: "hammer michael" Subject: RE: [SIP] Session-timer with INFO 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.50.4133.2400 In-Reply-To: <39ECABD9.75B6EE66@lmf.ericsson.se> Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 17 Oct 2000 17:58:59 -0400 Content-Transfer-Encoding: 7bit > -----Original Message----- > From: sip-admin@lists.bell-labs.com > [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Christer Holmberg > Sent: Tuesday, October 17, 2000 3:43 PM > To: sip@lists.bell-labs.com > Cc: hammer michael > Subject: Re: [SIP] Session-timer with INFO > > > > Hi, > > >Thus you are in support of not trying to implicitly use a method > to do >what a subordinate capability should be explicitly defined to do? > > I didn't say that. Of course it is nice if we can > get-two-things-by-doing-one, but in this case I just see some issues. > Again, first there is the thing that by using re-INVITEs we will > generate ACKs. > > Second, which I think is related to your mail, is when the UAS boots, > and the re-INVITE is seen as a new INVITE to establish a new session. We > may get 18x responses before the final response, and the final response > can be a 3xx, 4xx, 5xx or 6xx response, and in some cases it may be very > difficult for the UAC to behave in a good way. If we use INFO, and > receive 481, the UAS knows that the session doesn't exist anymore, and > can do whatever is needed, and then, if wanted, send a new INVITE to > re-establish the call. It gives the UAC more control, and the UAC may, > for some reason, even want to know if a session died. I don't believe this is the scenario that is addressed by the goal of being able to re-establish the session. Remember that the entity managing the SIP session information and the entity participating in the RTP session do not need to be the same machine. So the scenario is that the SIP UAS has lost track of the SIP state related of an RTP session, but the RTP session is still active. The re-INVITE would allow the SIP UAS to re-establish SIP state for the session without a new call being set up. In this scenario, it would not send 18x, 3xx, 4xx, 5xx or 6xx responses. While it is true that there are other ways that this could have been solved, it is pretty late in the game to make this kind of a change. Especially if the only reason for doing so is to avoid the ACK message. As a side note, we are in the process of creating a new version of the draft that we hope will be used for working group last call. Steve _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 17 18:17:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA21907 for ; Tue, 17 Oct 2000 18:17:00 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3C9C544351; Tue, 17 Oct 2000 17:17:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from elektron.elka.pw.edu.pl (elektron.elka.pw.edu.pl [194.29.160.2]) by lists.bell-labs.com (Postfix) with ESMTP id 21CF444340 for ; Tue, 17 Oct 2000 17:16:51 -0400 (EDT) Received: from dial-barska53.warman.com.pl ([195.164.232.54]:2183 "EHLO elka.pw.edu.pl") by elektron.elka.pw.edu.pl with ESMTP id ; Wed, 18 Oct 2000 00:16:32 +0200 Message-ID: <39ECCF76.985AAFF@elka.pw.edu.pl> From: "Piotr S. Kossowski" Organization: Warsaw University of Technology - Institute of Telecommunications X-Mailer: Mozilla 4.7 [pl] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] Destination addresses in Via/Contact Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 18 Oct 2000 00:15:18 +0200 Content-Transfer-Encoding: 7bit Hello, After studying of Via and Contact description in RFC-2543, My thinking about these headers is not fully clear (My apologies, if it is basic question). So, please someone to explain if something below is wrong: Let's imagine an INVITE sent from UAC directly to UAS that contain (amongst others): Via: SIP/2.0/UDP wonderland.com:6000 Contact: alice@wonderland.com:5080 After getting that INVITE by UAS, UAS should send a response to UDP socket 6000 on wonderland.com host. This "wonderland.com:6000" destination is valid only for this single request from UAC. In next requests (e.g. re-INVITE or BYE) UAC can put in Via not the same data, for example "new" 6001 port. As I figured out, Contact has no influence on destination of response. Port 5080 on wonderland.com host will be used only if UAS (callee) would like to send some request (e.g. BYE) to UAC (caller) during this call. Is that true ? Regards, Piotr PS BTW (For Henning, I suppose): There is incorrect year of expiration on the first side of rfc2354bis-02... _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 17 18:56:07 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA22262 for ; Tue, 17 Oct 2000 18:56:04 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 24B2144338; Tue, 17 Oct 2000 17:56:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from broadsoft.com (broadsoft.com [161.58.239.68]) by lists.bell-labs.com (Postfix) with ESMTP id 353E644336 for ; Tue, 17 Oct 2000 17:55:38 -0400 (EDT) Received: from tate ([216.181.56.35]) by broadsoft.com (8.8.8) id SAA92547; Tue, 17 Oct 2000 18:55:33 -0400 (EDT) Message-ID: <0e7d01c0388d$8ba56370$3202a8c0@broadsoft.com> From: "Brett Tate" To: References: Subject: Re: [SIP] Session-timer with INFO 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: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 17 Oct 2000 18:56:54 -0400 Content-Transfer-Encoding: 7bit > While it is true that there are other ways that this could have been solved, > it is pretty late in the game to make this kind of a change. Especially if > the only reason for doing so is to avoid the ACK message. Other reasons include the desire not to revive a dead session and to avoid the possibility of a new SDP in the 200 response. > > As a side note, we are in the process of creating a new version of the draft > that we hope will be used for working group last call. Steve, Can a header or parameter be defined within the sip-session-timer to indicate that the sender is just trying to extend the Session-Timer and check session state, but the sender does NOT want the session revived if it is down? The reverse of the boolean value could indicate a request to revive the session if it is down. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 17 20:24:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA23527 for ; Tue, 17 Oct 2000 20:24:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 88BBF44345; Tue, 17 Oct 2000 19:24:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sj_exchange.sj.nuera.com (h-207-20-110-62.ncal.verio.net [207.20.110.62]) by lists.bell-labs.com (Postfix) with ESMTP id F2AAB44338 for ; Tue, 17 Oct 2000 19:23:14 -0400 (EDT) Received: by exchange.sj.nuera.com with Internet Mail Service (5.5.2650.21) id <4C7KR5JK>; Tue, 17 Oct 2000 17:23:10 -0700 Message-ID: <350860CC5B2AD311991D0008C7F7EEAAA02659@exchange.sj.nuera.com> From: "Emami-Nouri, Mohsen" To: "'Piotr S. Kossowski'" , sip@lists.bell-labs.com Subject: RE: [SIP] Destination addresses in Via/Contact MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 17 Oct 2000 17:23:09 -0700 -----Original Message----- From: Piotr S. Kossowski [mailto:P.Kossowski@elka.pw.edu.pl] Sent: Tuesday, October 17, 2000 3:15 PM To: sip@lists.bell-labs.com Subject: [SIP] Destination addresses in Via/Contact Hello, After studying of Via and Contact description in RFC-2543, My thinking about these headers is not fully clear (My apologies, if it is basic question). So, please someone to explain if something below is wrong: Let's imagine an INVITE sent from UAC directly to UAS that contain (amongst others): Via: SIP/2.0/UDP wonderland.com:6000 Contact: alice@wonderland.com:5080 After getting that INVITE by UAS, UAS should send a response to UDP socket 6000 on wonderland.com host. This "wonderland.com:6000" destination is valid only for this single request from UAC. In next requests (e.g. re-INVITE or BYE) UAC can put in Via not the same data, for example "new" 6001 port. As I figured out, Contact has no influence on destination of response. Port 5080 on wonderland.com host will be used only if UAS (callee) would like to send some request (e.g. BYE) to UAC (caller) during this call. Is that true ? >>>that would be my interpretation too. Regards, Piotr PS BTW (For Henning, I suppose): There is incorrect year of expiration on the first side of rfc2354bis-02... _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 17 20:36:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA23761 for ; Tue, 17 Oct 2000 20:36:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 92B4244351; Tue, 17 Oct 2000 19:36:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id EED564434D for ; Tue, 17 Oct 2000 19:35:21 -0400 (EDT) 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 UAA12990; Tue, 17 Oct 2000 20:34:50 -0400 (EDT) Message-ID: <39ECF02B.6D4AF522@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Keith Robinson Cc: Jonathan Rosenberg , "'Brett Tate'" , "'Neil Deason'" , "'sip-implementors@cs.columbia.edu'" , "'sip@lists.bell-labs.com'" Subject: Re: [SIP] Incorrect behaviour when using a local outbound proxy References: <8025697B.0056D145.00@marconicomms.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 17 Oct 2000 20:34:51 -0400 Content-Transfer-Encoding: 7bit Keith Robinson wrote: > > I think the SIP spec (bis-02) is ambiguous on the contents of the Request-URI > which has (will) lead to different implementations; in section 2, the following > is written : > > "SIP URLs are used within SIP messages to indicate the originator (From), > current destination (Request-URI) .............." > > and in section 4.3 the following is written : > > "It [Request-URI] indicates the user or service to which this request is being > addressed" > > >From the point of view of a UA, the current destination may be a very different > thing from the user or service being addressed. Using the current destination > definition, a UA may well put the address of the local outbound proxy into the > Request-URI, using the definition as per 4.3 would lead them to putting in the > logical identity of the user (or service). > > When refering to current destination, does it mean the next hop destination or > the current logical destination ? Current SIP destination. The outbound proxy is by definition not a SIP destination (with its own SIP URL). Thus, putting its address in the request URI makes no sense. I would prefer not to introduce yet another term ("logical destination"), as this increases complexity. The definition of the outbound proxy is that it differs from the Request-URI address, so I'm not sure how much confusion there can be. (If you stick the address of the proxy in the request-URI, it's no longer an outbound proxy.) -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 18 01:54:06 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA05805 for ; Wed, 18 Oct 2000 01:54:06 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 190C644338; Wed, 18 Oct 2000 00:54:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lists.bell-labs.com (Postfix) with ESMTP id 2919244336 for ; Wed, 18 Oct 2000 00:53:52 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id e9I5riZ23004; Wed, 18 Oct 2000 07:53:45 +0200 (MEST) 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 IAA15556; Wed, 18 Oct 2000 08:53:41 +0300 (EET DST) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.73]) by greymse1.lmf.ericsson.se (8.9.3 (PHNE_18979)/8.8.6) with ESMTP id IAA03327; Wed, 18 Oct 2000 08:53:37 +0300 (EETDST) Message-ID: <39ED3ADF.53946083@lmf.ericsson.se> From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Cc: Steve Donovan , hammer michael Subject: Re: [SIP] Session-timer with INFO References: Content-Type: multipart/mixed; boundary="------------A07FDD6ABD3953A47E35D94F" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 18 Oct 2000 08:53:35 +0300 This is a multi-part message in MIME format. --------------A07FDD6ABD3953A47E35D94F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, >>>Thus you are in support of not trying to implicitly use a method >>>to do what a subordinate capability should be explicitly defined to do? >> >>I didn't say that. Of course it is nice if we can >>get-two-things-by-doing-one, but in this case I just see some issues. >>Again, first there is the thing that by using re-INVITEs we will >>generate ACKs. >> >>Second, which I think is related to your mail, is when the UAS boots, >>and the re-INVITE is seen as a new INVITE to establish a new session. We >>may get 18x responses before the final response, and the final response >>can be a 3xx, 4xx, 5xx or 6xx response, and in some cases it may be very >>difficult for the UAC to behave in a good way. If we use INFO, and >>receive 481, the UAS knows that the session doesn't exist anymore, and >>can do whatever is needed, and then, if wanted, send a new INVITE to >>re-establish the call. It gives the UAC more control, and the UAC may, >>for some reason, even want to know if a session died. >I don't believe this is the scenario that is addressed by the goal of >being able to re-establish the session. Remember that the entity >managing the SIP session information and the entity participating in the >RTP session do not need to be the same machine. So the scenario is that >the SIP UAS has lost track of the SIP state related of an RTP session, >but the RTP session is still active. The re-INVITE would allow the SIP >UAS to re-establish SIP state for the session without a new call being >set up. In this scenario, it would not send 18x, 3xx, 4xx, 5xx or 6xx >responses. Maybe not in this specific scenario, but it MAY happen depending of the architecture and logic of the remote party. I would like the heartbeat mechanism, and the logic to support it, to be as simple as possible, i.e. you send a request and receive a response. Then, depending on the response, the UAC can choose to do whatever he wishes to. In some systems, for example, he may choose to use another UAS, or whatever, if the session has died. >While it is true that there are other ways that this could have been >solved, it is pretty late in the game to make this kind of a change. >Especially if the only reason for doing so is to avoid the ACK message. Well, as has been discussed here, that is not the only reason, but I still think it is a good reason. >As a side note, we are in the process of creating a new version of the >draft that we hope will be used for working group last call. One option, which has been proposed, was to define a new functionality, "session ping", e.g. by using the INFO method extension. Regards, Christer Holmberg Ericsson Finland > > Steve --------------A07FDD6ABD3953A47E35D94F Content-Type: text/x-vcard; charset=us-ascii; name="christer.holmberg.vcf" Content-Description: Card for Christer Holmberg Content-Disposition: attachment; filename="christer.holmberg.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Holmberg;Christer tel;cell:+358-40-5604412 tel;work:+358-9-2992943 x-mozilla-html:FALSE org:Ericsson;Advanced Signalling Research Laboratory adr:;;;;;; version:2.1 email;internet:christer.holmberg@lmf.ericsson.se title:System Designer fn:Christer Holmberg end:vcard --------------A07FDD6ABD3953A47E35D94F-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 18 01:58:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA05817 for ; Wed, 18 Oct 2000 01:58:03 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C93F94434F; Wed, 18 Oct 2000 00:58:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lists.bell-labs.com (Postfix) with ESMTP id 79FC74434E for ; Wed, 18 Oct 2000 00:57:29 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id e9I5vOt11728; Wed, 18 Oct 2000 07:57:24 +0200 (MEST) 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 IAA15833; Wed, 18 Oct 2000 08:57:23 +0300 (EET DST) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.73]) by greymse1.lmf.ericsson.se (8.9.3 (PHNE_18979)/8.8.6) with ESMTP id IAA03929; Wed, 18 Oct 2000 08:57:22 +0300 (EETDST) Message-ID: <39ED3BC0.BE7ABCE1@lmf.ericsson.se> From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Cc: Brett Tate Subject: Re: [SIP] Session-timer with INFO References: <0e7d01c0388d$8ba56370$3202a8c0@broadsoft.com> Content-Type: multipart/mixed; boundary="------------EB490AF34149AC9C25CE9C2B" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 18 Oct 2000 08:57:20 +0300 This is a multi-part message in MIME format. --------------EB490AF34149AC9C25CE9C2B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, >>While it is true that there are other ways that this could have been >>solved, it is pretty late in the game to make this kind of a change. >>Especially if the only reason for doing so is to avoid the ACK message. >Other reasons include the desire not to revive a >dead session and to avoid the possibility of a new >SDP in the 200 response. True. Regards, Christer Holmberg Ericsson Finland >>As a side note, we are in the process of creating a new version of the >>draft that we hope will be used for working group last call. > > Steve, > > Can a header or parameter be defined within > the sip-session-timer to indicate that the sender > is just trying to extend the Session-Timer and > check session state, but the sender does NOT > want the session revived if it is down? The > reverse of the boolean value could indicate a > request to revive the session if it is down. > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip --------------EB490AF34149AC9C25CE9C2B Content-Type: text/x-vcard; charset=us-ascii; name="christer.holmberg.vcf" Content-Description: Card for Christer Holmberg Content-Disposition: attachment; filename="christer.holmberg.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Holmberg;Christer tel;cell:+358-40-5604412 tel;work:+358-9-2992943 x-mozilla-html:FALSE org:Ericsson;Advanced Signalling Research Laboratory adr:;;;;;; version:2.1 email;internet:christer.holmberg@lmf.ericsson.se title:System Designer fn:Christer Holmberg end:vcard --------------EB490AF34149AC9C25CE9C2B-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 18 03:22:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA12745 for ; Wed, 18 Oct 2000 03:22:02 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8480544338; Wed, 18 Oct 2000 02:22:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 9F88744336 for ; Wed, 18 Oct 2000 02:21:09 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id DAA23326; Wed, 18 Oct 2000 03:22:53 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <4WS2XR85>; Wed, 18 Oct 2000 03:16:56 -0400 Message-ID: From: Jonathan Rosenberg To: Christer Holmberg , sip@lists.bell-labs.com Subject: RE: [SIP] Question on SIP Caller Preferences draft MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 18 Oct 2000 03:16:47 -0400 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > Sent: Tuesday, October 17, 2000 5:35 PM > To: sip@lists.bell-labs.com > Subject: [SIP] Question on SIP Caller Preferences draft > > > > Hi, > > I would like to clarify one issue in the SIP Caller Preferences draft > (draft-ietf-sip-callerprefs-02.txt). > > The case is when I talk to a SIP server acting as both proxy and > redirect. I want it to be able to send me 3xx responses ("redirect"), > and I want it to be able to act like a proxy ("proxy"). Also, if it > forks a request, and receives a 3xx response, I want it to be > forwarded > back to me ("no-recurse"). Well, it seems if you want either proxy or redirect than you have no preference. > > The draft says (chapter 5.5 Request-Disposition) that the > recurese-feature is ignored if redirect has been requested, > so I can not > use the following header: > > Request-Disposition: proxy, redirect, no-recurse > > Should I instead use two different headers in the message? I.e.: > > Request-Disposition: proxy, no-recurse > Request-Disposition: redirect As I said, this makes no sense. You have no proxy or redirect preference; listing both provides zero information. How about just: Request-Disposition: no-recurse -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 18 03:23:09 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA12756 for ; Wed, 18 Oct 2000 03:23:09 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B2C3044359; Wed, 18 Oct 2000 02:22:14 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 5F33C44336 for ; Wed, 18 Oct 2000 02:21:39 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id DAA23393; Wed, 18 Oct 2000 03:23:44 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <4WS2XR9K>; Wed, 18 Oct 2000 03:17:47 -0400 Message-ID: From: Jonathan Rosenberg To: vkg@lucent.com, sip@lists.bell-labs.com, Jonathan Rosenberg , schulzrinne@cs.columbia.edu Cc: P.Kossowski@elka.pw.edu.pl MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] RE: CANCEL - response sequence issue (again) Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 18 Oct 2000 03:17:42 -0400 > -----Original Message----- > From: Vijay K. Gurbani [mailto:vkg@lucent.com] > Sent: Tuesday, October 17, 2000 7:49 PM > To: sip@lists.bell-labs.com; Jonathan Rosenberg; > schulzrinne@cs.columbia.edu > Cc: P.Kossowski@elka.pw.edu.pl; Vijay Gurbani > Subject: CANCEL - response sequence issue (again) > > Now, if we have a UAC (actual UAC or a virtual UAC branch on a proxy) > that's coded according to the new bis but dealing with a UAS that's > coded according to the original RFC, the order of delivery suddenly > becomes important if the UAC wants to clean state correctly. > > Consider a UAC coded to the bis spec dealing with an old UAS coded to > the RFC 2543 spec. If the UAC sends a CANCEL, it will only > get the 200 > OK (CSeq: xxx CANCEL). So, it is done with the CANCEL/200 OK > transaction. But it will never get the 487 Request > Terminated response > for it's original INVITE. The UAC will not retransmit the > INVITE (since > it got the provisional responses), leading to inconsistent > call state in > the UAC. > > I think the bis should, in section 4.2.5 stress that, "...If > the server > has not issued a final response for the original request, it > immediately > sends a 487 Request Terminated for the original request. The UAC > confirms receipt of any final response for the original request as > normal with an ACK request. CANCEL request is answered with a 200 OK > response in either case after the original transaction has completed." > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > My suggested wordings; please re-word > if needed No. Counting on order is a dangerous thing. Lets say a real final response was sent, and then a CANCEL is received (crossing the final response on the wire). The CANCEL is received, and responded to with a 200 OK. This 200 OK, and the final response to the request, are received in the opposite order at the client. The result is that the client thinks there won't be a response to the original request, even though there is. The correct solution is that you cannot *depend* on the receipt of 487 to terminate the original transaction. You need to have a timeout which, after sending CANCEL, terminates the transaction if no final response is received before some X seconds. X can be fairly small, since either you will get a final response right away (modulo some packet loss), in the case of bis proxies, or never. We have this timer set to something like 5 or 6 seconds. I do think the spec needs to talk about this. In fact, I recall that it was raised on the list previously. I would rather say: For backwards compatibility with RFC2543, UACs and proxies which generate \CANCEL \MUSTNOT assume that a 487 response to the original transaction will be received. Instead, they \SHOULD set a timer upon sending \CANCEL, and terminate the transaction if not response to the original request is received after X seconds. Now, the question is: what value for X? To deal with worst case network losses, it could be as large as 32 seconds, but that results in very slow timeouts. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 18 03:25:25 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA12768 for ; Wed, 18 Oct 2000 03:25:25 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9A7D84435E; Wed, 18 Oct 2000 02:22:23 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id AC25144336 for ; Wed, 18 Oct 2000 02:21:53 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id DAA23416; Wed, 18 Oct 2000 03:23:54 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <4WS2XR9P>; Wed, 18 Oct 2000 03:17:57 -0400 Message-ID: From: Jonathan Rosenberg To: Christer Holmberg , sip@lists.bell-labs.com Cc: Bryan Byerly , stlevy@cisco.com, jryang@cisco.com Subject: RE: [SIP] From header to ISUP CgPN mapping MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 18 Oct 2000 03:17:48 -0400 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > Sent: Tuesday, October 17, 2000 5:00 PM > To: sip@lists.bell-labs.com > Cc: Bryan Byerly; stlevy@cisco.com; jryang@cisco.com > Subject: Re: [SIP] From header to ISUP CgPN mapping > > > > Hi, > > >ok. Thanks for clearing that up. > > > >A follow-up question: > >How does/does Also-From header differ from the Remote-Party-Id header > >(draft-dcsgroup-sip-privacy-02.txt)? > > Well, it could perhaps be possible to use that header, but the whole > concept of that draft is a little different than just adding an > telephone number alias to the caller, and by supporting it I guess you > would have to do more implementation than necessary for this specfic > need. Also, depending on what is put in Remote-Party-Id header, it is > not even sure it would solve the problem. I agree. Remote-Party-ID is supposed to be an address that the network has "verified" to be the actual address of the originator. It is even stripped if verification cannot take place. THis seems a bit at odds with the desired function here. That said, I still do not understand this need for YAI (yet another identifier). This previous motivation involving the termination in the PSTN or IP network is totally bogus. At this point, I am very, very, very reluctant to add new stuff without serious justification. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 18 03:27:55 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA12779 for ; Wed, 18 Oct 2000 03:27:55 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6A80444362; Wed, 18 Oct 2000 02:22:31 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 9715844336 for ; Wed, 18 Oct 2000 02:21:57 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id DAA23406; Wed, 18 Oct 2000 03:23:54 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <4WS2XR9M>; Wed, 18 Oct 2000 03:17:57 -0400 Message-ID: From: Jonathan Rosenberg To: Brett Tate , sip@lists.bell-labs.com Subject: RE: [SIP] Session-timer with INFO MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 18 Oct 2000 03:17:47 -0400 First off, I'd like to agree with others here that this is a rehash of whats already been discussed, and decided, in the past. If we revisit every decision every few months as new people join the lists, we'll never make progress. The use of INVITE along with the SDP has numerous benefits above just the INFO approach. It allows for crash recoveries, it allows for refreshes of session state in intermediate devices, such as proxies, and it follows the soft-state model present in other similar protocols. Thus, it is more general purpose of a solution. Thats been our goal with SIP - to have fairly general purpose components that could be used to build a variety of different services. I'll agree INFO would eliminate a message, but compared to media, signaling is still negligable. We've been through that one umpteen times, and the horse is very dead. As for the question about how to make sure session timers don't keep getting resent if the UAS doesn't support them, thats easy. It would include a Require header in the request, listing "timer". If the UAS doesn't support session timer, the request is rejected (no session is setup either). Now, the UAC knows that the terminating UA doesn't support the timer. So, it can either start the session without session timer at all by sending a new INVITE with no Supported header and no Session-Expires header, give up, or do session timer anyway if the proxies want it (Supported header, no Session-Expires header). Brett also asks if the UAC can ask to not have the session revived if the UAS isn't active. The question really is, who gets to make that decision? Is it realy the UAC who should ultimately decide whether a session restart is appropriate? Since its really the UAS that needs to do it, it seems like it should be its responsibility to decide. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com > -----Original Message----- > From: Brett Tate [mailto:brett@broadsoft.com] > Sent: Tuesday, October 17, 2000 6:57 PM > To: sip@lists.bell-labs.com > Subject: Re: [SIP] Session-timer with INFO > > > > While it is true that there are other ways that this could have been > solved, > > it is pretty late in the game to make this kind of a > change. Especially > if > > the only reason for doing so is to avoid the ACK message. > > Other reasons include the desire not to revive a > dead session and to avoid the possibility of a new > SDP in the 200 response. > > > > > As a side note, we are in the process of creating a new > version of the > draft > > that we hope will be used for working group last call. > > Steve, > > Can a header or parameter be defined within > the sip-session-timer to indicate that the sender > is just trying to extend the Session-Timer and > check session state, but the sender does NOT > want the session revived if it is down? The > reverse of the boolean value could indicate a > request to revive the session if it is down. > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 18 03:30:14 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA12795 for ; Wed, 18 Oct 2000 03:30:14 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 024E744367; Wed, 18 Oct 2000 02:22:39 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id C1A6344336 for ; Wed, 18 Oct 2000 02:21:59 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id DAA23431; Wed, 18 Oct 2000 03:24:04 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <4WS2XR94>; Wed, 18 Oct 2000 03:18:07 -0400 Message-ID: From: Jonathan Rosenberg To: Joshua_Fox@vocaltec.com, sip@lists.bell-labs.com Subject: RE: [SIP] call flow: Two different media types in parallel MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 18 Oct 2000 03:18:02 -0400 I really don't understand why you would want two UAs. SIP handles fine the case where a single user has multiple media devices on different machines. Things like mbus have been designed specifically for this model. A SIP UA is a logical point for signaling; if you want two devices to be in-sync as one logical point, why not make them one instead of two? -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com > -----Original Message----- > From: Joshua_Fox@vocaltec.com [mailto:Joshua_Fox@vocaltec.com] > Sent: Thursday, October 12, 2000 3:40 AM > To: sip@lists.bell-labs.com > Subject: [SIP] call flow: Two different media types in parallel > > > Thanks to SIP-list readers for answering my questions, which > I hope are not > too newbie-ish. > > Here is a call flow question. I did not see this discussed in > the FAQ or > call-flow examples, > but if I missed it, could you please point me to the right URL. > > Say that two humans--the omnipresent Alice and Bob of cryptography > fame--have two SIP-enabled > UA's each. The UA's may be two apps running on one computer, > or an app on a > computer and > on a handheld embedded-SIP device. The two devices > communicate on different > media--say one > is audio-only and the other video-only, or one is audio-video and the > other text-chat. Part of this > call flow is that each person uses two independent SIP > implementations--this is not one SIP UA controlling > two media types, but rather two SIP UA's controlling two media types. > > Alice wants to push one and only one button and initiate simultaneous > parallel channels on two separate media. > > What is the correct call flow? Does Alice's UA1 INVITE three other > UA's--Alice's UA2, > Bob's UA1, and Bob's UA2--to a four-way session (using SDP to > distinguish the two channels)? If this is a case where Alice's UA1 and > Alice's UA2 can > communicate easily using a non-SIP protocol--say they are two > apps on the > same computer, > and inter-process communication is possible--should that be > done first, > rather than attempting > a SIP 4-way session? If so, then should the same thing be > done of the other > side--only one of > Bob's UA's is initially invited, and this UA then INVITEs or otherwise > brings Bob's other UA into the session? > > Or should Alice's initial INVITE from her UA1 be forked to > both of Bob's > UA's > (a forking proxy typically forks to find which one of several > choices is > valid, but it could be asked to return > more than one) and if so, what about Alice's UA2? In any of > these cases, > does Alice's UA1 have to be > "told" about her UA2, or should a automated discovery process be built > using REGISTER? > > I guess that both of each person's UAs would have the same SIP URL. > > We could take the question further and ask what call-flow to > use when one > of the > apps is not SIP-enabled, but rather uses one of the other > protocols which > can be translated to/from SIP > with a gateway. > > This is a rather wide question, and no doubt many implementations are > possible. I'd like to see what > has been written about these possibilities. > > > Joshua Fox > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 18 03:32:07 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA12830 for ; Wed, 18 Oct 2000 03:32:06 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8F80544370; Wed, 18 Oct 2000 02:23:06 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 4525444338 for ; Wed, 18 Oct 2000 02:22:00 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id DAA23424; Wed, 18 Oct 2000 03:24:04 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <4WS2XR9R>; Wed, 18 Oct 2000 03:18:07 -0400 Message-ID: From: Jonathan Rosenberg To: Gonzalo.Camarillo@lmf.ericsson.se, sip@lists.bell-labs.com Subject: RE: [SIP] CANCEL and stateless proxies MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 18 Oct 2000 03:17:56 -0400 This issue is actually more closely related to the SRV discussion. Your issue with CANCEL could just as well be applied to retransmissions. If I send an INVITE through a proxy, how can I be sure that a retransmission of the INVITE goes the same way? The solution is the same we proposed for SRV. Stateless proxies should route requests within the same transaction to the same destination. Doing this more generally than SRV is a bit harder, but here are some guidelines: 1. if the proxy routing logic depends on some static information plus a random variable, make sure that random variable is generated so that it is invariant across requests for the same transaction (hash of transaction, take N bits, works well) 2. if the proxy routing is not dependent on things that have temporal variations, and not dependent on randomization, you should have no problem. 3. if the proxy routing does have temporal variations, well, in this case the proxy might really need to store some state around transition times. This may seem unreasonable, but consider this: a proxy whose routing can change as a function of time basically is a forking proxy, since it might send an INVITE one way, and then a retransmission another way. We have a requirement that forking proxies must be stateful. So, if you can't prevent forking, you can't be stateless. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com > -----Original Message----- > From: Gonzalo.Camarillo@lmf.ericsson.se > [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > Sent: Tuesday, October 17, 2000 6:05 AM > To: sip@lists.bell-labs.com > Subject: [SIP] CANCEL and stateless proxies > > > Hi, > > A CANCEL request for a previous INVITE follows the same path as > the INVITE. This > way the CANCEL request arrives to the same set of hosts as the > INVITE. > > Stateful proxies storing transaction state perform this routing > fine. > > What about stateless proxies? The CANCEL might be routed in a > different way than > the previous INVITE. > > This issue is somehow related to the "BYE after a INVITE" > issue. It is > preferable to send a CANCEL rather than a BYE after a INVITE > because stateful > proxies storing transaction state will route the CANCEL > properly. The BYE might > be routed in a wrong way. > > My question is: the same way proxies storing just transaction > state (not call > state) might route a BYE to a different host than the previous > INVITE, a > stateless proxy might route a CANCEL in a wrong way. What am I > missing? > > Thanks, > > Gonzalo > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 18 03:34:34 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA12863 for ; Wed, 18 Oct 2000 03:34:33 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id EF7F144375; Wed, 18 Oct 2000 02:23:13 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 76A8544336 for ; Wed, 18 Oct 2000 02:22:00 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id DAA23428; Wed, 18 Oct 2000 03:24:04 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <4WS2XR9T>; Wed, 18 Oct 2000 03:18:07 -0400 Message-ID: From: Jonathan Rosenberg To: Gonzalo.Camarillo@lmf.ericsson.se, sip@lists.bell-labs.com Subject: RE: [SIP] 100 responses MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 18 Oct 2000 03:17:57 -0400 Yes, I believe you are correct. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com > -----Original Message----- > From: Gonzalo.Camarillo@lmf.ericsson.se > [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > Sent: Tuesday, October 17, 2000 6:27 AM > To: sip@lists.bell-labs.com > Subject: [SIP] 100 responses > > > Hi, > > Page 73 of draft-ietf-sip-rfc2543bis-02.ps says: > "100 responses SHOULD NOT be forwarded, other 1xx responses MAY > be forwarded, > possible after..." > > Shouldn't it say that 100 responses SHOULD NOT be forwarded by > statefull proxies > but MUST be forwarded by stateless proxies? > > Regards, > > Gonzalo > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 18 03:36:21 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA12874 for ; Wed, 18 Oct 2000 03:36:21 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 979854437B; Wed, 18 Oct 2000 02:26:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 110794435D for ; Wed, 18 Oct 2000 02:25:46 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id DAA23396; Wed, 18 Oct 2000 03:23:44 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <4WS2XR9L>; Wed, 18 Oct 2000 03:17:47 -0400 Message-ID: From: Jonathan Rosenberg To: "Piotr S. Kossowski" , sip@lists.bell-labs.com Subject: RE: [SIP] Destination addresses in Via/Contact MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 18 Oct 2000 03:17:40 -0400 Yes, your interpretation is correct. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com > -----Original Message----- > From: Piotr S. Kossowski [mailto:P.Kossowski@elka.pw.edu.pl] > Sent: Tuesday, October 17, 2000 6:15 PM > To: sip@lists.bell-labs.com > Subject: [SIP] Destination addresses in Via/Contact > > > Hello, > > After studying of Via and Contact description in RFC-2543, My thinking > about these headers is not fully clear (My apologies, if it is basic > question). So, please someone to explain if something below is wrong: > > Let's imagine an INVITE sent from UAC directly to UAS that contain > (amongst others): > > Via: SIP/2.0/UDP wonderland.com:6000 > Contact: alice@wonderland.com:5080 > > After getting that INVITE by UAS, UAS should send a response > to UDP socket 6000 on wonderland.com host. > This "wonderland.com:6000" destination is valid only for this > single request from UAC. In next requests (e.g. re-INVITE or BYE) > UAC can put in Via not the same data, for example "new" 6001 port. > > As I figured out, Contact has no influence on destination of response. > Port 5080 on wonderland.com host will be used only if UAS > (callee) would > like to send some request (e.g. BYE) to UAC (caller) during this call. > > Is that true ? > > Regards, Piotr > > PS > > BTW (For Henning, I suppose): There is incorrect year of expiration > on the first side of rfc2354bis-02... > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 18 03:46:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA12980 for ; Wed, 18 Oct 2000 03:46:04 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A97724435E; Wed, 18 Oct 2000 02:45:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lists.bell-labs.com (Postfix) with ESMTP id BCDB744359 for ; Wed, 18 Oct 2000 02:44:23 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id e9I7iGt14997; Wed, 18 Oct 2000 09:44:16 +0200 (MEST) 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 KAA24120; Wed, 18 Oct 2000 10:44:14 +0300 (EET DST) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.73]) by greymse1.lmf.ericsson.se (8.9.3 (PHNE_18979)/8.8.6) with ESMTP id KAA01786; Wed, 18 Oct 2000 10:44:13 +0300 (EETDST) Message-ID: <39ED54C9.86A9A2A3@lmf.ericsson.se> From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Cc: Jonathan Rosenberg , Bryan Byerly , stlevy@cisco.com, jryang@cisco.com Subject: Re: [SIP] From header to ISUP CgPN mapping References: Content-Type: multipart/mixed; boundary="------------393D1F1B4C56D4FA02F63987" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 18 Oct 2000 10:44:09 +0300 This is a multi-part message in MIME format. --------------393D1F1B4C56D4FA02F63987 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, >>>A follow-up question: >>>How does/does Also-From header differ from the Remote-Party-Id header >>>(draft-dcsgroup-sip-privacy-02.txt)? >> >>Well, it could perhaps be possible to use that header, but the whole >>concept of that draft is a little different than just adding an >>telephone number alias to the caller, and by supporting it I guess you >>would have to do more implementation than necessary for this specfic >>need. Also, depending on what is put in Remote-Party-Id header, it is >>not even sure it would solve the problem. > >I agree. Remote-Party-ID is supposed to be an address that the network >has "verified" to be the actual address of the originator. It is even >stripped if verification cannot take place. THis seems a bit at odds with >the desired function here. > >That said, I still do not understand this need for YAI (yet another >identifier). This previous motivation involving the termination in the >PSTN or IP network is totally bogus. At this point, I am very, very, very >reluctant to add new stuff without serious justification. I agree, that this is simply an alias for the From header value, it is maybe not such a good, and efficient, way to add a new header. Another way would be to simply add a "telephone-number" URI parameter. In that case, however, the UAC must insert it (since intermediate nodes are not allowed to change to From header). Another way would be for the UAS (the PSTN GW in this case) to send a response, asking for the telephone number. A new INVITE, with the telephone number in the From (in some cases the URI could even be changed from a SIP-URL to a TEL-URL) header. And, if the "telephone-number" URI parameter is used, the From URI would not have to be changed in the new INVITE - the parameter would simply be added to the old SIP-URL. Regards, Christer Holmberg Ericsson Finland > -Jonathan R. > > --- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > http://www.dynamicsoft.com --------------393D1F1B4C56D4FA02F63987 Content-Type: text/x-vcard; charset=us-ascii; name="christer.holmberg.vcf" Content-Description: Card for Christer Holmberg Content-Disposition: attachment; filename="christer.holmberg.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Holmberg;Christer tel;cell:+358-40-5604412 tel;work:+358-9-2992943 x-mozilla-html:FALSE org:Ericsson;Advanced Signalling Research Laboratory adr:;;;;;; version:2.1 email;internet:christer.holmberg@lmf.ericsson.se title:System Designer fn:Christer Holmberg end:vcard --------------393D1F1B4C56D4FA02F63987-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 18 04:16:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA13247 for ; Wed, 18 Oct 2000 04:16:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9A2E444356; Wed, 18 Oct 2000 03:16:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lists.bell-labs.com (Postfix) with ESMTP id 7D8E94434D for ; Wed, 18 Oct 2000 03:15:13 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id e9I8F0t06666; Wed, 18 Oct 2000 10:15:00 +0200 (MEST) 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 LAA26509; Wed, 18 Oct 2000 11:14:59 +0300 (EET DST) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.73]) by greymse1.lmf.ericsson.se (8.9.3 (PHNE_18979)/8.8.6) with ESMTP id LAA11749; Wed, 18 Oct 2000 11:14:57 +0300 (EETDST) Message-ID: <39ED5BFE.C46E399D@lmf.ericsson.se> From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Cc: Jonathan Rosenberg , Brett Tate Subject: Re: [SIP] Session-timer with INFO References: Content-Type: multipart/mixed; boundary="------------D22119B6B90BA1266B4581AB" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 18 Oct 2000 11:14:54 +0300 This is a multi-part message in MIME format. --------------D22119B6B90BA1266B4581AB Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, >First off, I'd like to agree with others here that this is a rehash of >whats already been discussed, and decided, in the past. If we revisit >every decision every few months as new people join the lists, we'll never >make progress. > >The use of INVITE along with the SDP has numerous benefits above just the >INFO approach. It allows for crash recoveries, it allows for refreshes of >session state in intermediate devices, such as proxies, and it follows >the soft-state model present in other similar protocols. Thus, it is more >general purpose of a solution. Thats been our goal with SIP - to have >fairly general purpose components that could be used to build a variety >of different services. I don't want to change the current draft, because it does provide a very mechanism to keep sessions alive, and I agree that it would not take us anywhere if we change things every time someone has a different opinion. My point it is very "heavy", both on the network and the endpoint logic, if the only thing I want is a session heartbeat on the signaling level. Of course, I can personally chose to send INFOs wherever I want, but I don't think that is a good thing to do. And, that way no negotiation of the timeout value, and of which party should send the messages, is possible, why it would be much better to have a standard way on how to do it. Regards, Christer Holmberg Ericsson Finland >I'll agree INFO would eliminate a message, but compared to media, >signaling is still negligable. We've been through that one umpteen times, >and the horse is very dead. > >As for the question about how to make sure session timers don't keep >getting resent if the UAS doesn't support them, thats easy. It would >include a Require header in the request, listing "timer". If the UAS >doesn't support session timer, the request is rejected (no session is >setup either). Now, the UAC knows that the terminating UA doesn't support >the timer. So, it can either start the session without session timer at >all by sending a new INVITE with no Supported header and no >Session-Expires header, give up, or do session timer anyway if the >proxies want it (Supported header, no Session-Expires header). > >Brett also asks if the UAC can ask to not have the session revived if the >UAS isn't active. The question really is, who gets to make that decision? >Is it realy the UAC who should ultimately decide whether a session >restart is appropriate? Since its really the UAS that needs to do it, it >seems like it should be its responsibility to decide. > > -Jonathan R. > > --- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > > > -----Original Message----- > > From: Brett Tate [mailto:brett@broadsoft.com] > > Sent: Tuesday, October 17, 2000 6:57 PM > > To: sip@lists.bell-labs.com > > Subject: Re: [SIP] Session-timer with INFO > > > > > > > While it is true that there are other ways that this could have been > > solved, > > > it is pretty late in the game to make this kind of a > > change. Especially > > if > > > the only reason for doing so is to avoid the ACK message. > > > > Other reasons include the desire not to revive a > > dead session and to avoid the possibility of a new > > SDP in the 200 response. > > > > > > > > As a side note, we are in the process of creating a new > > version of the > > draft > > > that we hope will be used for working group last call. > > > > Steve, > > > > Can a header or parameter be defined within > > the sip-session-timer to indicate that the sender > > is just trying to extend the Session-Timer and > > check session state, but the sender does NOT > > want the session revived if it is down? The > > reverse of the boolean value could indicate a > > request to revive the session if it is down. > > > > > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip --------------D22119B6B90BA1266B4581AB Content-Type: text/x-vcard; charset=us-ascii; name="christer.holmberg.vcf" Content-Description: Card for Christer Holmberg Content-Disposition: attachment; filename="christer.holmberg.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Holmberg;Christer tel;cell:+358-40-5604412 tel;work:+358-9-2992943 x-mozilla-html:FALSE org:Ericsson;Advanced Signalling Research Laboratory adr:;;;;;; version:2.1 email;internet:christer.holmberg@lmf.ericsson.se title:System Designer fn:Christer Holmberg end:vcard --------------D22119B6B90BA1266B4581AB-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 18 08:04:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA16892 for ; Wed, 18 Oct 2000 08:04:03 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id F31A74434F; Wed, 18 Oct 2000 07:04:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sumo.vocaltec.co.il (sumo.vocaltec.co.il [199.203.72.1]) by lists.bell-labs.com (Postfix) with ESMTP id BD2404434D for ; Wed, 18 Oct 2000 07:03:47 -0400 (EDT) Received: from ilnimo.vocaltec.co.il (ilnimo.vocaltec.co.il [194.90.71.135]) by sumo.vocaltec.co.il (8.9.3/8.9.3) with ESMTP id OAA12212 for ; Wed, 18 Oct 2000 14:03:51 +0200 (IST) From: Joshua_Fox@vocaltec.com To: sip@lists.bell-labs.com X-Mailer: Lotus Notes Release 5.0.3 March 21, 2000 Message-ID: X-MIMETrack: Serialize by Router on ILNimo/Vocaltec_Comm(Release 5.0.3 (Intl)|21 March 2000) at 10/18/2000 02:03:10 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [SIP] SIP tunneled over HTTP Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 18 Oct 2000 14:03:10 +0200 The documents at http://www.cs.columbia.edu/~hgs/sip/drafts_firewall.html discuss the issue of SIP through firewalls at detail for SIP associated with VoIP and similar media. Indeed, as the draft at http://www.cs.columbia.edu/~hgs/sip/drafts/draft-rosenberg-sip-firewalls-00.txt points out, the main problem is not SIP but the media. One of the advantages of SOAP and similar protocols is to tunnel everything over HTTP. It does get kind of silly to play a cat-and-mouse game with the firewall administrator, but SOAP has chosen this approach (although the possibility of yet another layer of blocking, in which the firewall can actually block certain SOP messages, has been considered; you could take the cat-and-mouse game one more level and tunnel firewall-forbidden SOAP over firewall-allowed SOAP). Given media that themselves use HTTP, what about the possibility of tunneling SIP over HTTP (using the usual techniques of tunneling: place SIP headers+body as part of the body of HTTP)? There are problems. HTTP is request-response, so we have to consider how to get notifications from server-to-client. We could run an HTTP-server on the client too, but as the above-mentioned draft mentions, some firewalls do not allow arbitrary incoming HTTP to port 80. What I am discussing here is similar, but not identical, to the "non-solutions" mentioned in the Section 7 of the draft. I admit it's slow, clumsy, and bad for security, but since HTTP-tunneling is at least reasonable enough to be considered by SOAP people, among others, I wonder if it has been considered by SIP people. Joshua Fox _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 18 08:28:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA17524 for ; Wed, 18 Oct 2000 08:28:02 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 605CD4434C; Wed, 18 Oct 2000 07:28:04 -0400 (EDT) Delivered-To: sip@share.research.bell-labs.com Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by lists.bell-labs.com (Postfix) with SMTP id 2A02644351 for ; Tue, 17 Oct 2000 18:06:06 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Tue Oct 17 19:05:19 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 2814644380; Tue, 17 Oct 2000 18:52:10 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ans.ih.lucent.com (ans.ih.lucent.com [135.2.78.5]) by lists.bell-labs.com (Postfix) with SMTP id D69D94437D for ; Tue, 17 Oct 2000 18:52:09 -0400 (EDT) Received: by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id RAA05473; Tue, 17 Oct 2000 17:52:07 -0500 Cc: sip@lists.bell-labs.com Received: from lucent.com by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id RAA05461; Tue, 17 Oct 2000 17:52:05 -0500 Message-ID: <39ECD811.C9B81628@lucent.com> From: "Vijay K. Gurbani" Reply-To: vkg@lucent.com Organization: Intelligent Network/Messaging Systems & Internet Software Group X-Mailer: Mozilla 4.61 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: "Piotr S. Kossowski" Original-CC: sip@lists.bell-labs.com Subject: Re: [SIP] Destination addresses in Via/Contact References: <39ECCF76.985AAFF@elka.pw.edu.pl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 17 Oct 2000 17:52:01 -0500 Content-Transfer-Encoding: 7bit "Piotr S. Kossowski" wrote: > > Hello, > > After studying of Via and Contact description in RFC-2543, My thinking > about these headers is not fully clear (My apologies, if it is basic > question). So, please someone to explain if something below is wrong: > > Let's imagine an INVITE sent from UAC directly to UAS that contain > (amongst others): > > Via: SIP/2.0/UDP wonderland.com:6000 > Contact: alice@wonderland.com:5080 > > After getting that INVITE by UAS, UAS should send a response > to UDP socket 6000 on wonderland.com host. Right. A FQDN (fully qualified domain name) is recommended for Via lists, though. Responses are sent to the topmost Via. > This "wonderland.com:6000" destination is valid only for this > single request from UAC. In next requests (e.g. re-INVITE or BYE) > UAC can put in Via not the same data, for example "new" 6001 port. Right. The next request is a new transaction which has no bearing on the previous one. Thus the topmost Via for the new request could be, as you indicated, Via: SIP/2.0/UDP wonderland.com:6001 > As I figured out, Contact has no influence on destination of response. Nope. Responses follow the Via list. > Port 5080 on wonderland.com host will be used only if UAS (callee) > would like to send some request (e.g. BYE) to UAC (caller) during this > call. > > Is that true ? Right. It gets somewhat more complicated when a proxy is involved and it wants to do Record-Route'ing. In that case, a Route list has to be constructed by the UACs, with Contact being at the bottom of the list. This Route list basically acts the same for requests as the Via list does for responses; i.e. requests are proxied to the topmost Route entry (which is removed before proxying). See Section 6.34 of the bis for more information. Regards, - vijay -- Vijay K. Gurbani vkg@lucent.com vkg@research.bell-labs.com vkg@acm.org Internet Software Group/Intelligent Network and Messaging Systems Lucent Technologies/Bell Labs Innovations, 263 Shuman Blvd, Rm 1A-413 Naperville, Illinois 60566 Voice: +1 630 224 0216 Fax: +1 630 713 0184 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 18 08:29:28 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA17598 for ; Wed, 18 Oct 2000 08:29:28 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 55B9E4435D; Wed, 18 Oct 2000 07:28:15 -0400 (EDT) Delivered-To: sip@share.research.bell-labs.com Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by lists.bell-labs.com (Postfix) with SMTP id 0D22F44338 for ; Tue, 17 Oct 2000 19:04:05 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by dirty; Tue Oct 17 20:02:27 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 7366344380; Tue, 17 Oct 2000 19:49:18 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ans.ih.lucent.com (ans.ih.lucent.com [135.2.78.5]) by lists.bell-labs.com (Postfix) with SMTP id 2E8324437D for ; Tue, 17 Oct 2000 19:49:18 -0400 (EDT) Received: by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id SAA20632; Tue, 17 Oct 2000 18:49:15 -0500 To: sip@lists.bell-labs.com, Jonathan Rosenberg , schulzrinne@cs.columbia.edu Cc: P.Kossowski@elka.pw.edu.pl, Vijay Gurbani Received: from lucent.com by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id SAA20625; Tue, 17 Oct 2000 18:49:15 -0500 Message-ID: <39ECE577.6811010D@lucent.com> From: "Vijay K. Gurbani" Reply-To: vkg@lucent.com Organization: Intelligent Network/Messaging Systems & Internet Software Group X-Mailer: Mozilla 4.61 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 Original-To: sip@lists.bell-labs.com, Jonathan Rosenberg , schulzrinne@cs.columbia.edu Original-CC: P.Kossowski@elka.pw.edu.pl, Vijay Gurbani Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] CANCEL - response sequence issue (again) Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 17 Oct 2000 18:49:11 -0500 Content-Transfer-Encoding: 7bit Jonathan/Dr. Schulzrinne: possible backward compatibility scenario listed below. If you please, could you go through this email... All: Sorry to beat a (maybe not so) dead horse; but I think that the INVITE/{CANCEL,BYE} issue may lead to interoperability problems. On October 16th, Piotr Kossowski and I had an email exchange included in this URL: http://lists.bell-labs.com/pipermail/sip/2000q4/003311.html Based on some of my call flows, Piotr had asked if his call flows (rep- roduced as 3 and 4 below) were correct: > My question is about correctness of next sequences: > > 3. > > UAC > INVITE-----> > <----------- 100, 18x.. > CANCEL-----> > <----------- 487 (CSeq: xxx INVITE) > <----------- 200 (CSeq: xxx CANCEL) > ACK--------> (for 487 response) > > Is it allowed to send 200 response just after sending 487, before > getting ACK for 487 response ? > > If yes, what about: > > 4. > UAC > INVITE-----> > <----------- 100 , 18x.. > CANCEL-----> > <----------- 200 (CSeq: xxx CANCEL) > <----------- 487 (CSeq: xxx INVITE) > ACK--------> (for 487 response) > To which I had replied, both were correct and the order did not matter since these were two distinct transactions. But I am not so convinced any more. I think we may have a backward compatibility issue here. First off, response 487 was not present in the original RFC 2543, it is new to the bis. Thus, the UAS coded according to the original RFC would exhibit this behavior: UAC INVITE------> <------------ 100, 18x, ... CANCEL -----> <------------ 200 OK (CSeq: xxx CANCEL) and that's it (and this is the behavior I am observing of the UASes I have in my lab). Now, if we have a UAC (actual UAC or a virtual UAC branch on a proxy) that's coded according to the new bis but dealing with a UAS that's coded according to the original RFC, the order of delivery suddenly becomes important if the UAC wants to clean state correctly. Consider a UAC coded to the bis spec dealing with an old UAS coded to the RFC 2543 spec. If the UAC sends a CANCEL, it will only get the 200 OK (CSeq: xxx CANCEL). So, it is done with the CANCEL/200 OK transaction. But it will never get the 487 Request Terminated response for it's original INVITE. The UAC will not retransmit the INVITE (since it got the provisional responses), leading to inconsistent call state in the UAC. I think the bis should, in section 4.2.5 stress that, "...If the server has not issued a final response for the original request, it immediately sends a 487 Request Terminated for the original request. The UAC confirms receipt of any final response for the original request as normal with an ACK request. CANCEL request is answered with a 200 OK response in either case after the original transaction has completed." ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ My suggested wordings; please re-word if needed In this case, if the newly minted UAC sends a CANCEL after the INVITE, and gets a 200 OK (CSeq: xxx CANCEL) instead of a 487 Request Terminated, it can figure out that it is dealing with an older UAS which will NOT send it a 487. Thus it can close all its transactions on getting a 200 OK (CSeq: xxx CANCEL). If I am mistaken in my analysis (which won't be the first time), please let me know. Thanks, - vijay -- Vijay K. Gurbani vkg@lucent.com vkg@research.bell-labs.com vkg@acm.org Internet Software Group/Intelligent Network and Messaging Systems Lucent Technologies/Bell Labs Innovations, 263 Shuman Blvd, Rm 1A-413 Naperville, Illinois 60566 Voice: +1 630 224 0216 Fax: +1 630 713 0184 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 18 08:32:15 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA17712 for ; Wed, 18 Oct 2000 08:32:15 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7034F44366; Wed, 18 Oct 2000 07:28:24 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from drago1.ubiquity.net (unknown [194.202.146.92]) by lists.bell-labs.com (Postfix) with SMTP id 178A04435B for ; Wed, 18 Oct 2000 07:04:19 -0400 (EDT) Received: from gecko.ubiquity.co.uk by drago1.ubiquity.net via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 18 Oct 2000 12:04:47 UT Received: from phoffer by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id NAA07861; Wed, 18 Oct 2000 13:02:38 +0100 (BST) Message-ID: <001601c038fb$3b86a340$5334c3c1@ubiquity.co.uk> From: "Phil Hoffer" To: 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 Subject: [SIP] Repost: Use of Record-Route and Contact Headers Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 18 Oct 2000 13:02:04 +0100 Content-Transfer-Encoding: 7bit > Hi, > > Table 4 of bis02 states that a Contact header can occur in the following > response types: > > 1xx > 2xx > 3xx > 485 (Ambiguous) > > However, Table 5 states that Record-Route can occur in the following > response types: > > 2xx > 401 (Unauthorized) > 484 (Address Incomplete) > > I don't see how a response can include a Record-Route, if it can't contain > a Contact. > I believe that 401 and 484 should be added to the list of response types for > a Contact header. > > What do you think? > > Cheers > Phil (Just appreciating how overloaded Contact header is! :) Hi again, No replies so far! Probably got lost in the deluge. Thanks In Advance Phil http://www.ubiquity.net _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 18 08:35:45 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA17827 for ; Wed, 18 Oct 2000 08:35:45 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B8F1644377; Wed, 18 Oct 2000 07:33:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lists.bell-labs.com (Postfix) with ESMTP id 20F7D44364 for ; Wed, 18 Oct 2000 07:32:51 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id e9ICWjt28111 for ; Wed, 18 Oct 2000 14:32:45 +0200 (MEST) Received: from lmf.ericsson.se (E005004B57366.lmf.ericsson.se [131.160.30.12]) by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id PAA15837 for ; Wed, 18 Oct 2000 15:32:44 +0300 (EET DST) Message-ID: <39ED986B.A022F0AB@lmf.ericsson.se> From: Gonzalo Camarillo X-Mailer: Mozilla 4.74 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] Route learnt out of band Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 18 Oct 2000 15:32:43 +0300 Content-Transfer-Encoding: 7bit Hi, UACs build Route headers based on the Record-Route header received in a previous response. But, can a UAC build a Route header that is not based on any previous response received? That is, the UAC builds a Route header based on information obtained out of band and then sends the INVITE. There are many scenarios where this feature would be very useful. For instance, I am in Heslinki connected to the Internet (outside the Ericsson intranet) and I want to call a guy in Ericsson Helsinki. I want to reach that guy at sip:maglar@ws1234.ericsson.fi Ericsson has firewalls, so the calls have to be routed by a SIP proxy that belongs to Ericsson. If I send an INVITE with Request-URI=sip:maglars@ws1234.ericsson.fi it will be stopped by the firewall. If I send an INVITE with a Request-URI=sip:Magnus.Lars@ericsson.com (that is his public address) it will reach first the SIP server handling the ericsson.com domain. This server is in the States. Then, it will forward the INVITE to the SIP server hanlding ericsson Finland and so on. The INVITE traverses a bunch of different servers until if gets to ws1234.ericsson.fi (his workstation). If I could build my INVITE with a Route header as follows: Route: , I would save lots of hops in the path. This is just one scenario among many others (probaly more useful) where this could be employed. Does anybody see any problem with this? Best regards, Gonzalo _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 18 09:12:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA18859 for ; Wed, 18 Oct 2000 09:12:02 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E65EE4434C; Wed, 18 Oct 2000 08:12:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from drago1.ubiquity.net (unknown [194.202.146.92]) by lists.bell-labs.com (Postfix) with SMTP id 285AA44336 for ; Wed, 18 Oct 2000 08:11:11 -0400 (EDT) Received: from gecko.ubiquity.co.uk by drago1.ubiquity.net via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 18 Oct 2000 13:11:39 UT Received: from gethin by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id OAA00402; Wed, 18 Oct 2000 14:09:21 +0100 (BST) From: Gethin Liddell Organization: Ubiquity Software Corp. To: Chris Harris , Itamar Gilad Subject: Re: [SIP] JAIN SIP Specification X-Mailer: KMail [version 1.0.29.2] Content-Type: text/plain Cc: sip@lists.bell-labs.com, "'SIPForum list'" References: <39EB464C.44254E5B@dynamicsoft.com> In-Reply-To: <39EB464C.44254E5B@dynamicsoft.com> MIME-Version: 1.0 Message-Id: <00101814092004.10136@gethin> Content-Transfer-Encoding: 8bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 18 Oct 2000 13:24:55 +0100 Content-Transfer-Encoding: 8bit All, This idea of abstraction of the JAIN API is certainly a valid and interesting idea. However, i'm a bit concerened that the proposed solution of many different packages, will only seek to complicate and maybe enlarge the API. I too see no reason why there is an EntityHeader etc... and i also do not see any requirement for an InviteMessage, AckMessage etc... How about if the format of the API remains as is: jain.protocol.ip.sip jain.protocol.ip.sip.header jain.protocol.ip.sip.message except that the messages available in the message package consisted of BasicRequest/Response, MinimalRequest/Response etc... where each message is extened in turn (e.g. Minimal extends Basic, Moderate extends Minimal etc...), of course as Chris points out it is not hard to see that a combination would be required that is not provided. So in the interest of flexibility, it could be possible for the user to plug-in to the message class what extra headers it requires. The only issue then is that the user will have to use a "public Header getHeader(String headerName)" and then cast the header to their desired header type. Either that or create their own Message class (extending the current ones) that simply does the casting automatically for them. Then after compiling, run an obfuscator on the code and it will automatically extract and only extract the Message, Headers and even methods that are used. This then will also cut down on the number of methods in the Provider as there will be no need for the sendAck(AckMessage), sendInvite(InviteMessage) etc.. as they would be replaced by the single method sendRequest(RequestMessage). I personally see three arguments for keeping the JAIN SIP stack as small as possible: 1) The first is for embedded applications where stack size has to be kept to a minimum as memory is at a premium. So if just using the Basic message suffices then this will compile and run with a small number of classes present from the stack. Don't forget, obfuscation will help in extracting only the Messages, Headers and even methods required from a jar file but it won't do everything. 2) The second is that users may be put off or confused by the sheer size and complexity of the JAIN stack. So if only using the BasicMessage gets them on the first rung of the ladder then it is a good starting point and allows them to build up to bigger and better things. 3) We also have to consider who is going to implement the JAIN SIP stack. If it is indeed overly complicated then no-one or a single vendor may end up implmenting the stack and thus its definition and all the hard work that has gone into it is useless. On Mon, 16 Oct 2000, Chris Harris wrote: > Itamar, > > The idea of levelling the API based on what messages, headers and response codes > are understood is certainly an interesting one - minimal, basic, redirection, > firewall-friendly, negotiation, authentication and "full". > > jain.protocol.ip.sip > jain.protocol.ip.sip.header > jain.protocol.ip.sip.message > > could then become... > > jain.protocol.ip.sip - listener, provider, stack, general classes used at all > levels > jain.protocol.ip.sip.header - contains base Header class (and requestHeader, > ResponseHeader, EntityHeader, GeneralHeader) > jain.protocol.ip.sip.message - contains base Message class > > jain.protocol.ip.sip.minimal - general classes used only at this level and above > > jain.protocol.ip.sip.minimal.header - headers used only at this level and above > jain.protocol.ip.sip.minimal.message - messages only used at this level and > above > > jain.protocol.ip.sip.basic - general classes used only at this level and above > jain.protocol.ip.sip.basic.header - headers used only at this level and above > jain.protocol.ip.sip.basic.message - messages used only at this level and above > ... > .... > jjain.protocol.ip.sip."full" - general classes only used at this level > jain.protocol.ip.sip."full".header - headers used only at this level > jain.protocol.ip.sip."full".message - messages used only at this level > > The API user could then pick the packages they need - say they initially only > want the minimal features, but then realise they need to use their application > behind a firewall - then they can simply add the firewall-friendly package. The > RFC says "In general, each capability listed builds on the ones above it" but it > is not hard to see that firewall-friendly and authentication may be desired > without redirection for example. > > Is this what you hand in mind Itamar? -- Gethin Liddell Ubiquity Software Corporation http://www.ubiquity.net mailto:gethin@ubiquity.net _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 18 09:23:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA19129 for ; Wed, 18 Oct 2000 09:23:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 988924434C; Wed, 18 Oct 2000 08:23:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id C32BC4434C for ; Wed, 18 Oct 2000 08:22:51 -0400 (EDT) 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 JAA04109; Wed, 18 Oct 2000 09:22:45 -0400 (EDT) Message-ID: <39EDA426.1D670C89@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Joshua_Fox@vocaltec.com Cc: sip@lists.bell-labs.com Subject: Re: [SIP] SIP tunneled over HTTP References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 18 Oct 2000 09:22:46 -0400 Content-Transfer-Encoding: 7bit Joshua_Fox@vocaltec.com wrote: > > What I am discussing here is similar, but not identical, to the > "non-solutions" mentioned in the Section 7 of the draft. I admit it's slow, > clumsy, and bad for security, but since HTTP-tunneling is at least > reasonable enough to be considered by SOAP people, among others, I wonder > if it has been considered by SIP people. > Fortunately, such kludges require no protocol support, so anybody is free to invent and implement them without the assistance of the IETF. That way, we don't get blamed if you get fired for violating your company's security policy or get your security clearance revoked if you work at a government lab (unless your name is Deutsch, in which case you can probably tunnel SIP on your personal laptop). Just run IP-over-HTTP, and you don't even have to do this for each protocol. See http://www.linux.org/docs/ldp/howto/mini/Firewall-Piercing-6.html or http://www.nocrew.org/software/httptunnel.html -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 18 09:57:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA19978 for ; Wed, 18 Oct 2000 09:57:02 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id F305A4434C; Wed, 18 Oct 2000 08:57:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 45CA344336 for ; Wed, 18 Oct 2000 08:56:29 -0400 (EDT) Received: from dynamicsoft.com (ip194.honxr2.ras.tele.dk [195.249.119.194]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id JAA25631; Wed, 18 Oct 2000 09:58:22 -0400 (EDT) Message-ID: <39EDAB64.657547E4@dynamicsoft.com> From: Anders Kristensen Organization: dynamicsoft X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 To: Gonzalo Camarillo Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Route learnt out of band References: <39ED986B.A022F0AB@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 18 Oct 2000 15:53:40 +0200 Content-Transfer-Encoding: 7bit This ability to perform source routing for an initial INVITE came up recently as a desirable feature in a slightly different context. I think most people agreed it was a good idea but it's not guaranteed to work with proxies implementing either rfc2543 or the current bis draft. It seems a pretty straightforward generalisation but I think one potential complication is that the Route used might be incomplete, i.e. the initial INVITE (or other method for that matter) may need to traverse proxies not explicitly on the Route. These proxies should have a chance to stay on the signaling path, i.e. must be allowed to add themselves to a Record-Route header. The issue then is whether all proxies will add themselves to the Record-Route (even if they may be on the Route) and whether the endpoints will update their routes. There are probably other problems. Anders Gonzalo Camarillo wrote: > > Hi, > > UACs build Route headers based on the Record-Route header received in a > previous response. But, can a UAC build a Route header that is not based > on any previous response received? That is, the UAC builds a Route > header based on information obtained out of band and then sends the > INVITE. > > There are many scenarios where this feature would be very useful. > > For instance, I am in Heslinki connected to the Internet (outside the > Ericsson intranet) and I want to call a guy in Ericsson Helsinki. I want > to reach that guy at sip:maglar@ws1234.ericsson.fi > > Ericsson has firewalls, so the calls have to be routed by a SIP proxy > that belongs to Ericsson. If I send an INVITE with > Request-URI=sip:maglars@ws1234.ericsson.fi it will be stopped by the > firewall. > > If I send an INVITE with a Request-URI=sip:Magnus.Lars@ericsson.com > (that is his public address) it will reach first the SIP server handling > the ericsson.com domain. This server is in the States. Then, it will > forward the INVITE to the SIP server hanlding ericsson Finland and so > on. The INVITE traverses a bunch of different servers until if gets to > ws1234.ericsson.fi (his workstation). > > If I could build my INVITE with a Route header as follows: > Route: , > > > I would save lots of hops in the path. > > This is just one scenario among many others (probaly more useful) where > this could be employed. > > Does anybody see any problem with this? > > Best regards, > > Gonzalo > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 18 10:02:11 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA20100 for ; Wed, 18 Oct 2000 10:02:08 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id AB68E4434C; Wed, 18 Oct 2000 09:02:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from gollum.axion.bt.co.uk (gollum.axion.bt.co.uk [132.146.17.41]) by lists.bell-labs.com (Postfix) with ESMTP id 2FD3E44336 for ; Wed, 18 Oct 2000 09:01:37 -0400 (EDT) Received: from cbtlipnt01.btlabs.bt.co.uk by gollum (local) with ESMTP; Wed, 18 Oct 2000 15:01:33 +0100 Received: by cbtlipnt01.btlabs.bt.co.uk with Internet Mail Service (5.5.2652.35) id ; Wed, 18 Oct 2000 15:00:10 +0100 Message-ID: From: richard.swale@bt.com To: Joshua_Fox@vocaltec.com, sip@lists.bell-labs.com Subject: RE: [SIP] SIP tunneled over HTTP X-Mailer: Internet Mail Service (5.5.2652.35) MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 18 Oct 2000 14:58:18 +0100 Joshua, An interesting idea - however I think we need to be clear about the type of media involved. If it is text, graphic images or half duplex sound then we can probably get away with this type of approach - some of the security experts may raise additional concerns though because tunnelling kind of defeats the idea of the firewall in the first place. However if we are talking about real-time full duplex streamed audio and video then there are QoS concerns that may be hard to overcome with the tunnelling approach. regards Richard -----Original Message----- From: Joshua_Fox@vocaltec.com [mailto:Joshua_Fox@vocaltec.com] Sent: Wednesday, October 18, 2000 1:03 PM To: sip@lists.bell-labs.com Subject: [SIP] SIP tunneled over HTTP The documents at http://www.cs.columbia.edu/~hgs/sip/drafts_firewall.html discuss the issue of SIP through firewalls at detail for SIP associated with VoIP and similar media. Indeed, as the draft at http://www.cs.columbia.edu/~hgs/sip/drafts/draft-rosenberg-sip-firewalls-00. txt points out, the main problem is not SIP but the media. One of the advantages of SOAP and similar protocols is to tunnel everything over HTTP. It does get kind of silly to play a cat-and-mouse game with the firewall administrator, but SOAP has chosen this approach (although the possibility of yet another layer of blocking, in which the firewall can actually block certain SOP messages, has been considered; you could take the cat-and-mouse game one more level and tunnel firewall-forbidden SOAP over firewall-allowed SOAP). Given media that themselves use HTTP, what about the possibility of tunneling SIP over HTTP (using the usual techniques of tunneling: place SIP headers+body as part of the body of HTTP)? There are problems. HTTP is request-response, so we have to consider how to get notifications from server-to-client. We could run an HTTP-server on the client too, but as the above-mentioned draft mentions, some firewalls do not allow arbitrary incoming HTTP to port 80. What I am discussing here is similar, but not identical, to the "non-solutions" mentioned in the Section 7 of the draft. I admit it's slow, clumsy, and bad for security, but since HTTP-tunneling is at least reasonable enough to be considered by SOAP people, among others, I wonder if it has been considered by SIP people. Joshua Fox _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 18 10:04:48 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA20259 for ; Wed, 18 Oct 2000 10:04:46 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5838A4436B; Wed, 18 Oct 2000 09:03:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 46A2C4434C for ; Wed, 18 Oct 2000 09:02:49 -0400 (EDT) Received: from dynamicsoft.com (useraa51.ie.uudial.com [212.120.133.52]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id KAA25771; Wed, 18 Oct 2000 10:04:47 -0400 (EDT) Message-ID: <39EDAD8D.6EC60BC6@dynamicsoft.com> From: Chris Harris Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Billy Biggs Cc: jainsip@sun.com, sip@lists.bell-labs.com, discussion@sipforum.org References: <20001017145531.A2803@div8.net> Content-Type: multipart/alternative; boundary="------------8C17F599F1B087C90CAAEED9" Subject: [SIP] Re: JAIN SIP Comments Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 18 Oct 2000 15:02:53 +0100 --------------8C17F599F1B087C90CAAEED9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Billy, Responses below in blue... Chris Billy Biggs wrote: > Hi, > > I wondered why I still had no response to this message, when I > realized that it never got sent! :) > == > > Chris, > > > > [...] Probably the largest part of the design that really shocked > > > me was the extensive amount of parsing that the library seems to > > > imply. [...] > > > > The first and foremost aim of the JAIN SIP API is application > > portability. It seems you are suggesting that a header value should > > be simply defined as a String. This approach was considered to be > > unacceptable by the expert group because allowing the API user to put > > any String into a header seriously increases the risk of incorrect use > > of the API, and applications which are not portable. > > Now that I read over the API again, it doesn't seem so bad. But > still, I'm surprised you'd have such a comprehensive object to represent > the User-Agent and Server headers, including the product name and > version as separate values? It seems that a straightforward > implementation might end up having to parse alot more than it needs to. That's a fair point - the API does assume that an implementation needs to parse in as much detatil as the ABNF. The question is - where to draw the line. Some headers will have a value that can reasonably represented by a String value, and others will not. I suppose UserAgentHeader and ServerHeader could just have a "Product" string value. > > > The same is true of the call-id. Why bother having a method to > extract the host portion of the call-id? It's unlikely this will be > required separately, and implementations are supposed to treat the > call-id as an opaque string anyways. Indeed CallIdHeader could uses a String value too. I am considering removing the Challenge and Credential classes and replacing them in the authenticate/authorization headers with just a scheme String and a challenge/credentials String (or Parameters object mentioned below?). This will mean the implementation won't have to understand the schemes. What do you think? > > > One thing I noticed was that the object hierarchy does not take into > account the contents of the headers but rather the structure of a > message. I have removed GeneralHeader, EntityHeader, RequestHeader and ResponseHeader - removing a layer in the header hierarchy. Now the API just relies on a header type parameter to the Header constructor. > > > For example, there isn't much difference at all between the Contact, > Record-Route, Route, and even the To and From in a SIP message. Each of > these contains a NameAddress along with some header parameters. Why not > have them inherit from a common base class? I guess you're trying to > just make the object as generic as possible without enforcing an object > model on the stack behind it, but still, why not make a parametered uri > object to represent this? I have created a NameAddressParameters class - which is composed of a NameAddress and a Hashtable for parameters (get, set, has and remove methods are included for parameters). I have also created a NameAddressHeader base class for all the headers you mention above - so the generic parameter and NameAddress methods are avilable to all subclasses - FromHeader, ToHeader, ContactHeader, RecordRouteHeader and RouteHeader. > > Why have both a ToHeader and a FromHeader object if they're exactly > the same? I could add a superclass for these two classes - with the classes only differing in option tag. Can you think of an appropriate name for such a class? > > > Also, it's interesting to see how you have a ContentTypeHeader object > instead of a more general MimeContentType object. It seems to me that > something so generic should be outside of the scope of a SIP stack. > > The last object I'd think would be useful would be some sort of > ParameterList object. It would help to avoid problems like your > ViaHeader object, which is missing calls to set or retrieve extension > parameters. This is so obvious it was bound to be be overlooked :) This Parameters object could be used in SipURL and Header class - making NameAddressParameters class obsolete. I'm just thinking about parameters for the encryption and response key headers - they use a comma as a delimiter not a semi-colon and need a space before them - should they be treated independently, or should the Parameters object know which delimiter type it uses and whether it needs spaces in front? Also the via header allows a comment between via params and extension params - so should the ViaHeader class have another Parameters object specifically for via params? Wouldn't SIP have been so much easier if the parameters all used the same syntax? :) > > > > > Also, the Header object should really contain the concept of a list of > > > headers. [...] > > > > It was decided that the API would be simpler if we did not allow a > > Header to include a list. We adopted the canonical form here, so if a > > header list is received by the implementation, it simply creates a > > list of Header objects and adds them to the Message in the same order > > - which is semantically equivalent. > > Yes, now that I look at the API again, I see how you have a > getHeaders() call which handles stuff very nicely. > > Another thing I'm concerned about is how only a string key is passed > in to unencrypt a message. Is this sufficient? As well, how do you > check if a message is encrypted: if it has an encryption header? I am beginning to think that the decryptMessage and encryptMessage methods are a bad idea - Is it really fair to expect an implementation to handle this? > > > > > There also seems to be some confusion in the API about SIP calls > > > and the scope of a call-id. [...] > > > > > > This confusion is completely rampant through the entire > > > documentation as well. For example, call-leg-ends and Call-IDs > > > are confused in the description of an InviteMessage. > > > > This is absolutely true - The method for getting CSeq numbers should > > take a from and a to parameter as well as the CallIdHeader. (It would > > also be more convenient if the method returned a CSeqHeader rather > > than just a CSeq number.) > > Careful though. I'd argue: why have a CSeq header object at all? It > seems like you're letting the user have alot of power, being able to put > mis-matching methods in the CSeq and in the start line. If you're > worried about having a safe API this seems surprising. Why not just be > able to get and set the sequence numbers on messages? I could do that - but remeber there's nothing stopping the user adding a CSeq header via the Header class. I think if it is made clear in the API documentation that CSeqHeaders must be generated through the Provider, and that if the method is incorrect the Provider will fix it to match the Message method it should be OK? > > > Also regarding call-leg end matching, I'm confused about how you > intend to keep things straight between which call-leg end you're talking > about in communication with the stack. > > For example, let's say I send an Invite request and I receive four 200 > OK response, creating four active calls. I accept all of them, and then > later I want to disconnect one of them. > > If I call sendBye( listener, originalinvite ), what happens? This > seems odd. The Provider will send BYEs to all call legs > > > If I call sendBye( listener, one_of_the_responses ), is the provider > supposed to keep track of the sequence numbers for that call-leg to know > which one to use? The Provider will send BYE to call leg response corresponds to > > > I guess I'm really asking, if you're asking the provider to keep track > of the call-legs, provide the necessary calls to query and see which are > active, and perform operations on the legs directly, not through > inference by what messages get passed in from the calling code. If you > let the user send create messages from scratch and send them out, and > reply to messages using responses they created, then it means that you > have both layers struggling to keep track of all active legs, without > any common method of referencing them. I could create a CallLeg object comprised of a CallIdHeader, FromHeader and ToHeader, and have a method: public CallLeg[] getCallLegs(CallIdHeader callIdHeader) on the Provider, and also a method: public sendBye(CallLeg callLeg) throws SipException - but won't this imply that the implementation has to maintain call state? > > > Another suggestion: when talking about call-legs, it's probably best > to have a concept of the near-end and far-end URIs, since you end up > having to flip the To and the From when you send local requests to > remote calls etc. Otherwise, things just get really confusing, > especially when you try and call yourself. I'm not quite sure what you mean by this - what is a near and far URI if you not the UAC or UAS - i.e. a proxy in the middle? > > > -- > Billy Biggs, 3Com Email: Billy_Biggs@3com.com > http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com --------------8C17F599F1B087C90CAAEED9 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Billy,

Responses below in blue...

Chris
 

Billy Biggs wrote:

  Hi,

  I wondered why I still had no response to this message, when I
realized that it never got sent! :)
==

  Chris,

> > [...]  Probably the largest part of the design that really shocked
> > me was the extensive amount of parsing that the library seems to
> > imply. [...]
>
> The first and foremost aim of the JAIN SIP API is application
> portability.  It seems you are suggesting that a header value should
> be simply defined as a String. This approach was considered to be
> unacceptable by the expert group because allowing the API user to put
> any String into a header seriously increases the risk of incorrect use
> of the API, and applications which are not portable.

  Now that I read over the API again, it doesn't seem so bad.  But
still, I'm surprised you'd have such a comprehensive object to represent
the User-Agent and Server headers, including the product name and
version as separate values?  It seems that a straightforward
implementation might end up having to parse alot more than it needs to.

That's a fair point - the API does assume that an implementation needs to parse in as much detatil as the ABNF. The question is - where to draw the line. Some headers will have a value that can reasonably represented by a String value, and others will not. I suppose UserAgentHeader and ServerHeader could just have a "Product" string value.
 

  The same is true of the call-id.  Why bother having a method to
extract the host portion of the call-id?  It's unlikely this will be
required separately, and implementations are supposed to treat the
call-id as an opaque string anyways.

Indeed CallIdHeader could uses a String value too. I am considering removing the Challenge and Credential classes and replacing them in the authenticate/authorization headers with just a scheme String and a challenge/credentials String (or Parameters object mentioned below?). This will mean the implementation won't have to understand the schemes. What do you think?
 

  One thing I noticed was that the object hierarchy does not take into
account the contents of the headers but rather the structure of a
message.

I have removed GeneralHeader, EntityHeader, RequestHeader and ResponseHeader - removing a layer in the header hierarchy. Now the API just relies on a header type parameter to the Header constructor.
 

  For example, there isn't much difference at all between the Contact,
Record-Route, Route, and even the To and From in a SIP message.  Each of
these contains a NameAddress along with some header parameters.  Why not
have them inherit from a common base class?  I guess you're trying to
just make the object as generic as possible without enforcing an object
model on the stack behind it, but still, why not make a parametered uri
object to represent this?

I have created a NameAddressParameters class - which is composed of a NameAddress and a Hashtable for parameters (get, set, has and remove methods are included for parameters). I have also created a NameAddressHeader base class for all the headers you mention above - so the generic parameter and NameAddress methods are avilable to all subclasses - FromHeader, ToHeader, ContactHeader, RecordRouteHeader and RouteHeader.
 
  Why have both a ToHeader and a FromHeader object if they're exactly
the same?
I could add a superclass for these two classes - with the classes only differing in option tag. Can you think of an appropriate name for such a class?
 

  Also, it's interesting to see how you have a ContentTypeHeader object
instead of a more general MimeContentType object.  It seems to me that
something so generic should be outside of the scope of a SIP stack.

  The last object I'd think would be useful would be some sort of
ParameterList object.  It would help to avoid problems like your
ViaHeader object, which is missing calls to set or retrieve extension
parameters.

This is so obvious it was bound to be be overlooked :) This Parameters object could be used in SipURL and Header class - making NameAddressParameters class obsolete. I'm just thinking about parameters for the encryption and response key headers - they use a comma as a delimiter not a semi-colon and need a space before them - should they be treated independently, or should the Parameters object know which delimiter type it uses and whether it needs spaces in front? Also the via header allows a comment between via params and extension params - so should the ViaHeader class have another Parameters object specifically for via params? Wouldn't SIP have been so much easier if the parameters all used the same syntax? :)
 

> >   Also, the Header object should really contain the concept of a list of
> > headers. [...]
>
> It was decided that the API would be simpler if we did not allow a
> Header to include a list. We adopted the canonical form here, so if a
> header list is received by the implementation, it simply creates a
> list of Header objects and adds them to the Message in the same order
> - which is semantically equivalent.

  Yes, now that I look at the API again, I see how you have a
getHeaders() call which handles stuff very nicely.

  Another thing I'm concerned about is how only a string key is passed
in to unencrypt a message.  Is this sufficient?  As well, how do you
check if a message is encrypted: if it has an encryption header?

I am beginning to think that the decryptMessage and encryptMessage methods are a bad idea - Is it really fair to expect an implementation to handle this?
 

> >   There also seems to be some confusion in the API about SIP calls
> > and the scope of a call-id.  [...]
> >
> >   This confusion is completely rampant through the entire
> > documentation as well.  For example, call-leg-ends and Call-IDs
> > are confused in the description of an InviteMessage.
>
> This is absolutely true - The method for getting CSeq numbers should
> take a from and a to parameter as well as the CallIdHeader. (It would
> also be more convenient if the method returned a CSeqHeader rather
> than just a CSeq number.)

  Careful though.  I'd argue: why have a CSeq header object at all?  It
seems like you're letting the user have alot of power, being able to put
mis-matching methods in the CSeq and in the start line.  If you're
worried about having a safe API this seems surprising.  Why not just be
able to get and set the sequence numbers on messages?

I could do that - but remeber there's nothing stopping the user adding a CSeq header via the Header class. I think if it is made clear in the API documentation that CSeqHeaders must be generated through the Provider, and that if the method is incorrect the Provider will fix it to match the Message method it should be OK?
 

  Also regarding call-leg end matching, I'm confused about how you
intend to keep things straight between which call-leg end you're talking
about in communication with the stack.

  For example, let's say I send an Invite request and I receive four 200
OK response, creating four active calls.  I accept all of them, and then
later I want to disconnect one of them.

  If I call sendBye( listener, originalinvite ), what happens?  This
seems odd.

The Provider will send BYEs to all call legs
 

  If I call sendBye( listener, one_of_the_responses ), is the provider
supposed to keep track of the sequence numbers for that call-leg to know
which one to use?

The Provider will send BYE to call leg response corresponds to
 

  I guess I'm really asking, if you're asking the provider to keep track
of the call-legs, provide the necessary calls to query and see which are
active, and perform operations on the legs directly, not through
inference by what messages get passed in from the calling code.  If you
let the user send create messages from scratch and send them out, and
reply to messages using responses they created, then it means that you
have both layers struggling to keep track of all active legs, without
any common method of referencing them.

I could create a CallLeg object comprised of a CallIdHeader, FromHeader and ToHeader, and have a method: public CallLeg[] getCallLegs(CallIdHeader callIdHeader) on the Provider, and also a method: public sendBye(CallLeg callLeg) throws SipException - but won't this imply that the implementation has to maintain call state?
 

  Another suggestion: when talking about call-legs, it's probably best
to have a concept of the near-end and far-end URIs, since you end up
having to flip the To and the From when you send local requests to
remote calls etc.  Otherwise, things just get really confusing,
especially when you try and call yourself.

I'm not quite sure what you mean by this - what is a near and far URI if you not the UAC or UAS - i.e. a proxy in the middle?
 

--
Billy Biggs, 3Com               Email: Billy_Biggs@3com.com
http://www.div8.net/billy/      Phone: Billy_Biggs@sip.3com.com

--------------8C17F599F1B087C90CAAEED9-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 18 10:20:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA20546 for ; Wed, 18 Oct 2000 10:20:04 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 71EA34434C; Wed, 18 Oct 2000 09:20:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lists.bell-labs.com (Postfix) with ESMTP id 23EF944336 for ; Wed, 18 Oct 2000 09:19:09 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id e9IEJ0Z21848; Wed, 18 Oct 2000 16:19:00 +0200 (MEST) Received: from lmf.ericsson.se (E005004B57366.lmf.ericsson.se [131.160.30.12]) by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id RAA23276; Wed, 18 Oct 2000 17:18:58 +0300 (EET DST) Message-ID: <39EDB150.9B27646B@lmf.ericsson.se> From: Gonzalo Camarillo X-Mailer: Mozilla 4.74 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Anders Kristensen Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Route learnt out of band References: <39ED986B.A022F0AB@lmf.ericsson.se> <39EDAB64.657547E4@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 18 Oct 2000 17:18:56 +0300 Content-Transfer-Encoding: 7bit Hej Anders, Anders Kristensen wrote: > > This ability to perform source routing for an initial INVITE came up > recently as a desirable feature in a slightly different context. As I said in my mail, there are many scenarios where this feature could be useful. I believe this is a general mechanism with general applicability. Which context are you referring to? >I > think most people agreed it was a good idea but it's not guaranteed to > work with proxies implementing either rfc2543 or the current bis draft. > > It seems a pretty straightforward generalisation but I think one > potential complication is that the Route used might be incomplete, i.e. > the initial INVITE (or other method for that matter) may need to > traverse proxies not explicitly on the Route. These proxies should have > a chance to stay on the signaling path, i.e. must be allowed to add > themselves to a Record-Route header. The issue then is whether all > proxies will add themselves to the Record-Route (even if they may be on > the Route) and whether the endpoints will update their routes. > > There are probably other problems. If folks think this is a interesting feature we can work on all the issues. Best regards, Gonzalo > > Anders > > Gonzalo Camarillo wrote: > > > > Hi, > > > > UACs build Route headers based on the Record-Route header received in a > > previous response. But, can a UAC build a Route header that is not based > > on any previous response received? That is, the UAC builds a Route > > header based on information obtained out of band and then sends the > > INVITE. > > > > There are many scenarios where this feature would be very useful. > > > > For instance, I am in Heslinki connected to the Internet (outside the > > Ericsson intranet) and I want to call a guy in Ericsson Helsinki. I want > > to reach that guy at sip:maglar@ws1234.ericsson.fi > > > > Ericsson has firewalls, so the calls have to be routed by a SIP proxy > > that belongs to Ericsson. If I send an INVITE with > > Request-URI=sip:maglars@ws1234.ericsson.fi it will be stopped by the > > firewall. > > > > If I send an INVITE with a Request-URI=sip:Magnus.Lars@ericsson.com > > (that is his public address) it will reach first the SIP server handling > > the ericsson.com domain. This server is in the States. Then, it will > > forward the INVITE to the SIP server hanlding ericsson Finland and so > > on. The INVITE traverses a bunch of different servers until if gets to > > ws1234.ericsson.fi (his workstation). > > > > If I could build my INVITE with a Route header as follows: > > Route: , > > > > > > I would save lots of hops in the path. > > > > This is just one scenario among many others (probaly more useful) where > > this could be employed. > > > > Does anybody see any problem with this? > > > > Best regards, > > > > Gonzalo > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 18 10:30:06 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA20677 for ; Wed, 18 Oct 2000 10:30:05 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1E6454434C; Wed, 18 Oct 2000 09:30:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from is1-55.antd.nist.gov (is1-60.antd.nist.gov [129.6.60.251]) by lists.bell-labs.com (Postfix) with ESMTP id 7269C44336 for ; Wed, 18 Oct 2000 09:29:29 -0400 (EDT) Received: from nist.gov (IDENT:mranga@stinkbug.antd.nist.gov [129.6.55.9]) by is1-55.antd.nist.gov (8.9.3/8.9.3) with ESMTP id KAA22169; Wed, 18 Oct 2000 10:24:51 -0400 (EDT) Message-ID: <39EDB3C4.282F1EFA@nist.gov> From: "M. Ranganathan" Reply-To: mranga@nist.gov Organization: NIST advanced networking technologies group X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Cc: Gethin Liddell Subject: Re: [SIP] JAIN SIP Specification References: <39EB464C.44254E5B@dynamicsoft.com> <00101814092004.10136@gethin> Content-Type: text/plain; charset=iso-8859-1 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 18 Oct 2000 10:29:24 -0400 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id KAA20677 JAIN-SIP is a groovy idea. Hats off to the whole concept and many thanks to Chris and the JAIN-SIP team for putting together a spec and more flower power to them :-) . In particular I like the notion of treating UAS, Redirect and Proxy servers as merely special cases of the general notion of Services and the idea of unifying these notions with an event mechanism and event handlers. Second, I like the idea of separation between a stateless event -oriented "stack" and a bunch of event handlers that are triggered by the stack with all state (including transaction state) being separated from the event stack via the JAIN-SIP mapping layer if you will. ( Correct me if I wax poetic but have the wrong understanding....) I hope I will not be viewed as being too critical, but I would like to go one step further than what Gethin is suggesting. I am all for using interfaces as much as possible and leaving class hierarchy definitions to implemeters. Defining class hierarchies almost lays out an implementation and involves considerable rework for those who have a working java-based stack, but have not used the same classes. OK it is just a matter of labor to map things to the JAIN-SIP class hierarchy but it IS a dis-incentive. 1. Lets use interfaces for all messages rather than actually define class hierarchies ( yes Chris has pointed out the historical precedent behind actually defining class hierarchies for messages. IMHO, there has to be a more compelling reason than that.) 2. The tie-in with the JAVA event mechanism has necessitated the explicit definition of class hierarchies in certain places. Why not use callbacks instead and do away with this dependency as well? (Basically the same thing as events but does not tie into the JAVA event mechanism and its associated limitations.) Nice work and keep it rolling! Thanks. Ranga. Gethin Liddell wrote: > All, > > This idea of abstraction of the JAIN API is certainly a valid and > interesting idea. However, i'm a bit concerened that the proposed > solution of many different packages, will only seek to complicate and > maybe enlarge the API. > > I too see no reason why there is an EntityHeader etc... and i also do > not see any requirement for an InviteMessage, AckMessage etc... > > How about if the format of the API remains as is: > > jain.protocol.ip.sip > jain.protocol.ip.sip.header > jain.protocol.ip.sip.message > > except that the messages available in the message package consisted of > BasicRequest/Response, MinimalRequest/Response etc... where each > message is extened in turn (e.g. Minimal extends Basic, Moderate > extends Minimal etc...), of course as Chris points out it is not hard > to see that a combination would be required that is not provided. So > in the interest of flexibility, it could be possible for the user to > plug-in to the message class what extra headers it requires. The only > issue then is that the user will have to use a "public Header > getHeader(String headerName)" and then cast the header to their desired > header type. Either that or create their own Message class > (extending the current ones) that simply does the casting automatically > for them. Then after compiling, run an obfuscator on the code and it > will automatically extract and only extract the Message, Headers and > even methods that are used. > > This then will also cut down on the number of methods in the Provider > as there will be no need for the sendAck(AckMessage), > sendInvite(InviteMessage) etc.. as they would be replaced by the > single method sendRequest(RequestMessage). > > I personally see three arguments for keeping the JAIN SIP stack as small > as possible: > > 1) The first is for embedded applications where stack size has to be > kept to a minimum as memory is at a premium. So if just using the > Basic message suffices then this will compile and run with a small > number of classes present from the stack. Don't forget, obfuscation > will help in extracting only the Messages, Headers and even methods > required from a jar file but it won't do everything. > > 2) The second is that users may be put off or confused by the sheer > size and complexity of the JAIN stack. So if only using the > BasicMessage gets them on the first rung of the ladder then it is a > good starting point and allows them to build up to bigger and better > things. > > 3) We also have to consider who is going to implement the JAIN SIP > stack. If it is indeed overly complicated then no-one or a single > vendor may end up implmenting the stack and thus its definition and > all the hard work that has gone into it is useless. > > On Mon, 16 Oct 2000, Chris Harris wrote: > > Itamar, > > > > The idea of levelling the API based on what messages, headers and response codes > > are understood is certainly an interesting one - minimal, basic, redirection, > > firewall-friendly, negotiation, authentication and "full". > > > > jain.protocol.ip.sip > > jain.protocol.ip.sip.header > > jain.protocol.ip.sip.message > > > > could then become... > > > > jain.protocol.ip.sip - listener, provider, stack, general classes used at all > > levels > > jain.protocol.ip.sip.header - contains base Header class (and requestHeader, > > ResponseHeader, EntityHeader, GeneralHeader) > > jain.protocol.ip.sip.message - contains base Message class > > > > jain.protocol.ip.sip.minimal - general classes used only at this level and above > > > > jain.protocol.ip.sip.minimal.header - headers used only at this level and above > > jain.protocol.ip.sip.minimal.message - messages only used at this level and > > above > > > > jain.protocol.ip.sip.basic - general classes used only at this level and above > > jain.protocol.ip.sip.basic.header - headers used only at this level and above > > jain.protocol.ip.sip.basic.message - messages used only at this level and above > > ... > > .... > > jjain.protocol.ip.sip."full" - general classes only used at this level > > jain.protocol.ip.sip."full".header - headers used only at this level > > jain.protocol.ip.sip."full".message - messages used only at this level > > > > The API user could then pick the packages they need - say they initially only > > want the minimal features, but then realise they need to use their application > > behind a firewall - then they can simply add the firewall-friendly package. The > > RFC says "In general, each capability listed builds on the ones above it" but it > > is not hard to see that firewall-friendly and authentication may be desired > > without redirection for example. > > > > Is this what you hand in mind Itamar? > > -- > Gethin Liddell > Ubiquity Software Corporation > > http://www.ubiquity.net > mailto:gethin@ubiquity.net > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip -- M.Ranganathan NIST Advanced Networking Technologies Group, 100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899. Tel: 301 975 3664 Fax: 301 590 0932 ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÒ ùšŠX§‚X¬µ"þX¬¶ÏÛzYÿ•¦ìýÊ&†ÛiÿÿåŠËlý·¥—ùZnÏÜ¢oæj)fjåŠËbú? From sip-admin@lists.bell-labs.com Wed Oct 18 10:35:39 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA20802 for ; Wed, 18 Oct 2000 10:35:37 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9DBA944379; Wed, 18 Oct 2000 09:34:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 929124437B for ; Wed, 18 Oct 2000 09:33:12 -0400 (EDT) Received: from dynamicsoft.com (useraa51.ie.uudial.com [212.120.133.52]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id KAA26038; Wed, 18 Oct 2000 10:35:08 -0400 (EDT) Message-ID: <39EDB4AC.21D28150@dynamicsoft.com> From: Chris Harris Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Gethin Liddell Cc: Itamar Gilad , sip@lists.bell-labs.com, "'SIPForum list'" , jainsip@sun.com Subject: Re: [SIP] JAIN SIP Specification References: <39EB464C.44254E5B@dynamicsoft.com> <00101814092004.10136@gethin> Content-Type: multipart/alternative; boundary="------------5D45B4D41FF6E41185AA0DBC" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 18 Oct 2000 15:33:16 +0100 --------------5D45B4D41FF6E41185AA0DBC Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Gethin, Comments below... Chris PS - I'm looking forward to seeing you at the JAIN Meeting next week! Gethin Liddell wrote: > All, > > This idea of abstraction of the JAIN API is certainly a valid and > interesting idea. However, i'm a bit concerened that the proposed > solution of many different packages, will only seek to complicate and > maybe enlarge the API. Yes - I suppose a lot of packages will lead to a lot of confusion. > > > I too see no reason why there is an EntityHeader etc... and i also do > not see any requirement for an InviteMessage, AckMessage etc... I have removed EnityHeader etc...as for the RequestMessage classes - different classes exist because the headers applicable to each are different - hence the accessor methods on each are different. I guess we could have just a RequestMessage class - with accessor methods for only the headers common to all 6 methods, and then the user/implementor has to use the generic header methods for any other headers. If this is the case, then I don't think there is any need for layering the API as mentioned. My only concern is about the Ack and Cancel Messages, which although are requests - can in a sense be thought of as being logically separate to the other requests. > > > How about if the format of the API remains as is: > > jain.protocol.ip.sip > jain.protocol.ip.sip.header > jain.protocol.ip.sip.message > > except that the messages available in the message package consisted of > BasicRequest/Response, MinimalRequest/Response etc... where each > message is extened in turn (e.g. Minimal extends Basic, Moderate > extends Minimal etc...), of course as Chris points out it is not hard > to see that a combination would be required that is not provided. So > in the interest of flexibility, it could be possible for the user to > plug-in to the message class what extra headers it requires. The only > issue then is that the user will have to use a "public Header > getHeader(String headerName)" and then cast the header to their desired > header type. Either that or create their own Message class > (extending the current ones) that simply does the casting automatically > for them. Then after compiling, run an obfuscator on the code and it > will automatically extract and only extract the Message, Headers and > even methods that are used. > > This then will also cut down on the number of methods in the Provider > as there will be no need for the sendAck(AckMessage), > sendInvite(InviteMessage) etc.. as they would be replaced by the > single method sendRequest(RequestMessage). As I mentioned above, it may be useful to keep sendAck and sendCancel in addition to sendRequest. > > > I personally see three arguments for keeping the JAIN SIP stack as small > as possible: > > 1) The first is for embedded applications where stack size has to be > kept to a minimum as memory is at a premium. So if just using the > Basic message suffices then this will compile and run with a small > number of classes present from the stack. Don't forget, obfuscation > will help in extracting only the Messages, Headers and even methods > required from a jar file but it won't do everything. > > 2) The second is that users may be put off or confused by the sheer > size and complexity of the JAIN stack. So if only using the > BasicMessage gets them on the first rung of the ladder then it is a > good starting point and allows them to build up to bigger and better > things. > > 3) We also have to consider who is going to implement the JAIN SIP > stack. If it is indeed overly complicated then no-one or a single > vendor may end up implmenting the stack and thus its definition and > all the hard work that has gone into it is useless. Three very good reasons for using this Public Review period to make JAIN SIP realise its full potential! > > > On Mon, 16 Oct 2000, Chris Harris wrote: > > Itamar, > > > > The idea of levelling the API based on what messages, headers and response codes > > are understood is certainly an interesting one - minimal, basic, redirection, > > firewall-friendly, negotiation, authentication and "full". > > > > jain.protocol.ip.sip > > jain.protocol.ip.sip.header > > jain.protocol.ip.sip.message > > > > could then become... > > > > jain.protocol.ip.sip - listener, provider, stack, general classes used at all > > levels > > jain.protocol.ip.sip.header - contains base Header class (and requestHeader, > > ResponseHeader, EntityHeader, GeneralHeader) > > jain.protocol.ip.sip.message - contains base Message class > > > > jain.protocol.ip.sip.minimal - general classes used only at this level and above > > > > jain.protocol.ip.sip.minimal.header - headers used only at this level and above > > jain.protocol.ip.sip.minimal.message - messages only used at this level and > > above > > > > jain.protocol.ip.sip.basic - general classes used only at this level and above > > jain.protocol.ip.sip.basic.header - headers used only at this level and above > > jain.protocol.ip.sip.basic.message - messages used only at this level and above > > ... > > .... > > jjain.protocol.ip.sip."full" - general classes only used at this level > > jain.protocol.ip.sip."full".header - headers used only at this level > > jain.protocol.ip.sip."full".message - messages used only at this level > > > > The API user could then pick the packages they need - say they initially only > > want the minimal features, but then realise they need to use their application > > behind a firewall - then they can simply add the firewall-friendly package. The > > RFC says "In general, each capability listed builds on the ones above it" but it > > is not hard to see that firewall-friendly and authentication may be desired > > without redirection for example. > > > > Is this what you hand in mind Itamar? > > -- > Gethin Liddell > Ubiquity Software Corporation > > http://www.ubiquity.net > mailto:gethin@ubiquity.net --------------5D45B4D41FF6E41185AA0DBC Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Gethin,

Comments below...

Chris

PS - I'm looking forward to seeing you at the JAIN Meeting next week!

Gethin Liddell wrote:

All,

This idea of abstraction of the JAIN API is certainly a valid and
interesting idea.  However, i'm a bit concerened that the proposed
solution of many different packages, will only seek to complicate and
maybe enlarge the API.

Yes - I suppose a lot of packages will lead to a lot of confusion.
 

I too see no reason why there is an EntityHeader etc... and i also do
not see any requirement for an InviteMessage, AckMessage etc...

I have removed EnityHeader etc...as for the RequestMessage classes - different classes exist because the headers applicable to each are different - hence the accessor methods on each are different. I guess we could have just a RequestMessage class - with accessor methods for only the headers common to all 6 methods, and then the user/implementor has to use the generic header methods for any other headers. If this is the case, then I don't think there is any need for layering the API as mentioned. My only concern is about the Ack and Cancel Messages, which although are requests - can in a sense be thought of as being logically separate to the other requests.
 

How about if the format of the API remains as is:

jain.protocol.ip.sip
jain.protocol.ip.sip.header
jain.protocol.ip.sip.message

except that the messages available in the message package consisted of
BasicRequest/Response, MinimalRequest/Response etc... where each
message is extened in turn (e.g. Minimal extends Basic, Moderate
extends Minimal etc...), of course as Chris points out it is not hard
to see that a combination would be required that is not provided. So
in the interest of flexibility, it could be possible for the user to
plug-in to the message class what extra headers it requires.  The only
issue then is that the user will have to use a "public Header
getHeader(String headerName)" and then cast the header to their desired
header type. Either that or create their own Message class
(extending the current ones) that simply does the casting automatically
for them.  Then after compiling, run an obfuscator on the code and it
will automatically extract and only extract the Message, Headers and
even methods that are used.

This then will also cut down on the number of methods in the Provider
as there will be no need for the sendAck(AckMessage),
sendInvite(InviteMessage) etc.. as they would be replaced by the
single method sendRequest(RequestMessage).

As I mentioned above, it may be useful to keep sendAck and sendCancel in addition to sendRequest.
 

I personally see three arguments for keeping the JAIN SIP stack as small
as possible:

1) The first is for embedded applications where stack size has to be
kept to a minimum as memory is at a premium.  So if just using the
Basic message suffices then this will compile and run with a small
number of classes present from the stack.  Don't forget, obfuscation
will help in extracting only the Messages, Headers and even methods
required from a jar file but it won't do everything.

2) The second is that users may be put off or confused by the sheer
size and complexity of the JAIN stack.  So if only using the
BasicMessage gets them on the first rung of the ladder then it is a
good starting point and allows them to build up to bigger and better
things.

3) We also have to consider who is going to implement the JAIN SIP
stack. If it is indeed overly complicated then no-one or a single
vendor may end up implmenting the stack and thus its definition and
all the hard work that has gone into it is useless.

Three very good reasons for using this Public Review period to make JAIN SIP realise its full potential!
 

On Mon, 16 Oct 2000, Chris Harris wrote:
> Itamar,
>
> The idea of levelling the API based on what messages, headers and response codes
> are understood is certainly an interesting one - minimal, basic, redirection,
> firewall-friendly, negotiation, authentication and "full".
>
> jain.protocol.ip.sip
> jain.protocol.ip.sip.header
> jain.protocol.ip.sip.message
>
> could then become...
>
> jain.protocol.ip.sip - listener, provider, stack, general classes used at all
> levels
> jain.protocol.ip.sip.header - contains base Header class (and requestHeader,
> ResponseHeader, EntityHeader, GeneralHeader)
> jain.protocol.ip.sip.message - contains base Message class
>
> jain.protocol.ip.sip.minimal - general classes used only at this level and above
>
> jain.protocol.ip.sip.minimal.header - headers used only at this level and above
> jain.protocol.ip.sip.minimal.message - messages only used at this level and
> above
>
> jain.protocol.ip.sip.basic - general classes used only at this level and above
> jain.protocol.ip.sip.basic.header - headers used only at this level and above
> jain.protocol.ip.sip.basic.message - messages used only at this level and above
> ...
> ....
> jjain.protocol.ip.sip."full" - general classes only used at this level
> jain.protocol.ip.sip."full".header - headers used only at this level
> jain.protocol.ip.sip."full".message - messages used only at this level
>
> The API user could then pick the packages they need - say they initially only
> want the minimal features, but then realise they need to use their application
> behind a firewall - then they can simply add the firewall-friendly package. The
> RFC says "In general, each capability listed builds on the ones above it" but it
> is not hard to see that firewall-friendly and authentication may be desired
> without redirection for example.
>
> Is this what you hand in mind Itamar?

--
Gethin Liddell
Ubiquity Software Corporation

http://www.ubiquity.net
mailto:gethin@ubiquity.net

--------------5D45B4D41FF6E41185AA0DBC-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 18 10:44:19 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA20906 for ; Wed, 18 Oct 2000 10:44:18 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id AF64244382; Wed, 18 Oct 2000 09:38:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14]) by lists.bell-labs.com (Postfix) with ESMTP id E79D44437F for ; Wed, 18 Oct 2000 09:37:46 -0400 (EDT) Received: from fokus.gmd.de (dhcp082 [195.37.78.210]) by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id QAA08932; Wed, 18 Oct 2000 16:37:30 +0200 (MET DST) Message-ID: <39EDB55A.93360AFF@fokus.gmd.de> From: Jiri Kuthan Organization: GMD Fokus X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Joshua_Fox@vocaltec.com Cc: sip@lists.bell-labs.com Subject: Re: [SIP] SIP tunneled over HTTP References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 18 Oct 2000 16:36:10 +0200 Content-Transfer-Encoding: 7bit Actually, your idea has already been documented in draft-eastlake-ip-mime-03.txt. Jiri Joshua_Fox@vocaltec.com wrote: > > The documents at http://www.cs.columbia.edu/~hgs/sip/drafts_firewall.html > discuss the issue of SIP through firewalls at detail for SIP associated > with VoIP and similar media. Indeed, as the draft at > http://www.cs.columbia.edu/~hgs/sip/drafts/draft-rosenberg-sip-firewalls-00.txt > > points out, the main problem is not SIP but the media. > > One of the advantages of SOAP and similar protocols is to tunnel everything > over HTTP. It does get kind of silly to play a cat-and-mouse game with the > firewall administrator, but SOAP has chosen this approach (although the > possibility of yet another layer of blocking, in which the firewall can > actually block certain SOP messages, has been considered; you could take > the cat-and-mouse game one more level and tunnel firewall-forbidden SOAP > over firewall-allowed SOAP). > > Given media that themselves use HTTP, what about the possibility of > tunneling SIP over HTTP (using the usual techniques of tunneling: place SIP > headers+body as part of the body of HTTP)? There are problems. HTTP is > request-response, so we have to consider how to get notifications from > server-to-client. We could run an HTTP-server on the client too, but as the > above-mentioned draft mentions, some firewalls do not allow arbitrary > incoming HTTP to port 80. > > What I am discussing here is similar, but not identical, to the > "non-solutions" mentioned in the Section 7 of the draft. I admit it's slow, > clumsy, and bad for security, but since HTTP-tunneling is at least > reasonable enough to be considered by SOAP people, among others, I wonder > if it has been considered by SIP people. > > Joshua Fox > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip -- Jiri Kuthan http://www.fokus.gmd.de/usr/kuthan Internet Telephony: http://www.fokus.gmd.de/glone/projects/ipt _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 18 10:48:49 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA21067 for ; Wed, 18 Oct 2000 10:48:47 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id BE6A04438E; Wed, 18 Oct 2000 09:40:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 817474438D for ; Wed, 18 Oct 2000 09:39:30 -0400 (EDT) Received: from dynamicsoft.com (ip57.honxr1.ras.tele.dk [195.249.119.57]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id KAA26114; Wed, 18 Oct 2000 10:41:29 -0400 (EDT) Message-ID: <39EDB57C.B1E9BCDA@dynamicsoft.com> From: Anders Kristensen Organization: dynamicsoft X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 To: Gonzalo Camarillo Cc: SIP Subject: Re: [SIP] Route learnt out of band References: <39ED986B.A022F0AB@lmf.ericsson.se> <39EDAB64.657547E4@dynamicsoft.com> <39EDB150.9B27646B@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 18 Oct 2000 16:36:44 +0200 Content-Transfer-Encoding: 7bit Gonzalo Camarillo wrote: > > Hej Anders, Hejsa! > > Anders Kristensen wrote: > > > > This ability to perform source routing for an initial INVITE came up > > recently as a desirable feature in a slightly different context. > > As I said in my mail, there are many scenarios where this feature could > be useful. I believe this is a general mechanism with general > applicability. > Which context are you referring to? http://lists.bell-labs.com/pipermail/sip/2000q3/thread.html thread named "Outbound call routing". Explicit route used to enable services on home proxy when making calls from visited domain. -- Anders Kristensen _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 18 11:05:08 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA21363 for ; Wed, 18 Oct 2000 11:05:05 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 051E24436B; Wed, 18 Oct 2000 10:05:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 6497C44336 for ; Wed, 18 Oct 2000 10:04:34 -0400 (EDT) Received: from dynamicsoft.com (useraa51.ie.uudial.com [212.120.133.52]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id LAA26504; Wed, 18 Oct 2000 11:06:33 -0400 (EDT) Message-ID: <39EDBC08.A51790EF@dynamicsoft.com> From: Chris Harris Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: mranga@nist.gov Cc: sip@lists.bell-labs.com, discussion@sipforum.org, jainsip@sun.com, jaintech@sun.com Subject: Re: [SIP] JAIN SIP Specification References: <39EB464C.44254E5B@dynamicsoft.com> <00101814092004.10136@gethin> <39EDB3C4.282F1EFA@nist.gov> Content-Type: multipart/alternative; boundary="------------B058E6D9C333E204850D8808" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 18 Oct 2000 16:04:40 +0100 --------------B058E6D9C333E204850D8808 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi Ranga, Response below... Chris "M. Ranganathan" wrote: > JAIN-SIP is a groovy idea. Hats off to the whole concept and many thanks to Chris and > the JAIN-SIP team for putting together a spec and more flower power to them :-) . In > particular I like the notion of treating UAS, Redirect and Proxy servers as merely > special cases of the general notion of Services and the idea of unifying these > notions with an event mechanism and event handlers. Second, I like the idea of > separation between a stateless event -oriented "stack" and a bunch of event > handlers that are triggered by the stack with all state (including transaction > state) being separated from the event stack via the JAIN-SIP mapping layer if you > will. ( Correct me if I wax poetic but have the wrong understanding....) Maybe I've misunderstood what you're saying - but a JAIN SIP implementation is only stateless when it comes to call state. The JainSipProvider implementation must maintain transaction state - it simply exposes a reference to a transaction via the transaction id for the convenience of the JainSipListener. The service does not have total control over transacton state - the stack implementation does. > > > I hope I will not be viewed as being too critical, but I would like to go one step > further than what Gethin is suggesting. I am all for using interfaces as much as > possible and leaving class hierarchy definitions to implemeters. Defining class > hierarchies almost lays out an implementation and involves considerable rework for > those who have a working java-based stack, but have not used the same classes. OK it > is just a matter of labor to map things to the JAIN-SIP class hierarchy but it IS a > dis-incentive. > > 1. Lets use interfaces for all messages rather than actually define class > hierarchies ( yes Chris has pointed out the historical precedent behind actually > defining class hierarchies for messages. IMHO, there has to be a more compelling > reason than that.) I suppose all classes could be turned into interfaces, except for the Message classes which must extend java.util.EventObject to fit into the JAIN framework. > > > 2. The tie-in with the JAVA event mechanism has necessitated the explicit definition > of class hierarchies in certain places. Why not use callbacks instead and do away > with this dependency as well? (Basically the same thing as events but does not tie > into the JAVA event mechanism and its associated limitations.) Unfortunately the JAIN framework expilicitly relies on the Java Event model, and I don't think callbacks would be accepted within the JAIN community. > > > Nice work and keep it rolling! Thanks. Couldn't do it without you guys - thank you! > > > Ranga. > > Gethin Liddell wrote: > > > All, > > > > This idea of abstraction of the JAIN API is certainly a valid and > > interesting idea. However, i'm a bit concerened that the proposed > > solution of many different packages, will only seek to complicate and > > maybe enlarge the API. > > > > I too see no reason why there is an EntityHeader etc... and i also do > > not see any requirement for an InviteMessage, AckMessage etc... > > > > How about if the format of the API remains as is: > > > > jain.protocol.ip.sip > > jain.protocol.ip.sip.header > > jain.protocol.ip.sip.message > > > > except that the messages available in the message package consisted of > > BasicRequest/Response, MinimalRequest/Response etc... where each > > message is extened in turn (e.g. Minimal extends Basic, Moderate > > extends Minimal etc...), of course as Chris points out it is not hard > > to see that a combination would be required that is not provided. So > > in the interest of flexibility, it could be possible for the user to > > plug-in to the message class what extra headers it requires. The only > > issue then is that the user will have to use a "public Header > > getHeader(String headerName)" and then cast the header to their desired > > header type. Either that or create their own Message class > > (extending the current ones) that simply does the casting automatically > > for them. Then after compiling, run an obfuscator on the code and it > > will automatically extract and only extract the Message, Headers and > > even methods that are used. > > > > This then will also cut down on the number of methods in the Provider > > as there will be no need for the sendAck(AckMessage), > > sendInvite(InviteMessage) etc.. as they would be replaced by the > > single method sendRequest(RequestMessage). > > > > I personally see three arguments for keeping the JAIN SIP stack as small > > as possible: > > > > 1) The first is for embedded applications where stack size has to be > > kept to a minimum as memory is at a premium. So if just using the > > Basic message suffices then this will compile and run with a small > > number of classes present from the stack. Don't forget, obfuscation > > will help in extracting only the Messages, Headers and even methods > > required from a jar file but it won't do everything. > > > > 2) The second is that users may be put off or confused by the sheer > > size and complexity of the JAIN stack. So if only using the > > BasicMessage gets them on the first rung of the ladder then it is a > > good starting point and allows them to build up to bigger and better > > things. > > > > 3) We also have to consider who is going to implement the JAIN SIP > > stack. If it is indeed overly complicated then no-one or a single > > vendor may end up implmenting the stack and thus its definition and > > all the hard work that has gone into it is useless. > > > > On Mon, 16 Oct 2000, Chris Harris wrote: > > > Itamar, > > > > > > The idea of levelling the API based on what messages, headers and response codes > > > are understood is certainly an interesting one - minimal, basic, redirection, > > > firewall-friendly, negotiation, authentication and "full". > > > > > > jain.protocol.ip.sip > > > jain.protocol.ip.sip.header > > > jain.protocol.ip.sip.message > > > > > > could then become... > > > > > > jain.protocol.ip.sip - listener, provider, stack, general classes used at all > > > levels > > > jain.protocol.ip.sip.header - contains base Header class (and requestHeader, > > > ResponseHeader, EntityHeader, GeneralHeader) > > > jain.protocol.ip.sip.message - contains base Message class > > > > > > jain.protocol.ip.sip.minimal - general classes used only at this level and above > > > > > > jain.protocol.ip.sip.minimal.header - headers used only at this level and above > > > jain.protocol.ip.sip.minimal.message - messages only used at this level and > > > above > > > > > > jain.protocol.ip.sip.basic - general classes used only at this level and above > > > jain.protocol.ip.sip.basic.header - headers used only at this level and above > > > jain.protocol.ip.sip.basic.message - messages used only at this level and above > > > ... > > > .... > > > jjain.protocol.ip.sip."full" - general classes only used at this level > > > jain.protocol.ip.sip."full".header - headers used only at this level > > > jain.protocol.ip.sip."full".message - messages used only at this level > > > > > > The API user could then pick the packages they need - say they initially only > > > want the minimal features, but then realise they need to use their application > > > behind a firewall - then they can simply add the firewall-friendly package. The > > > RFC says "In general, each capability listed builds on the ones above it" but it > > > is not hard to see that firewall-friendly and authentication may be desired > > > without redirection for example. > > > > > > Is this what you hand in mind Itamar? > > > > -- > > Gethin Liddell > > Ubiquity Software Corporation > > > > http://www.ubiquity.net > > mailto:gethin@ubiquity.net > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > -- > M.Ranganathan > NIST Advanced Networking Technologies Group, > 100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899. > Tel: 301 975 3664 Fax: 301 590 0932 > > Hƒæj)bž b²Ôˆ>X¬¶ÆÞ–YZnÇ(šm§ÿåŠËlmée•¦ìr‰¿™¨¥™©ÿ–+-ŠwèþÈ© --------------B058E6D9C333E204850D8808 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi Ranga,

Response below...

Chris

"M. Ranganathan" wrote:

JAIN-SIP is a groovy idea. Hats off to the whole concept and many thanks to Chris and
the JAIN-SIP team for putting together a spec and more flower power to them :-) .  In
particular I like the notion of treating UAS,  Redirect and Proxy servers as merely
special cases of the general notion of Services and  the idea of  unifying these
notions with an event mechanism and  event handlers.  Second, I like the idea of
separation between a  stateless  event -oriented "stack" and a bunch of event
handlers that are triggered by the stack with all state (including  transaction
state) being separated from the event stack via the JAIN-SIP mapping layer if you
will.  ( Correct me if I  wax poetic but have the wrong understanding....)
Maybe I've misunderstood what you're saying - but a JAIN SIP implementation is only stateless when it comes to call state. The JainSipProvider implementation must maintain transaction state - it simply exposes a reference to a transaction via the transaction id for the convenience of the JainSipListener. The service does not have total control over transacton state - the stack implementation does.
 

I hope I  will not be viewed as being too critical,  but I would like to go  one step
further than what Gethin is suggesting.   I am all for using interfaces as much as
possible and leaving class hierarchy definitions to implemeters. Defining class
hierarchies almost lays out an implementation and involves considerable rework for
those who have a working java-based stack, but have not used the same classes. OK it
is just a matter of labor to map things to the JAIN-SIP class hierarchy but it  IS a
dis-incentive.

1. Lets use interfaces for all messages rather than actually define class
hierarchies  ( yes Chris has pointed out the historical precedent behind actually
defining class hierarchies for messages. IMHO,  there has to be a more compelling
reason than that.)

I suppose all classes could be turned into interfaces, except for the Message classes which must extend java.util.EventObject to fit into the JAIN framework.
 

2. The tie-in with the JAVA event mechanism has necessitated the explicit definition
of class hierarchies in certain places.  Why not use callbacks instead and do away
with this dependency as well?  (Basically the same thing as events but does not tie
into the JAVA event mechanism and its associated limitations.)

Unfortunately the JAIN framework expilicitly relies on the Java Event model, and I don't think callbacks would be accepted within the JAIN community.
 

Nice work and keep it rolling!  Thanks.

Couldn't do it without you guys - thank you!
 

Ranga.

Gethin Liddell wrote:

> All,
>
> This idea of abstraction of the JAIN API is certainly a valid and
> interesting idea.  However, i'm a bit concerened that the proposed
> solution of many different packages, will only seek to complicate and
> maybe enlarge the API.
>
> I too see no reason why there is an EntityHeader etc... and i also do
> not see any requirement for an InviteMessage, AckMessage etc...
>
> How about if the format of the API remains as is:
>
> jain.protocol.ip.sip
> jain.protocol.ip.sip.header
> jain.protocol.ip.sip.message
>
> except that the messages available in the message package consisted of
> BasicRequest/Response, MinimalRequest/Response etc... where each
> message is extened in turn (e.g. Minimal extends Basic, Moderate
> extends Minimal etc...), of course as Chris points out it is not hard
> to see that a combination would be required that is not provided. So
> in the interest of flexibility, it could be possible for the user to
> plug-in to the message class what extra headers it requires.  The only
> issue then is that the user will have to use a "public Header
> getHeader(String headerName)" and then cast the header to their desired
> header type. Either that or create their own Message class
> (extending the current ones) that simply does the casting automatically
> for them.  Then after compiling, run an obfuscator on the code and it
> will automatically extract and only extract the Message, Headers and
> even methods that are used.
>
> This then will also cut down on the number of methods in the Provider
> as there will be no need for the sendAck(AckMessage),
> sendInvite(InviteMessage) etc.. as they would be replaced by the
> single method sendRequest(RequestMessage).
>
> I personally see three arguments for keeping the JAIN SIP stack as small
> as possible:
>
> 1) The first is for embedded applications where stack size has to be
> kept to a minimum as memory is at a premium.  So if just using the
> Basic message suffices then this will compile and run with a small
> number of classes present from the stack.  Don't forget, obfuscation
> will help in extracting only the Messages, Headers and even methods
> required from a jar file but it won't do everything.
>
> 2) The second is that users may be put off or confused by the sheer
> size and complexity of the JAIN stack.  So if only using the
> BasicMessage gets them on the first rung of the ladder then it is a
> good starting point and allows them to build up to bigger and better
> things.
>
> 3) We also have to consider who is going to implement the JAIN SIP
> stack. If it is indeed overly complicated then no-one or a single
> vendor may end up implmenting the stack and thus its definition and
> all the hard work that has gone into it is useless.
>
> On Mon, 16 Oct 2000, Chris Harris wrote:
> > Itamar,
> >
> > The idea of levelling the API based on what messages, headers and response codes
> > are understood is certainly an interesting one - minimal, basic, redirection,
> > firewall-friendly, negotiation, authentication and "full".
> >
> > jain.protocol.ip.sip
> > jain.protocol.ip.sip.header
> > jain.protocol.ip.sip.message
> >
> > could then become...
> >
> > jain.protocol.ip.sip - listener, provider, stack, general classes used at all
> > levels
> > jain.protocol.ip.sip.header - contains base Header class (and requestHeader,
> > ResponseHeader, EntityHeader, GeneralHeader)
> > jain.protocol.ip.sip.message - contains base Message class
> >
> > jain.protocol.ip.sip.minimal - general classes used only at this level and above
> >
> > jain.protocol.ip.sip.minimal.header - headers used only at this level and above
> > jain.protocol.ip.sip.minimal.message - messages only used at this level and
> > above
> >
> > jain.protocol.ip.sip.basic - general classes used only at this level and above
> > jain.protocol.ip.sip.basic.header - headers used only at this level and above
> > jain.protocol.ip.sip.basic.message - messages used only at this level and above
> > ...
> > ....
> > jjain.protocol.ip.sip."full" - general classes only used at this level
> > jain.protocol.ip.sip."full".header - headers used only at this level
> > jain.protocol.ip.sip."full".message - messages used only at this level
> >
> > The API user could then pick the packages they need - say they initially only
> > want the minimal features, but then realise they need to use their application
> > behind a firewall - then they can simply add the firewall-friendly package. The
> > RFC says "In general, each capability listed builds on the ones above it" but it
> > is not hard to see that firewall-friendly and authentication may be desired
> > without redirection for example.
> >
> > Is this what you hand in mind Itamar?
>
> --
> Gethin Liddell
> Ubiquity Software Corporation
>
> http://www.ubiquity.net
> mailto:gethin@ubiquity.net
>
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip

--
M.Ranganathan
NIST Advanced Networking Technologies Group,
100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899.
Tel: 301 975 3664 Fax: 301 590 0932

Hƒæj)bž b²Ôˆ>X¬¶ÆÞ–YZnÇ(šm§ÿåŠËlmée•¦ìr‰¿™¨¥™©ÿ–+-ŠwèþÈ©

--------------B058E6D9C333E204850D8808-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 18 11:16:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA21552 for ; Wed, 18 Oct 2000 11:16:03 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C2C4C4437F; Wed, 18 Oct 2000 10:16:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by lists.bell-labs.com (Postfix) with ESMTP id B65D84437A for ; Wed, 18 Oct 2000 10:15:43 -0400 (EDT) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate2.mot.com (motgate2 2.1) with ESMTP id IAA19548 for ; Wed, 18 Oct 2000 08:15:18 -0700 (MST)] Received: [from il75exm02.cig.mot.com (IL75EXM02.cig.mot.com [136.182.110.102]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id IAA20938 for ; Wed, 18 Oct 2000 08:15:16 -0700 (MST)] Received: by IL75EXM02.cig.mot.com with Internet Mail Service (5.5.2651.58) id <4Q3R0W3L>; Wed, 18 Oct 2000 10:14:11 -0500 Message-ID: <0DF9920C9AD8D211AB0C0008C7CF1C9A04ED8530@il27exm02.cig.mot.com> From: Baniel Uri-CUB001 To: sip@lists.bell-labs.com MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] Stateful proxy Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 18 Oct 2000 10:14:08 -0500 Hello Why does a proxy that uses TCP must be stateful ? Can someone show me a scenario which went wrong because of a proxy have used a TCP and was stateless? Thanks Uri ===================== Uri Baniel Motorola Network solution Sector 1155 W. Dundee Rd Arlington Heights Tel: 847 632 4616 ===================== _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 18 11:27:10 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA21849 for ; Wed, 18 Oct 2000 11:27:08 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 405044437E; Wed, 18 Oct 2000 10:27:05 -0400 (EDT) Delivered-To: sip@share.research.bell-labs.com Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by lists.bell-labs.com (Postfix) with SMTP id B3F6944392 for ; Wed, 18 Oct 2000 09:46:06 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by dirty; Wed Oct 18 10:45:19 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 9A9A344380; Wed, 18 Oct 2000 10:32:10 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ans.ih.lucent.com (ans.ih.lucent.com [135.2.78.5]) by lists.bell-labs.com (Postfix) with SMTP id 55E6F4437D for ; Wed, 18 Oct 2000 10:32:10 -0400 (EDT) Received: by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id JAA29122; Wed, 18 Oct 2000 09:32:07 -0500 Cc: sip@lists.bell-labs.com, schulzrinne@cs.columbia.edu, P.Kossowski@elka.pw.edu.pl, Vijay Gurbani Received: from lucent.com by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id JAA29073; Wed, 18 Oct 2000 09:32:02 -0500 Message-ID: <39EDB45E.277EF9A3@lucent.com> From: "Vijay K. Gurbani" Reply-To: vkg@lucent.com Organization: Intelligent Network/Messaging Systems & Internet Software Group X-Mailer: Mozilla 4.61 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Original-CC: sip@lists.bell-labs.com, schulzrinne@cs.columbia.edu, P.Kossowski@elka.pw.edu.pl, Vijay Gurbani References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] Re: CANCEL - response sequence issue (again) Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 18 Oct 2000 09:31:58 -0500 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > > > > -----Original Message----- > > From: Vijay K. Gurbani [mailto:vkg@lucent.com] [...] > > I think the bis should, in section 4.2.5 stress that, "...If the > > server has not issued a final response for the original request, it > > immediately sends a 487 Request Terminated for the original request. > > The UAC confirms receipt of any final response for the original > > request as normal with an ACK request. CANCEL request is answered > > with a 200 OK response in either case after the original transaction > > has completed." > > > No. Counting on order is a dangerous thing. Lets say a real final > response was sent, and then a CANCEL is received (crossing the final > response on the wire). The CANCEL is received, and responded to with a > 200 OK. But, Jonathan, this should NEVER happen. If the UAS has sent out a final response AND THEN gets a CANCEL, per the bis, the CANCEL has no effect on its state; it will ignore it and NOT send a 200 OK (CSeq: xxx CANCEL). Meanwhile, the final response from the UAS arrives at the UAC, which figures out that this response is for the INVITE. Thus it knows that the CANCEL it sent out has no effect and it can kill the CANCEL transaction, formulate an ACK and send that out and clean state for the INVITE transaction as well (after 32 seconds, of course). > This 200 OK, and the final response to the request, are received in > the opposite order at the client. The result is that the client thinks > there won't be a response to the original request, even though there > is. > > The correct solution is that you cannot *depend* on the receipt of 487 > to terminate the original transaction. I think the ordering is preserved by the protocol itself. The UAS on getting a CANCEL will NOT transmit a 487 if it has already transmitted a final response prior to when the CANCEL arrived. > You need to have a timeout which, after sending CANCEL, terminates the > transaction if no final response is received before some X seconds. X > can be fairly small, since either you will get a final response right > away (modulo some packet loss), in the case of bis proxies, or never. > We have this timer set to something like 5 or 6 seconds. > > I do think the spec needs to talk about this. In fact, I recall that > it was raised on the list previously. > > I would rather say: > > For backwards compatibility with RFC2543, UACs and proxies which > generate \CANCEL \MUSTNOT assume that a 487 response to the original > transaction will be received. Instead, they \SHOULD set a timer upon > sending \CANCEL, and terminate the transaction if not response to the > original request is received after X seconds. I really don't think we need to set a timer and converge on a value for X since that is just more complexity (at least) I can do without. As far as I have worked this out, if a UAC CANCELs an INVITE and gets back 200 OK (CSeq: xxx CANCEL), it can clean state of the INVITE as well since it will not be getting 487 for sure. The response cycle for the UAS appears straightforward -- the UAS MUST NOT send out a final response to the CANCEL if it got the CANCEL *after* sending a final response to an INVITE (or for any other method -- BYE, OPTIONS, for that matter). Your comments? - vijay -- Vijay K. Gurbani vkg@lucent.com vkg@research.bell-labs.com vkg@acm.org Internet Software Group/Intelligent Network and Messaging Systems Lucent Technologies/Bell Labs Innovations, 263 Shuman Blvd, Rm 1A-413 Naperville, Illinois 60566 Voice: +1 630 224 0216 Fax: +1 630 713 0184 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 18 11:34:07 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA21922 for ; Wed, 18 Oct 2000 11:34:05 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9BD9F4436B; Wed, 18 Oct 2000 10:34:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from is1-55.antd.nist.gov (is1-60.antd.nist.gov [129.6.60.251]) by lists.bell-labs.com (Postfix) with ESMTP id 7F7884434C for ; Wed, 18 Oct 2000 10:33:31 -0400 (EDT) Received: from nist.gov (IDENT:mranga@stinkbug.antd.nist.gov [129.6.55.9]) by is1-55.antd.nist.gov (8.9.3/8.9.3) with ESMTP id LAA23762; Wed, 18 Oct 2000 11:28:54 -0400 (EDT) Message-ID: <39EDC2C5.A98A11BF@nist.gov> From: "M. Ranganathan" Reply-To: mranga@nist.gov Organization: NIST advanced networking technologies group X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Cc: discussion@sipforum.org, jainsip@sun.com, jaintech@sun.com Subject: Re: [SIP] JAIN SIP Specification References: <39EB464C.44254E5B@dynamicsoft.com> <00101814092004.10136@gethin> <39EDB3C4.282F1EFA@nist.gov> <39EDBC08.A51790EF@dynamicsoft.com> Content-Type: text/plain; charset=iso-8859-1 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 18 Oct 2000 11:33:25 -0400 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id LAA21922 Hi Chris, Thanks for replying so promptly (I am sure you are flooded with email ). As you pointed out, I suppose we cannot do away with making Messages into classes because of the tie-in with java events (unfortunately) but I still like the notion of being able to specify interfaces where ever possible. I dont quite follow the motivation behind the following design decision (excerpted from your reply): Maybe I've misunderstood what you're saying - but a JAIN SIP implementation is only stateless when it comes to call state. The JainSipProvider implementation must maintain transaction state - it simply exposes a reference to a transaction via the transaction id for the convenience of the JainSipListener. The service does not have total control over transacton state - the stack implementation does. It appears that I have indded mis-understood the architecture. Why should the above be so? Can one not rely on the JainSipListener to keep transaction state also, thereby making the stack simply a way of recognising messages and triggering event handlers on the basis of message type. This would (IMHO) be a cleaner model yet. That way, we can do away with transaction identifiers being passed back and forth and keep all of this information in the handler. ( You may have to extend the architecture somewhat to deal with timeouts and failures so that the handler knows about transaction failure.) In any case, if this is not a viable idea, I would be grateful if you can explain why not (or point me to the portion of the spec that explains why not) so I can get a better understanding. Regards, Ranga. Chris Harris wrote: > Hi Ranga, > > Response below... > > Chris > > "M. Ranganathan" wrote: > >> JAIN-SIP is a groovy idea. Hats off to the whole concept and many >> thanks to Chris and >> the JAIN-SIP team for putting together a spec and more flower power >> to them :-) . In >> particular I like the notion of treating UAS, Redirect and Proxy >> servers as merely >> special cases of the general notion of Services and the idea of >> unifying these >> notions with an event mechanism and event handlers. Second, I like >> the idea of >> separation between a stateless event -oriented "stack" and a bunch >> of event >> handlers that are triggered by the stack with all state (including >> transaction >> state) being separated from the event stack via the JAIN-SIP mapping >> layer if you >> will. ( Correct me if I wax poetic but have the wrong >> understanding....) > >> >> >> I hope I will not be viewed as being too critical, but I would >> like to go one step >> further than what Gethin is suggesting. I am all for using >> interfaces as much as >> possible and leaving class hierarchy definitions to implemeters. >> Defining class >> hierarchies almost lays out an implementation and involves >> considerable rework for >> those who have a working java-based stack, but have not used the >> same classes. OK it >> is just a matter of labor to map things to the JAIN-SIP class >> hierarchy but it IS a >> dis-incentive. >> >> 1. Lets use interfaces for all messages rather than actually define >> class >> hierarchies ( yes Chris has pointed out the historical precedent >> behind actually >> defining class hierarchies for messages. IMHO, there has to be a >> more compelling >> reason than that.) > > I suppose all classes could be turned into interfaces, except for the > Message classes which must extend java.util.EventObject to fit into > the JAIN framework. > >> >> >> 2. The tie-in with the JAVA event mechanism has necessitated the >> explicit definition >> of class hierarchies in certain places. Why not use callbacks >> instead and do away >> with this dependency as well? (Basically the same thing as events >> but does not tie >> into the JAVA event mechanism and its associated limitations.) > > Unfortunately the JAIN framework expilicitly relies on the Java Event > model, and I don't think callbacks would be accepted within the JAIN > community. > >> >> >> Nice work and keep it rolling! Thanks. > > Couldn't do it without you guys - thank you! > >> >> >> Ranga. >> >> Gethin Liddell wrote: >> >> > All, >> > >> > This idea of abstraction of the JAIN API is certainly a valid and >> > interesting idea. However, i'm a bit concerened that the proposed >> >> > solution of many different packages, will only seek to complicate >> and >> > maybe enlarge the API. >> > >> > I too see no reason why there is an EntityHeader etc... and i also >> do >> > not see any requirement for an InviteMessage, AckMessage etc... >> > >> > How about if the format of the API remains as is: >> > >> > jain.protocol.ip.sip >> > jain.protocol.ip.sip.header >> > jain.protocol.ip.sip.message >> > >> > except that the messages available in the message package >> consisted of >> > BasicRequest/Response, MinimalRequest/Response etc... where each >> > message is extened in turn (e.g. Minimal extends Basic, Moderate >> > extends Minimal etc...), of course as Chris points out it is not >> hard >> > to see that a combination would be required that is not provided. >> So >> > in the interest of flexibility, it could be possible for the user >> to >> > plug-in to the message class what extra headers it requires. The >> only >> > issue then is that the user will have to use a "public Header >> > getHeader(String headerName)" and then cast the header to their >> desired >> > header type. Either that or create their own Message class >> > (extending the current ones) that simply does the casting >> automatically >> > for them. Then after compiling, run an obfuscator on the code and >> it >> > will automatically extract and only extract the Message, Headers >> and >> > even methods that are used. >> > >> > This then will also cut down on the number of methods in the >> Provider >> > as there will be no need for the sendAck(AckMessage), >> > sendInvite(InviteMessage) etc.. as they would be replaced by the >> > single method sendRequest(RequestMessage). >> > >> > I personally see three arguments for keeping the JAIN SIP stack as >> small >> > as possible: >> > >> > 1) The first is for embedded applications where stack size has to >> be >> > kept to a minimum as memory is at a premium. So if just using the >> >> > Basic message suffices then this will compile and run with a small >> >> > number of classes present from the stack. Don't forget, >> obfuscation >> > will help in extracting only the Messages, Headers and even >> methods >> > required from a jar file but it won't do everything. >> > >> > 2) The second is that users may be put off or confused by the >> sheer >> > size and complexity of the JAIN stack. So if only using the >> > BasicMessage gets them on the first rung of the ladder then it is >> a >> > good starting point and allows them to build up to bigger and >> better >> > things. >> > >> > 3) We also have to consider who is going to implement the JAIN SIP >> >> > stack. If it is indeed overly complicated then no-one or a single >> > vendor may end up implmenting the stack and thus its definition >> and >> > all the hard work that has gone into it is useless. >> > >> > On Mon, 16 Oct 2000, Chris Harris wrote: >> > > Itamar, >> > > >> > > The idea of levelling the API based on what messages, headers >> and response codes >> > > are understood is certainly an interesting one - minimal, basic, >> redirection, >> > > firewall-friendly, negotiation, authentication and "full". >> > > >> > > jain.protocol.ip.sip >> > > jain.protocol.ip.sip.header >> > > jain.protocol.ip.sip.message >> > > >> > > could then become... >> > > >> > > jain.protocol.ip.sip - listener, provider, stack, general >> classes used at all >> > > levels >> > > jain.protocol.ip.sip.header - contains base Header class (and >> requestHeader, >> > > ResponseHeader, EntityHeader, GeneralHeader) >> > > jain.protocol.ip.sip.message - contains base Message class >> > > >> > > jain.protocol.ip.sip.minimal - general classes used only at this >> level and above >> > > >> > > jain.protocol.ip.sip.minimal.header - headers used only at this >> level and above >> > > jain.protocol.ip.sip.minimal.message - messages only used at >> this level and >> > > above >> > > >> > > jain.protocol.ip.sip.basic - general classes used only at this >> level and above >> > > jain.protocol.ip.sip.basic.header - headers used only at this >> level and above >> > > jain.protocol.ip.sip.basic.message - messages used only at this >> level and above >> > > ... >> > > .... >> > > jjain.protocol.ip.sip."full" - general classes only used at this >> level >> > > jain.protocol.ip.sip."full".header - headers used only at this >> level >> > > jain.protocol.ip.sip."full".message - messages used only at this >> level >> > > >> > > The API user could then pick the packages they need - say they >> initially only >> > > want the minimal features, but then realise they need to use >> their application >> > > behind a firewall - then they can simply add the >> firewall-friendly package. The >> > > RFC says "In general, each capability listed builds on the ones >> above it" but it >> > > is not hard to see that firewall-friendly and authentication may >> be desired >> > > without redirection for example. >> > > >> > > Is this what you hand in mind Itamar? >> > >> > -- >> > Gethin Liddell >> > Ubiquity Software Corporation >> > >> > http://www.ubiquity.net >> > mailto:gethin@ubiquity.net >> > >> > _______________________________________________ >> > SIP mailing list >> > SIP@lists.bell-labs.com >> > http://lists.bell-labs.com/mailman/listinfo/sip >> >> -- >> M.Ranganathan >> NIST Advanced Networking Technologies Group, >> 100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899. >> Tel: 301 975 3664 Fax: 301 590 0932 >> >> Hfæj)b? b²Ô^>X¬¶ÆÞ-YZnÇ(sm§ÿåSËlmée*¦ìr?¿?¨¥?©ÿ-+-SwèþÈ© > -- M.Ranganathan NIST Advanced Networking Technologies Group, 100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899. Tel: 301 975 3664 Fax: 301 590 0932 ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÒ ùšŠX§‚X¬µ"þX¬¶ÏÛzYÿ•¦ìýÊ&†ÛiÿÿåŠËlý·¥—ùZnÏÜ¢oæj)fjåŠËbú? From sip-admin@lists.bell-labs.com Wed Oct 18 11:58:06 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA22400 for ; Wed, 18 Oct 2000 11:58:04 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 59D4E4436B; Wed, 18 Oct 2000 10:58:04 -0400 (EDT) Delivered-To: sip@share.research.bell-labs.com Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by lists.bell-labs.com (Postfix) with SMTP id EFBEF4436B for ; Wed, 18 Oct 2000 10:50:06 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Wed Oct 18 11:48:44 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 0C44044380; Wed, 18 Oct 2000 11:35:35 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ans.ih.lucent.com (ans.ih.lucent.com [135.2.78.5]) by lists.bell-labs.com (Postfix) with SMTP id B5D4D4437D for ; Wed, 18 Oct 2000 11:35:34 -0400 (EDT) Received: by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id KAA25495; Wed, 18 Oct 2000 10:35:31 -0500 To: Jonathan Rosenberg , sip@lists.bell-labs.com, Vijay Gurbani Received: from lucent.com by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id KAA25456; Wed, 18 Oct 2000 10:35:29 -0500 Message-ID: <39EDC33D.C9452170@lucent.com> From: "Vijay K. Gurbani" Reply-To: vkg@lucent.com Organization: Intelligent Network/Messaging Systems & Internet Software Group X-Mailer: Mozilla 4.61 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 Original-To: Jonathan Rosenberg , sip@lists.bell-labs.com, Vijay Gurbani References: <39EDB45E.277EF9A3@lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] Re: CANCEL - response sequence issue (again) Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 18 Oct 2000 10:35:25 -0500 Content-Transfer-Encoding: 7bit "Vijay K. Gurbani" wrote: [...] > > Jonathan Rosenberg wrote: > > No. Counting on order is a dangerous thing. Lets say a real final > > response was sent, and then a CANCEL is received (crossing the final > > response on the wire). The CANCEL is received, and responded to with > > a 200 OK. [...] > But, Jonathan, this should NEVER happen. If the UAS has sent out a > final response AND THEN gets a CANCEL, per the bis, the CANCEL has no > effect on its state; it will ignore it and NOT send a 200 OK (CSeq: > xxx CANCEL). Hmmm...on closer introspection, my fault (should have read the draft more carefully). While the CANCEL has no effect on the UAS's call state, the UAS *does* sent out a 200 OK (CSeq: xxx CANCEL). So, the scenario Jonathan described about the 200 OK (CSeq: xxx CANCEL) arriving before the final response to the original transaction holds, as does the solution he described of waiting X seconds after getting the 200 OK (CSeq: xxx CANCEL). To paraphrase what someone said on the list a while ago, "Jonathan, you're the man" :-) Regards, - vijay -- Vijay K. Gurbani vkg@lucent.com vkg@research.bell-labs.com vkg@acm.org Internet Software Group/Intelligent Network and Messaging Systems Lucent Technologies/Bell Labs Innovations, 263 Shuman Blvd, Rm 1A-413 Naperville, Illinois 60566 Voice: +1 630 224 0216 Fax: +1 630 713 0184 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 18 12:06:09 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA22674 for ; Wed, 18 Oct 2000 12:06:05 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2AB5744377; Wed, 18 Oct 2000 11:06:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from drago1.ubiquity.net (unknown [194.202.146.92]) by lists.bell-labs.com (Postfix) with SMTP id E13764434C for ; Wed, 18 Oct 2000 11:05:32 -0400 (EDT) Received: from gecko.ubiquity.co.uk by drago1.ubiquity.net via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 18 Oct 2000 16:06:01 UT Received: from gethin by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id RAA03618; Wed, 18 Oct 2000 17:03:46 +0100 (BST) From: Gethin Liddell Organization: Ubiquity Software Corp. To: Chris Harris , Billy Biggs Subject: Re: [SIP] Re: JAIN SIP Comments X-Mailer: KMail [version 1.0.29.2] Content-Type: text/plain Cc: jainsip@sun.com, sip@lists.bell-labs.com, discussion@sipforum.org References: <20001017145531.A2803@div8.net> <39EDAD8D.6EC60BC6@dynamicsoft.com> In-Reply-To: <39EDAD8D.6EC60BC6@dynamicsoft.com> MIME-Version: 1.0 Message-Id: <00101817034505.10136@gethin> Content-Transfer-Encoding: 8bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 18 Oct 2000 15:15:01 +0100 Content-Transfer-Encoding: 8bit On Wed, 18 Oct 2000, Chris Harris wrote: > > Billy Biggs wrote: > > > The same is true of the call-id. Why bother having a method to > > extract the host portion of the call-id? It's unlikely this will be > > required separately, and implementations are supposed to treat the > > call-id as an opaque string anyways. > > Indeed CallIdHeader could uses a String value too. I am considering removing the > Challenge and Credential classes and replacing them in the > authenticate/authorization headers with just a scheme String and a > challenge/credentials String (or Parameters object mentioned below?). This will > mean the implementation won't have to understand the schemes. What do you think? Will this work for WWWAuthentication and the other multi valued authentication headers? Unfortunately the challenge and credential values use a `,' separated parameter list so if two different values are in the same header there will be no way of knowing where the first stops and the second starts. So any implemenetation will have to know and understand the different schemes. > > > > > > > One thing I noticed was that the object hierarchy does not take into > > account the contents of the headers but rather the structure of a > > message. > > I have removed GeneralHeader, EntityHeader, RequestHeader and ResponseHeader - > removing a layer in the header hierarchy. Now the API just relies on a header > type parameter to the Header constructor. > > > > > > > For example, there isn't much difference at all between the Contact, > > Record-Route, Route, and even the To and From in a SIP message. Each of > > these contains a NameAddress along with some header parameters. Why not > > have them inherit from a common base class? I guess you're trying to > > just make the object as generic as possible without enforcing an object > > model on the stack behind it, but still, why not make a parametered uri > > object to represent this? > > I have created a NameAddressParameters class - which is composed of a > NameAddress and a Hashtable for parameters (get, set, has and remove methods are > included for parameters). I have also created a NameAddressHeader base class for > all the headers you mention above - so the generic parameter and NameAddress > methods are avilable to all subclasses - FromHeader, ToHeader, ContactHeader, > RecordRouteHeader and RouteHeader. > > > > > Why have both a ToHeader and a FromHeader object if they're exactly > > the same? > > I could add a superclass for these two classes - with the classes only differing > in option tag. Can you think of an appropriate name for such a class? I'm a bit concerened that we are going down the path here of specifying an implementation as opposed to an API. Is it not acceptable to define that the To and From headers have certain methods, even if they are actually provided by some common base class? Don't forget, the API is supposed to be a thin wrapper around existing implmentations and not a re-write. > > > > > > Also, it's interesting to see how you have a ContentTypeHeader object > > instead of a more general MimeContentType object. It seems to me that > > something so generic should be outside of the scope of a SIP stack. > > > > The last object I'd think would be useful would be some sort of > > ParameterList object. It would help to avoid problems like your > > ViaHeader object, which is missing calls to set or retrieve extension > > parameters. > > This is so obvious it was bound to be be overlooked :) This Parameters object > could be used in SipURL and Header class - making NameAddressParameters class > obsolete. I'm just thinking about parameters for the encryption and response key > headers - they use a comma as a delimiter not a semi-colon and need a space > before them - should they be treated independently, or should the Parameters > object know which delimiter type it uses and whether it needs spaces in front? > Also the via header allows a comment between via params and extension params - > so should the ViaHeader class have another Parameters object specifically for > via params? Wouldn't SIP have been so much easier if the parameters all used the > same syntax? :) Absolutely!!!!!! Unfortunately, the authentication is just grabbed from the HTTP spec with no modifications so we're just lumbered with it. However, the questions you ask here again, i feel are getting far too implementation specific. I think that the access to the parameters should remiain solely in the form of access calls to the header. So to grab future parameters, we just need a "public String getParameter(String paramName)" method. In fact I see no need for a getTag(), getTTL() etc... would the getParameter(String) not suffice. And i definitely do not think we should be throwing Eexceptions if a getParameter() is made and it does not exist. just return null. IMHO it is a lot more elegant than having a lot of try catchs everywhere and more efficient as no Exception classes have to be created. Also is there a real need for hasBranch()? just check for null. It is easy enough and perfectly acceptable and cuts down drastically on the number of methods. in fact taking via as an example, we could cut the number of methods by 19 if we got rid of all the remove methods as well. So could we not replace all the getPARAMETER() with a single getParameter(String name), all the hasPARAMETER() with the fact that null defines no parameter exists and the removePARAMETER() with a setPARAMETER(null) (although i accept this last suggestion may be a little off the wall) I'm also tempted to get rid off all the setPARAMETER(String) methods and replace with a single setParameter(String name, String value) although i can't find an acceptable way to enforce type checking. Talking of which, how is type checking handled when read from the network? What if we receive a message with an invalid Authentication header for example? How is the stack supposed to relay that information back to the user when they ask for the Authentication header? Going onto another topic, I really, really, don't think it is a good idea to use InetAddress within the parsing of the message. Take the SipURL object, it has a "public InetAddress getHost()" method. This seems a bit bizarre to me as creating an InetAddress forces the JVM to do a DNS lookup. So if say we have a proxy that is using this stack and it recieves a request-uri with an address sip:bob@host.com then just trying to get at the host will cause a blocking dns lookup. The proxy may well have its own asynchronous dns solution and never use InetAddress until it has obtained an IPAddress itself. So using InetAddress seriously hampers the performance of the proxy. Also it may be the case that host.com is not actually a valid resolvable domain but is really intended to mean something to the proxy server to force some action. If it fails with an UnknownHostException what then? I think InetAddress should be removed from all getXXX() methods, eg. Via - getMAddr() getHost() getReceived(). Using it to set say the SipUrl in the To is valid but should not be the only constructor. We need a SipURL(String name, String host) constructor. -- Gethin Liddell Ubiquity Software Corporation http://www.ubiquity.net mailto:gethin@ubiquity.net _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 18 12:28:14 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA25974 for ; Wed, 18 Oct 2000 12:28:07 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 368254434C; Wed, 18 Oct 2000 11:28:06 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 0275F44336 for ; Wed, 18 Oct 2000 11:27:25 -0400 (EDT) Received: from dynamicsoft.com (userac41.ie.uudial.com [212.120.133.240]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id MAA27533; Wed, 18 Oct 2000 12:29:24 -0400 (EDT) Message-ID: <39EDCF73.42981937@dynamicsoft.com> From: Chris Harris Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: mranga@nist.gov Cc: sip@lists.bell-labs.com, discussion@sipforum.org, jainsip@sun.com Subject: Re: [SIP] JAIN SIP Specification References: <39EB464C.44254E5B@dynamicsoft.com> <00101814092004.10136@gethin> <39EDB3C4.282F1EFA@nist.gov> <39EDBC08.A51790EF@dynamicsoft.com> <39EDC2C5.A98A11BF@nist.gov> Content-Type: multipart/alternative; boundary="------------39569E68F11A897AB4A16251" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 18 Oct 2000 17:27:31 +0100 --------------39569E68F11A897AB4A16251 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit "M. Ranganathan" wrote: > Hi Chris, > > Thanks for replying so promptly (I am sure you are flooded with email ). I get one or two :) > > As you pointed out, I suppose we cannot do away with making Messages > into classes because of the tie-in with java events (unfortunately) but > I still like the notion of being able to specify interfaces where ever > possible. I see where you're coming from alright, and I suppose changing header classes into interfaces, could fit in with Gethin's proposal nicely? > > I dont quite follow the motivation behind the following design > decision (excerpted from your reply): > > Maybe I've misunderstood what you're saying - but a JAIN SIP > implementation is only stateless when it comes to call state. The > JainSipProvider implementation must maintain transaction state - it > simply exposes a reference to a transaction via the transaction id for > the convenience of the JainSipListener. The service does not have total > control over transacton state - the stack implementation does. > > It appears that I have indded mis-understood the architecture. Why > should the above be so? Can one not rely on the JainSipListener to keep > transaction state also, thereby making the stack simply a way of > recognising messages and triggering event handlers on the basis of > message type. This would (IMHO) be a cleaner model yet. That way, we > can do away with transaction identifiers being passed back and forth and > keep all of this information in the handler. ( You may have to extend > the architecture somewhat to deal with timeouts and failures so that the > handler knows about transaction failure.) In any case, if this is not a > viable idea, I would be grateful if you can explain why not (or point me > to the portion of the spec that explains why not) so I can get a better > understanding. It would be cleaner model, and personally I am in total agreement with you - but it means the application is forced to maintain transaction state, match up headers - which has been said places too much of a burden on applications. How about finding a way to let the application choose whether or not it wants to keep transaction state? > > > Regards, > > Ranga. > > Chris Harris wrote: > > > Hi Ranga, > > > > Response below... > > > > Chris > > > > "M. Ranganathan" wrote: > > > >> JAIN-SIP is a groovy idea. Hats off to the whole concept and many > >> thanks to Chris and > >> the JAIN-SIP team for putting together a spec and more flower power > >> to them :-) . In > >> particular I like the notion of treating UAS, Redirect and Proxy > >> servers as merely > >> special cases of the general notion of Services and the idea of > >> unifying these > >> notions with an event mechanism and event handlers. Second, I like > >> the idea of > >> separation between a stateless event -oriented "stack" and a bunch > >> of event > >> handlers that are triggered by the stack with all state (including > >> transaction > >> state) being separated from the event stack via the JAIN-SIP mapping > >> layer if you > >> will. ( Correct me if I wax poetic but have the wrong > >> understanding....) > > > >> > >> > >> I hope I will not be viewed as being too critical, but I would > >> like to go one step > >> further than what Gethin is suggesting. I am all for using > >> interfaces as much as > >> possible and leaving class hierarchy definitions to implemeters. > >> Defining class > >> hierarchies almost lays out an implementation and involves > >> considerable rework for > >> those who have a working java-based stack, but have not used the > >> same classes. OK it > >> is just a matter of labor to map things to the JAIN-SIP class > >> hierarchy but it IS a > >> dis-incentive. > >> > >> 1. Lets use interfaces for all messages rather than actually define > >> class > >> hierarchies ( yes Chris has pointed out the historical precedent > >> behind actually > >> defining class hierarchies for messages. IMHO, there has to be a > >> more compelling > >> reason than that.) > > > > I suppose all classes could be turned into interfaces, except for the > > Message classes which must extend java.util.EventObject to fit into > > the JAIN framework. > > > >> > >> > >> 2. The tie-in with the JAVA event mechanism has necessitated the > >> explicit definition > >> of class hierarchies in certain places. Why not use callbacks > >> instead and do away > >> with this dependency as well? (Basically the same thing as events > >> but does not tie > >> into the JAVA event mechanism and its associated limitations.) > > > > Unfortunately the JAIN framework expilicitly relies on the Java Event > > model, and I don't think callbacks would be accepted within the JAIN > > community. > > > >> > >> > >> Nice work and keep it rolling! Thanks. > > > > Couldn't do it without you guys - thank you! > > > >> > >> > >> Ranga. > >> > >> Gethin Liddell wrote: > >> > >> > All, > >> > > >> > This idea of abstraction of the JAIN API is certainly a valid and > >> > interesting idea. However, i'm a bit concerened that the proposed > >> > >> > solution of many different packages, will only seek to complicate > >> and > >> > maybe enlarge the API. > >> > > >> > I too see no reason why there is an EntityHeader etc... and i also > >> do > >> > not see any requirement for an InviteMessage, AckMessage etc... > >> > > >> > How about if the format of the API remains as is: > >> > > >> > jain.protocol.ip.sip > >> > jain.protocol.ip.sip.header > >> > jain.protocol.ip.sip.message > >> > > >> > except that the messages available in the message package > >> consisted of > >> > BasicRequest/Response, MinimalRequest/Response etc... where each > >> > message is extened in turn (e.g. Minimal extends Basic, Moderate > >> > extends Minimal etc...), of course as Chris points out it is not > >> hard > >> > to see that a combination would be required that is not provided. > >> So > >> > in the interest of flexibility, it could be possible for the user > >> to > >> > plug-in to the message class what extra headers it requires. The > >> only > >> > issue then is that the user will have to use a "public Header > >> > getHeader(String headerName)" and then cast the header to their > >> desired > >> > header type. Either that or create their own Message class > >> > (extending the current ones) that simply does the casting > >> automatically > >> > for them. Then after compiling, run an obfuscator on the code and > >> it > >> > will automatically extract and only extract the Message, Headers > >> and > >> > even methods that are used. > >> > > >> > This then will also cut down on the number of methods in the > >> Provider > >> > as there will be no need for the sendAck(AckMessage), > >> > sendInvite(InviteMessage) etc.. as they would be replaced by the > >> > single method sendRequest(RequestMessage). > >> > > >> > I personally see three arguments for keeping the JAIN SIP stack as > >> small > >> > as possible: > >> > > >> > 1) The first is for embedded applications where stack size has to > >> be > >> > kept to a minimum as memory is at a premium. So if just using the > >> > >> > Basic message suffices then this will compile and run with a small > >> > >> > number of classes present from the stack. Don't forget, > >> obfuscation > >> > will help in extracting only the Messages, Headers and even > >> methods > >> > required from a jar file but it won't do everything. > >> > > >> > 2) The second is that users may be put off or confused by the > >> sheer > >> > size and complexity of the JAIN stack. So if only using the > >> > BasicMessage gets them on the first rung of the ladder then it is > >> a > >> > good starting point and allows them to build up to bigger and > >> better > >> > things. > >> > > >> > 3) We also have to consider who is going to implement the JAIN SIP > >> > >> > stack. If it is indeed overly complicated then no-one or a single > >> > vendor may end up implmenting the stack and thus its definition > >> and > >> > all the hard work that has gone into it is useless. > >> > > >> > On Mon, 16 Oct 2000, Chris Harris wrote: > >> > > Itamar, > >> > > > >> > > The idea of levelling the API based on what messages, headers > >> and response codes > >> > > are understood is certainly an interesting one - minimal, basic, > >> redirection, > >> > > firewall-friendly, negotiation, authentication and "full". > >> > > > >> > > jain.protocol.ip.sip > >> > > jain.protocol.ip.sip.header > >> > > jain.protocol.ip.sip.message > >> > > > >> > > could then become... > >> > > > >> > > jain.protocol.ip.sip - listener, provider, stack, general > >> classes used at all > >> > > levels > >> > > jain.protocol.ip.sip.header - contains base Header class (and > >> requestHeader, > >> > > ResponseHeader, EntityHeader, GeneralHeader) > >> > > jain.protocol.ip.sip.message - contains base Message class > >> > > > >> > > jain.protocol.ip.sip.minimal - general classes used only at this > >> level and above > >> > > > >> > > jain.protocol.ip.sip.minimal.header - headers used only at this > >> level and above > >> > > jain.protocol.ip.sip.minimal.message - messages only used at > >> this level and > >> > > above > >> > > > >> > > jain.protocol.ip.sip.basic - general classes used only at this > >> level and above > >> > > jain.protocol.ip.sip.basic.header - headers used only at this > >> level and above > >> > > jain.protocol.ip.sip.basic.message - messages used only at this > >> level and above > >> > > ... > >> > > .... > >> > > jjain.protocol.ip.sip."full" - general classes only used at this > >> level > >> > > jain.protocol.ip.sip."full".header - headers used only at this > >> level > >> > > jain.protocol.ip.sip."full".message - messages used only at this > >> level > >> > > > >> > > The API user could then pick the packages they need - say they > >> initially only > >> > > want the minimal features, but then realise they need to use > >> their application > >> > > behind a firewall - then they can simply add the > >> firewall-friendly package. The > >> > > RFC says "In general, each capability listed builds on the ones > >> above it" but it > >> > > is not hard to see that firewall-friendly and authentication may > >> be desired > >> > > without redirection for example. > >> > > > >> > > Is this what you hand in mind Itamar? > >> > > >> > -- > >> > Gethin Liddell > >> > Ubiquity Software Corporation > >> > > >> > http://www.ubiquity.net > >> > mailto:gethin@ubiquity.net > >> > > >> > _______________________________________________ > >> > SIP mailing list > >> > SIP@lists.bell-labs.com > >> > http://lists.bell-labs.com/mailman/listinfo/sip > >> > >> -- > >> M.Ranganathan > >> NIST Advanced Networking Technologies Group, > >> 100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899. > >> Tel: 301 975 3664 Fax: 301 590 0932 > >> > >> Hfæj)b? b²Ô^>X¬¶ÆÞ-YZnÇ(sm§ÿåSËlmée*¦ìr?¿?¨¥?©ÿ-+-SwèþÈ© > > > > -- > M.Ranganathan > NIST Advanced Networking Technologies Group, > 100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899. > Tel: 301 975 3664 Fax: 301 590 0932 > > Hƒæj)bž b²Ôˆ>X¬¶ÆÞ–YZnÇ(šm§ÿåŠËlmée•¦ìr‰¿™¨¥™©ÿ–+-ŠwèþÈ© --------------39569E68F11A897AB4A16251 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit "M. Ranganathan" wrote:
Hi Chris,

Thanks for replying so promptly (I am sure you are flooded with email ).

I get one or two :)
 
As you pointed out, I suppose we cannot do away with making Messages
into classes because of the tie-in with java events (unfortunately) but
I still like the notion of being able to specify  interfaces where ever
possible.
I see where you're coming from alright, and I suppose changing header classes into interfaces, could fit in with Gethin's proposal nicely?
 
 I dont quite follow  the motivation behind the following design
decision (excerpted from your reply):

Maybe I've misunderstood what you're saying - but a JAIN SIP
implementation is only stateless when it comes to call state. The
JainSipProvider implementation must maintain transaction state - it
simply exposes a reference to a transaction via the transaction id for
the convenience of the JainSipListener. The service does not have total
control over transacton state - the stack implementation does.

It appears that I have indded mis-understood the architecture.  Why
should the above be so? Can one not rely on the JainSipListener to keep
transaction state also, thereby making the stack simply a way of
recognising messages and triggering  event handlers on the basis of
message type. This would (IMHO) be a cleaner model yet.    That way,  we
can do away with transaction identifiers being passed back and forth and
keep all of this information in the handler.  ( You may have to extend
the architecture somewhat to deal with timeouts and failures so that the
handler knows about transaction failure.) In any case, if this is not a
viable idea, I would be grateful if you can explain why not (or point me
to the portion of the spec that explains why not) so I can get a better
understanding.

It would be cleaner model, and personally I am in total agreement with you - but it means the application is forced to maintain transaction state, match up headers - which has been said places too much of a burden on applications. How about finding a way to let the application choose whether or not it wants to keep transaction state?
 

Regards,

Ranga.

Chris Harris wrote:

> Hi Ranga,
>
> Response below...
>
> Chris
>
> "M. Ranganathan" wrote:
>
>> JAIN-SIP is a groovy idea. Hats off to the whole concept and many
>> thanks to Chris and
>> the JAIN-SIP team for putting together a spec and more flower power
>> to them :-) .  In
>> particular I like the notion of treating UAS,  Redirect and Proxy
>> servers as merely
>> special cases of the general notion of Services and  the idea of
>> unifying these
>> notions with an event mechanism and  event handlers.  Second, I like
>> the idea of
>> separation between a  stateless  event -oriented "stack" and a bunch
>> of event
>> handlers that are triggered by the stack with all state (including
>> transaction
>> state) being separated from the event stack via the JAIN-SIP mapping
>> layer if you
>> will.  ( Correct me if I  wax poetic but have the wrong
>> understanding....)
>
>>
>>
>> I hope I  will not be viewed as being too critical,  but I would
>> like to go  one step
>> further than what Gethin is suggesting.   I am all for using
>> interfaces as much as
>> possible and leaving class hierarchy definitions to implemeters.
>> Defining class
>> hierarchies almost lays out an implementation and involves
>> considerable rework for
>> those who have a working java-based stack, but have not used the
>> same classes. OK it
>> is just a matter of labor to map things to the JAIN-SIP class
>> hierarchy but it  IS a
>> dis-incentive.
>>
>> 1. Lets use interfaces for all messages rather than actually define
>> class
>> hierarchies  ( yes Chris has pointed out the historical precedent
>> behind actually
>> defining class hierarchies for messages. IMHO,  there has to be a
>> more compelling
>> reason than that.)
>
> I suppose all classes could be turned into interfaces, except for the
> Message classes which must extend java.util.EventObject to fit into
> the JAIN framework.
>
>>
>>
>> 2. The tie-in with the JAVA event mechanism has necessitated the
>> explicit definition
>> of class hierarchies in certain places.  Why not use callbacks
>> instead and do away
>> with this dependency as well?  (Basically the same thing as events
>> but does not tie
>> into the JAVA event mechanism and its associated limitations.)
>
> Unfortunately the JAIN framework expilicitly relies on the Java Event
> model, and I don't think callbacks would be accepted within the JAIN
> community.
>
>>
>>
>> Nice work and keep it rolling!  Thanks.
>
> Couldn't do it without you guys - thank you!
>
>>
>>
>> Ranga.
>>
>> Gethin Liddell wrote:
>>
>> > All,
>> >
>> > This idea of abstraction of the JAIN API is certainly a valid and
>> > interesting idea.  However, i'm a bit concerened that the proposed
>>
>> > solution of many different packages, will only seek to complicate
>> and
>> > maybe enlarge the API.
>> >
>> > I too see no reason why there is an EntityHeader etc... and i also
>> do
>> > not see any requirement for an InviteMessage, AckMessage etc...
>> >
>> > How about if the format of the API remains as is:
>> >
>> > jain.protocol.ip.sip
>> > jain.protocol.ip.sip.header
>> > jain.protocol.ip.sip.message
>> >
>> > except that the messages available in the message package
>> consisted of
>> > BasicRequest/Response, MinimalRequest/Response etc... where each
>> > message is extened in turn (e.g. Minimal extends Basic, Moderate
>> > extends Minimal etc...), of course as Chris points out it is not
>> hard
>> > to see that a combination would be required that is not provided.
>> So
>> > in the interest of flexibility, it could be possible for the user
>> to
>> > plug-in to the message class what extra headers it requires.  The
>> only
>> > issue then is that the user will have to use a "public Header
>> > getHeader(String headerName)" and then cast the header to their
>> desired
>> > header type. Either that or create their own Message class
>> > (extending the current ones) that simply does the casting
>> automatically
>> > for them.  Then after compiling, run an obfuscator on the code and
>> it
>> > will automatically extract and only extract the Message, Headers
>> and
>> > even methods that are used.
>> >
>> > This then will also cut down on the number of methods in the
>> Provider
>> > as there will be no need for the sendAck(AckMessage),
>> > sendInvite(InviteMessage) etc.. as they would be replaced by the
>> > single method sendRequest(RequestMessage).
>> >
>> > I personally see three arguments for keeping the JAIN SIP stack as
>> small
>> > as possible:
>> >
>> > 1) The first is for embedded applications where stack size has to
>> be
>> > kept to a minimum as memory is at a premium.  So if just using the
>>
>> > Basic message suffices then this will compile and run with a small
>>
>> > number of classes present from the stack.  Don't forget,
>> obfuscation
>> > will help in extracting only the Messages, Headers and even
>> methods
>> > required from a jar file but it won't do everything.
>> >
>> > 2) The second is that users may be put off or confused by the
>> sheer
>> > size and complexity of the JAIN stack.  So if only using the
>> > BasicMessage gets them on the first rung of the ladder then it is
>> a
>> > good starting point and allows them to build up to bigger and
>> better
>> > things.
>> >
>> > 3) We also have to consider who is going to implement the JAIN SIP
>>
>> > stack. If it is indeed overly complicated then no-one or a single
>> > vendor may end up implmenting the stack and thus its definition
>> and
>> > all the hard work that has gone into it is useless.
>> >
>> > On Mon, 16 Oct 2000, Chris Harris wrote:
>> > > Itamar,
>> > >
>> > > The idea of levelling the API based on what messages, headers
>> and response codes
>> > > are understood is certainly an interesting one - minimal, basic,
>> redirection,
>> > > firewall-friendly, negotiation, authentication and "full".
>> > >
>> > > jain.protocol.ip.sip
>> > > jain.protocol.ip.sip.header
>> > > jain.protocol.ip.sip.message
>> > >
>> > > could then become...
>> > >
>> > > jain.protocol.ip.sip - listener, provider, stack, general
>> classes used at all
>> > > levels
>> > > jain.protocol.ip.sip.header - contains base Header class (and
>> requestHeader,
>> > > ResponseHeader, EntityHeader, GeneralHeader)
>> > > jain.protocol.ip.sip.message - contains base Message class
>> > >
>> > > jain.protocol.ip.sip.minimal - general classes used only at this
>> level and above
>> > >
>> > > jain.protocol.ip.sip.minimal.header - headers used only at this
>> level and above
>> > > jain.protocol.ip.sip.minimal.message - messages only used at
>> this level and
>> > > above
>> > >
>> > > jain.protocol.ip.sip.basic - general classes used only at this
>> level and above
>> > > jain.protocol.ip.sip.basic.header - headers used only at this
>> level and above
>> > > jain.protocol.ip.sip.basic.message - messages used only at this
>> level and above
>> > > ...
>> > > ....
>> > > jjain.protocol.ip.sip."full" - general classes only used at this
>> level
>> > > jain.protocol.ip.sip."full".header - headers used only at this
>> level
>> > > jain.protocol.ip.sip."full".message - messages used only at this
>> level
>> > >
>> > > The API user could then pick the packages they need - say they
>> initially only
>> > > want the minimal features, but then realise they need to use
>> their application
>> > > behind a firewall - then they can simply add the
>> firewall-friendly package. The
>> > > RFC says "In general, each capability listed builds on the ones
>> above it" but it
>> > > is not hard to see that firewall-friendly and authentication may
>> be desired
>> > > without redirection for example.
>> > >
>> > > Is this what you hand in mind Itamar?
>> >
>> > --
>> > Gethin Liddell
>> > Ubiquity Software Corporation
>> >
>> > http://www.ubiquity.net
>> > mailto:gethin@ubiquity.net
>> >
>> > _______________________________________________
>> > SIP mailing list
>> > SIP@lists.bell-labs.com
>> > http://lists.bell-labs.com/mailman/listinfo/sip
>>
>> --
>> M.Ranganathan
>> NIST Advanced Networking Technologies Group,
>> 100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899.
>> Tel: 301 975 3664 Fax: 301 590 0932
>>
>> Hfæj)b? b²Ô^>X¬¶ÆÞ-YZnÇ(sm§ÿåSËlmée*¦ìr?¿?¨¥?©ÿ-+-SwèþÈ©
>

--
M.Ranganathan
NIST Advanced Networking Technologies Group,
100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899.
Tel: 301 975 3664 Fax: 301 590 0932

Hƒæj)bž b²Ôˆ>X¬¶ÆÞ–YZnÇ(šm§ÿåŠËlmée•¦ìr‰¿™¨¥™©ÿ–+-ŠwèþÈ©

--------------39569E68F11A897AB4A16251-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 18 12:35:08 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA27015 for ; Wed, 18 Oct 2000 12:35:06 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B8B6D4434C; Wed, 18 Oct 2000 11:35:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from drago1.ubiquity.net (unknown [194.202.146.92]) by lists.bell-labs.com (Postfix) with SMTP id 33C9E44336 for ; Wed, 18 Oct 2000 11:34:04 -0400 (EDT) Received: from gecko.ubiquity.co.uk by drago1.ubiquity.net via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 18 Oct 2000 16:34:32 UT Received: from gethin by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id RAA14078; Wed, 18 Oct 2000 17:32:17 +0100 (BST) From: Gethin Liddell Organization: Ubiquity Software Corp. To: Chris Harris Subject: Re: [SIP] JAIN SIP Specification X-Mailer: KMail [version 1.0.29.2] Content-Type: text/plain Cc: Itamar Gilad , , "'SIPForum list'" , References: <00101814092004.10136@gethin> <39EDB4AC.21D28150@dynamicsoft.com> In-Reply-To: <39EDB4AC.21D28150@dynamicsoft.com> MIME-Version: 1.0 Message-Id: <00101817321606.10136@gethin> Content-Transfer-Encoding: 8bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 18 Oct 2000 17:10:52 +0100 Content-Transfer-Encoding: 8bit Hi Chris, check comments in-line: On Wed, 18 Oct 2000, Chris Harris wrote: > > PS - I'm looking forward to seeing you at the JAIN Meeting next week! likewise, should be fun ;-) > Gethin Liddell wrote: > > I have removed EnityHeader etc...as for the RequestMessage classes - different classes > exist because the headers applicable to each are different - hence the accessor > methods on each are different. I guess we could have just a RequestMessage class - > with accessor methods for only the headers common to all 6 methods, and then the > user/implementor has to use the generic header methods for any other headers. If this > is the case, then I don't think there is any need for layering the API as mentioned. > My only concern is about the Ack and Cancel Messages, which although are requests - > can in a sense be thought of as being logically separate to the other requests. I see no real problem with having a base RequestMethod with a basic subset of methods present and no InviteMessage etc... So it may be possible for a BYE to be sent with a Subject header in it. so what? if the user really wants to do something dull like that then we can't stop them anyway. Its hardly gonna crash anyone. > > > > > > How about if the format of the API remains as is: > > > > jain.protocol.ip.sip > > jain.protocol.ip.sip.header > > jain.protocol.ip.sip.message > > > > except that the messages available in the message package consisted of > > BasicRequest/Response, MinimalRequest/Response etc... where each > > message is extened in turn (e.g. Minimal extends Basic, Moderate > > extends Minimal etc...), of course as Chris points out it is not hard > > to see that a combination would be required that is not provided. So > > in the interest of flexibility, it could be possible for the user to > > plug-in to the message class what extra headers it requires. The only > > issue then is that the user will have to use a "public Header > > getHeader(String headerName)" and then cast the header to their desired > > header type. Either that or create their own Message class > > (extending the current ones) that simply does the casting automatically > > for them. Then after compiling, run an obfuscator on the code and it > > will automatically extract and only extract the Message, Headers and > > even methods that are used. > > > > This then will also cut down on the number of methods in the Provider > > as there will be no need for the sendAck(AckMessage), > > sendInvite(InviteMessage) etc.. as they would be replaced by the > > single method sendRequest(RequestMessage). > > As I mentioned above, it may be useful to keep sendAck and sendCancel in addition to > sendRequest. Again i don't really see why. The stack will have to examine the method anyway for invite or other so it can easily understand that it is an ACK or CANCEL. If what your trying to do is make it easy for the stack to behave correctly on a CANCEL then i don't really think we are gaining anything by having a sendCancel() method. Also can i have some feed back on the idea of plugins. At the moment it is only possible for a proprietary header to be constructed by doing a getHeader() call and then parsing the header after a toString() (as far as i can see). Would it not be nice to provide a way for the header to automatically be constructed? That is can we not notify the provider or messge or whatever at an early point of an additional header format and expect that header format back when a getHeader(String MyHeader) call is made. By that i mean can we not do something like the following: //at init Message.notifyOfProprietaryHeader(new MyHeader()); //then when message comes in MyHeader myHeader = (MyHeader) message.getHeader("myheader"); > *snip* > Three very good reasons for using this Public Review period to make JAIN SIP realise > its full potential! Can i ask, why is the public review only open until the 28th and what happens after that? Just that there seems to be a good response from the group at large and i think that any changes that occur will need to be discussed further. -- Gethin Liddell Ubiquity Software Corporation http://www.ubiquity.net mailto:gethin@ubiquity.net _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 18 12:42:37 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA28030 for ; Wed, 18 Oct 2000 12:42:32 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id BC5284434C; Wed, 18 Oct 2000 11:42:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from wusr3.mobilerain.com (sdsl-208-185-234-252.dsl.sjc.megapath.net [208.185.234.252]) by lists.bell-labs.com (Postfix) with ESMTP id C277E44336 for ; Wed, 18 Oct 2000 11:41:48 -0400 (EDT) Received: from mobilerain.com (IDENT:dsardana@localhost [127.0.0.1]) by wusr3.mobilerain.com (8.9.3/8.9.3) with ESMTP id JAA05469; Wed, 18 Oct 2000 09:38:42 -0700 Message-ID: <39EDD212.39768977@mobilerain.com> From: Bobby Sardana Organization: MobileRain Technologies, Inc. X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: discussion@sipforum.org Cc: mranga@nist.gov, sip@lists.bell-labs.com, jainsip@sun.com Subject: Re: [SIPFORUM] Re: [SIP] JAIN SIP Specification References: <39EB464C.44254E5B@dynamicsoft.com> <00101814092004.10136@gethin> <39EDB3C4.282F1EFA@nist.gov> <39EDBC08.A51790EF@dynamicsoft.com> <39EDC2C5.A98A11BF@nist.gov> <39EDCF73.42981937@dynamicsoft.com> Content-Type: multipart/mixed; boundary="------------E0D55AFF41A516B2A223F730" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 18 Oct 2000 09:38:42 -0700 This is a multi-part message in MIME format. --------------E0D55AFF41A516B2A223F730 Content-Type: multipart/alternative; boundary="------------5ED757744CA90ED956F10F08" --------------5ED757744CA90ED956F10F08 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Greetings Chris: Just to add a pointer to this thread: Maintaining trasaction state is an application level functionality and *shouldn't* be implemented in the base stack. For applications like state oriented proxy server, the JAIN SIP can provide enough hooks for event delivery but the state has to be maintained by the proxy server. Pleas keep up the good work. It is really appreciated. Regards, Bobby.Sardana@mobilerain.com Chris Harris wrote: > "M. Ranganathan" wrote: > >> Hi Chris, >> >> Thanks for replying so promptly (I am sure you are flooded with >> email ). > > I get one or two :) > >> >> As you pointed out, I suppose we cannot do away with making Messages >> >> into classes because of the tie-in with java events (unfortunately) >> but >> I still like the notion of being able to specify interfaces where >> ever >> possible. > > I see where you're coming from alright, and I suppose changing header > classes into interfaces, could fit in with Gethin's proposal nicely? > >> >> I dont quite follow the motivation behind the following design >> decision (excerpted from your reply): >> >> Maybe I've misunderstood what you're saying - but a JAIN SIP >> implementation is only stateless when it comes to call state. The >> JainSipProvider implementation must maintain transaction state - it >> simply exposes a reference to a transaction via the transaction id >> for >> the convenience of the JainSipListener. The service does not have >> total >> control over transacton state - the stack implementation does. >> >> It appears that I have indded mis-understood the architecture. Why >> should the above be so? Can one not rely on the JainSipListener to >> keep >> transaction state also, thereby making the stack simply a way of >> recognising messages and triggering event handlers on the basis of >> message type. This would (IMHO) be a cleaner model yet. That >> way, we >> can do away with transaction identifiers being passed back and forth >> and >> keep all of this information in the handler. ( You may have to >> extend >> the architecture somewhat to deal with timeouts and failures so that >> the >> handler knows about transaction failure.) In any case, if this is >> not a >> viable idea, I would be grateful if you can explain why not (or >> point me >> to the portion of the spec that explains why not) so I can get a >> better >> understanding. > > It would be cleaner model, and personally I am in total agreement with > you - but it means the application is forced to maintain transaction > state, match up headers - which has been said places too much of a > burden on applications. How about finding a way to let the application > choose whether or not it wants to keep transaction state? > >> >> >> Regards, >> >> Ranga. >> >> Chris Harris wrote: >> >> > Hi Ranga, >> > >> > Response below... >> > >> > Chris >> > >> > "M. Ranganathan" wrote: >> > >> >> JAIN-SIP is a groovy idea. Hats off to the whole concept and many >> >> >> thanks to Chris and >> >> the JAIN-SIP team for putting together a spec and more flower >> power >> >> to them :-) . In >> >> particular I like the notion of treating UAS, Redirect and Proxy >> >> >> servers as merely >> >> special cases of the general notion of Services and the idea of >> >> unifying these >> >> notions with an event mechanism and event handlers. Second, I >> like >> >> the idea of >> >> separation between a stateless event -oriented "stack" and a >> bunch >> >> of event >> >> handlers that are triggered by the stack with all state >> (including >> >> transaction >> >> state) being separated from the event stack via the JAIN-SIP >> mapping >> >> layer if you >> >> will. ( Correct me if I wax poetic but have the wrong >> >> understanding....) >> > >> >> >> >> >> >> I hope I will not be viewed as being too critical, but I would >> >> like to go one step >> >> further than what Gethin is suggesting. I am all for using >> >> interfaces as much as >> >> possible and leaving class hierarchy definitions to implemeters. >> >> Defining class >> >> hierarchies almost lays out an implementation and involves >> >> considerable rework for >> >> those who have a working java-based stack, but have not used the >> >> same classes. OK it >> >> is just a matter of labor to map things to the JAIN-SIP class >> >> hierarchy but it IS a >> >> dis-incentive. >> >> >> >> 1. Lets use interfaces for all messages rather than actually >> define >> >> class >> >> hierarchies ( yes Chris has pointed out the historical precedent >> >> >> behind actually >> >> defining class hierarchies for messages. IMHO, there has to be a >> >> >> more compelling >> >> reason than that.) >> > >> > I suppose all classes could be turned into interfaces, except for >> the >> > Message classes which must extend java.util.EventObject to fit >> into >> > the JAIN framework. >> > >> >> >> >> >> >> 2. The tie-in with the JAVA event mechanism has necessitated the >> >> explicit definition >> >> of class hierarchies in certain places. Why not use callbacks >> >> instead and do away >> >> with this dependency as well? (Basically the same thing as >> events >> >> but does not tie >> >> into the JAVA event mechanism and its associated limitations.) >> > >> > Unfortunately the JAIN framework expilicitly relies on the Java >> Event >> > model, and I don't think callbacks would be accepted within the >> JAIN >> > community. >> > >> >> >> >> >> >> Nice work and keep it rolling! Thanks. >> > >> > Couldn't do it without you guys - thank you! >> > >> >> >> >> >> >> Ranga. >> >> >> >> Gethin Liddell wrote: >> >> >> >> > All, >> >> > >> >> > This idea of abstraction of the JAIN API is certainly a valid >> and >> >> > interesting idea. However, i'm a bit concerened that the >> proposed >> >> >> >> > solution of many different packages, will only seek to >> complicate >> >> and >> >> > maybe enlarge the API. >> >> > >> >> > I too see no reason why there is an EntityHeader etc... and i >> also >> >> do >> >> > not see any requirement for an InviteMessage, AckMessage etc... >> >> >> > >> >> > How about if the format of the API remains as is: >> >> > >> >> > jain.protocol.ip.sip >> >> > jain.protocol.ip.sip.header >> >> > jain.protocol.ip.sip.message >> >> > >> >> > except that the messages available in the message package >> >> consisted of >> >> > BasicRequest/Response, MinimalRequest/Response etc... where >> each >> >> > message is extened in turn (e.g. Minimal extends Basic, >> Moderate >> >> > extends Minimal etc...), of course as Chris points out it is >> not >> >> hard >> >> > to see that a combination would be required that is not >> provided. >> >> So >> >> > in the interest of flexibility, it could be possible for the >> user >> >> to >> >> > plug-in to the message class what extra headers it requires. >> The >> >> only >> >> > issue then is that the user will have to use a "public Header >> >> > getHeader(String headerName)" and then cast the header to their >> >> >> desired >> >> > header type. Either that or create their own Message class >> >> > (extending the current ones) that simply does the casting >> >> automatically >> >> > for them. Then after compiling, run an obfuscator on the code >> and >> >> it >> >> > will automatically extract and only extract the Message, >> Headers >> >> and >> >> > even methods that are used. >> >> > >> >> > This then will also cut down on the number of methods in the >> >> Provider >> >> > as there will be no need for the sendAck(AckMessage), >> >> > sendInvite(InviteMessage) etc.. as they would be replaced by >> the >> >> > single method sendRequest(RequestMessage). >> >> > >> >> > I personally see three arguments for keeping the JAIN SIP stack >> as >> >> small >> >> > as possible: >> >> > >> >> > 1) The first is for embedded applications where stack size has >> to >> >> be >> >> > kept to a minimum as memory is at a premium. So if just using >> the >> >> >> >> > Basic message suffices then this will compile and run with a >> small >> >> >> >> > number of classes present from the stack. Don't forget, >> >> obfuscation >> >> > will help in extracting only the Messages, Headers and even >> >> methods >> >> > required from a jar file but it won't do everything. >> >> > >> >> > 2) The second is that users may be put off or confused by the >> >> sheer >> >> > size and complexity of the JAIN stack. So if only using the >> >> > BasicMessage gets them on the first rung of the ladder then it >> is >> >> a >> >> > good starting point and allows them to build up to bigger and >> >> better >> >> > things. >> >> > >> >> > 3) We also have to consider who is going to implement the JAIN >> SIP >> >> >> >> > stack. If it is indeed overly complicated then no-one or a >> single >> >> > vendor may end up implmenting the stack and thus its definition >> >> >> and >> >> > all the hard work that has gone into it is useless. >> >> > >> >> > On Mon, 16 Oct 2000, Chris Harris wrote: >> >> > > Itamar, >> >> > > >> >> > > The idea of levelling the API based on what messages, headers >> >> >> and response codes >> >> > > are understood is certainly an interesting one - minimal, >> basic, >> >> redirection, >> >> > > firewall-friendly, negotiation, authentication and "full". >> >> > > >> >> > > jain.protocol.ip.sip >> >> > > jain.protocol.ip.sip.header >> >> > > jain.protocol.ip.sip.message >> >> > > >> >> > > could then become... >> >> > > >> >> > > jain.protocol.ip.sip - listener, provider, stack, general >> >> classes used at all >> >> > > levels >> >> > > jain.protocol.ip.sip.header - contains base Header class (and >> >> >> requestHeader, >> >> > > ResponseHeader, EntityHeader, GeneralHeader) >> >> > > jain.protocol.ip.sip.message - contains base Message class >> >> > > >> >> > > jain.protocol.ip.sip.minimal - general classes used only at >> this >> >> level and above >> >> > > >> >> > > jain.protocol.ip.sip.minimal.header - headers used only at >> this >> >> level and above >> >> > > jain.protocol.ip.sip.minimal.message - messages only used at >> >> this level and >> >> > > above >> >> > > >> >> > > jain.protocol.ip.sip.basic - general classes used only at >> this >> >> level and above >> >> > > jain.protocol.ip.sip.basic.header - headers used only at this >> >> >> level and above >> >> > > jain.protocol.ip.sip.basic.message - messages used only at >> this >> >> level and above >> >> > > ... >> >> > > .... >> >> > > jjain.protocol.ip.sip."full" - general classes only used at >> this >> >> level >> >> > > jain.protocol.ip.sip."full".header - headers used only at >> this >> >> level >> >> > > jain.protocol.ip.sip."full".message - messages used only at >> this >> >> level >> >> > > >> >> > > The API user could then pick the packages they need - say >> they >> >> initially only >> >> > > want the minimal features, but then realise they need to use >> >> their application >> >> > > behind a firewall - then they can simply add the >> >> firewall-friendly package. The >> >> > > RFC says "In general, each capability listed builds on the >> ones >> >> above it" but it >> >> > > is not hard to see that firewall-friendly and authentication >> may >> >> be desired >> >> > > without redirection for example. >> >> > > >> >> > > Is this what you hand in mind Itamar? >> >> > >> >> > -- >> >> > Gethin Liddell >> >> > Ubiquity Software Corporation >> >> > >> >> > http://www.ubiquity.net >> >> > mailto:gethin@ubiquity.net >> >> > >> >> > _______________________________________________ >> >> > SIP mailing list >> >> > SIP@lists.bell-labs.com >> >> > http://lists.bell-labs.com/mailman/listinfo/sip >> >> >> >> -- >> >> M.Ranganathan >> >> NIST Advanced Networking Technologies Group, >> >> 100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899. >> >> Tel: 301 975 3664 Fax: 301 590 0932 >> >> >> >> Hfæj)b? b²Ô^>X¬¶ÆÞ-YZnÇ(sm§ÿåSËlmée*¦ìr?¿?¨¥?©ÿ-+-SwèþÈ© >> > >> >> -- >> M.Ranganathan >> NIST Advanced Networking Technologies Group, >> 100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899. >> Tel: 301 975 3664 Fax: 301 590 0932 >> >> Hfæj)b? b²Ô^>X¬¶ÆÞ-YZnÇ(sm§ÿåSËlmée*¦ìr?¿?¨¥?©ÿ-+-SwèþÈ© > --------------5ED757744CA90ED956F10F08 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Greetings Chris:

Just to add a pointer to this thread:

Maintaining trasaction state is an application level functionality and *shouldn't* be implemented in the base stack. For applications like state oriented proxy server, the JAIN SIP can provide enough hooks for event delivery but the state has to be maintained by the proxy server.

Pleas keep up the good work. It is really appreciated.

Regards,

Bobby.Sardana@mobilerain.com

Chris Harris wrote:

"M. Ranganathan" wrote:
Hi Chris,

Thanks for replying so promptly (I am sure you are flooded with email ).

I get one or two :)
 
As you pointed out, I suppose we cannot do away with making Messages
into classes because of the tie-in with java events (unfortunately) but
I still like the notion of being able to specify  interfaces where ever
possible.
I see where you're coming from alright, and I suppose changing header classes into interfaces, could fit in with Gethin's proposal nicely?
 
 I dont quite follow  the motivation behind the following design
decision (excerpted from your reply):

Maybe I've misunderstood what you're saying - but a JAIN SIP
implementation is only stateless when it comes to call state. The
JainSipProvider implementation must maintain transaction state - it
simply exposes a reference to a transaction via the transaction id for
the convenience of the JainSipListener. The service does not have total
control over transacton state - the stack implementation does.

It appears that I have indded mis-understood the architecture.  Why
should the above be so? Can one not rely on the JainSipListener to keep
transaction state also, thereby making the stack simply a way of
recognising messages and triggering  event handlers on the basis of
message type. This would (IMHO) be a cleaner model yet.    That way,  we
can do away with transaction identifiers being passed back and forth and
keep all of this information in the handler.  ( You may have to extend
the architecture somewhat to deal with timeouts and failures so that the
handler knows about transaction failure.) In any case, if this is not a
viable idea, I would be grateful if you can explain why not (or point me
to the portion of the spec that explains why not) so I can get a better
understanding.

It would be cleaner model, and personally I am in total agreement with you - but it means the application is forced to maintain transaction state, match up headers - which has been said places too much of a burden on applications. How about finding a way to let the application choose whether or not it wants to keep transaction state?
 

Regards,

Ranga.

Chris Harris wrote:

> Hi Ranga,
>
> Response below...
>
> Chris
>
> "M. Ranganathan" wrote:
>
>> JAIN-SIP is a groovy idea. Hats off to the whole concept and many
>> thanks to Chris and
>> the JAIN-SIP team for putting together a spec and more flower power
>> to them :-) .  In
>> particular I like the notion of treating UAS,  Redirect and Proxy
>> servers as merely
>> special cases of the general notion of Services and  the idea of
>> unifying these
>> notions with an event mechanism and  event handlers.  Second, I like
>> the idea of
>> separation between a  stateless  event -oriented "stack" and a bunch
>> of event
>> handlers that are triggered by the stack with all state (including
>> transaction
>> state) being separated from the event stack via the JAIN-SIP mapping
>> layer if you
>> will.  ( Correct me if I  wax poetic but have the wrong
>> understanding....)
>
>>
>>
>> I hope I  will not be viewed as being too critical,  but I would
>> like to go  one step
>> further than what Gethin is suggesting.   I am all for using
>> interfaces as much as
>> possible and leaving class hierarchy definitions to implemeters.
>> Defining class
>> hierarchies almost lays out an implementation and involves
>> considerable rework for
>> those who have a working java-based stack, but have not used the
>> same classes. OK it
>> is just a matter of labor to map things to the JAIN-SIP class
>> hierarchy but it  IS a
>> dis-incentive.
>>
>> 1. Lets use interfaces for all messages rather than actually define
>> class
>> hierarchies  ( yes Chris has pointed out the historical precedent
>> behind actually
>> defining class hierarchies for messages. IMHO,  there has to be a
>> more compelling
>> reason than that.)
>
> I suppose all classes could be turned into interfaces, except for the
> Message classes which must extend java.util.EventObject to fit into
> the JAIN framework.
>
>>
>>
>> 2. The tie-in with the JAVA event mechanism has necessitated the
>> explicit definition
>> of class hierarchies in certain places.  Why not use callbacks
>> instead and do away
>> with this dependency as well?  (Basically the same thing as events
>> but does not tie
>> into the JAVA event mechanism and its associated limitations.)
>
> Unfortunately the JAIN framework expilicitly relies on the Java Event
> model, and I don't think callbacks would be accepted within the JAIN
> community.
>
>>
>>
>> Nice work and keep it rolling!  Thanks.
>
> Couldn't do it without you guys - thank you!
>
>>
>>
>> Ranga.
>>
>> Gethin Liddell wrote:
>>
>> > All,
>> >
>> > This idea of abstraction of the JAIN API is certainly a valid and
>> > interesting idea.  However, i'm a bit concerened that the proposed
>>
>> > solution of many different packages, will only seek to complicate
>> and
>> > maybe enlarge the API.
>> >
>> > I too see no reason why there is an EntityHeader etc... and i also
>> do
>> > not see any requirement for an InviteMessage, AckMessage etc...
>> >
>> > How about if the format of the API remains as is:
>> >
>> > jain.protocol.ip.sip
>> > jain.protocol.ip.sip.header
>> > jain.protocol.ip.sip.message
>> >
>> > except that the messages available in the message package
>> consisted of
>> > BasicRequest/Response, MinimalRequest/Response etc... where each
>> > message is extened in turn (e.g. Minimal extends Basic, Moderate
>> > extends Minimal etc...), of course as Chris points out it is not
>> hard
>> > to see that a combination would be required that is not provided.
>> So
>> > in the interest of flexibility, it could be possible for the user
>> to
>> > plug-in to the message class what extra headers it requires.  The
>> only
>> > issue then is that the user will have to use a "public Header
>> > getHeader(String headerName)" and then cast the header to their
>> desired
>> > header type. Either that or create their own Message class
>> > (extending the current ones) that simply does the casting
>> automatically
>> > for them.  Then after compiling, run an obfuscator on the code and
>> it
>> > will automatically extract and only extract the Message, Headers
>> and
>> > even methods that are used.
>> >
>> > This then will also cut down on the number of methods in the
>> Provider
>> > as there will be no need for the sendAck(AckMessage),
>> > sendInvite(InviteMessage) etc.. as they would be replaced by the
>> > single method sendRequest(RequestMessage).
>> >
>> > I personally see three arguments for keeping the JAIN SIP stack as
>> small
>> > as possible:
>> >
>> > 1) The first is for embedded applications where stack size has to
>> be
>> > kept to a minimum as memory is at a premium.  So if just using the
>>
>> > Basic message suffices then this will compile and run with a small
>>
>> > number of classes present from the stack.  Don't forget,
>> obfuscation
>> > will help in extracting only the Messages, Headers and even
>> methods
>> > required from a jar file but it won't do everything.
>> >
>> > 2) The second is that users may be put off or confused by the
>> sheer
>> > size and complexity of the JAIN stack.  So if only using the
>> > BasicMessage gets them on the first rung of the ladder then it is
>> a
>> > good starting point and allows them to build up to bigger and
>> better
>> > things.
>> >
>> > 3) We also have to consider who is going to implement the JAIN SIP
>>
>> > stack. If it is indeed overly complicated then no-one or a single
>> > vendor may end up implmenting the stack and thus its definition
>> and
>> > all the hard work that has gone into it is useless.
>> >
>> > On Mon, 16 Oct 2000, Chris Harris wrote:
>> > > Itamar,
>> > >
>> > > The idea of levelling the API based on what messages, headers
>> and response codes
>> > > are understood is certainly an interesting one - minimal, basic,
>> redirection,
>> > > firewall-friendly, negotiation, authentication and "full".
>> > >
>> > > jain.protocol.ip.sip
>> > > jain.protocol.ip.sip.header
>> > > jain.protocol.ip.sip.message
>> > >
>> > > could then become...
>> > >
>> > > jain.protocol.ip.sip - listener, provider, stack, general
>> classes used at all
>> > > levels
>> > > jain.protocol.ip.sip.header - contains base Header class (and
>> requestHeader,
>> > > ResponseHeader, EntityHeader, GeneralHeader)
>> > > jain.protocol.ip.sip.message - contains base Message class
>> > >
>> > > jain.protocol.ip.sip.minimal - general classes used only at this
>> level and above
>> > >
>> > > jain.protocol.ip.sip.minimal.header - headers used only at this
>> level and above
>> > > jain.protocol.ip.sip.minimal.message - messages only used at
>> this level and
>> > > above
>> > >
>> > > jain.protocol.ip.sip.basic - general classes used only at this
>> level and above
>> > > jain.protocol.ip.sip.basic.header - headers used only at this
>> level and above
>> > > jain.protocol.ip.sip.basic.message - messages used only at this
>> level and above
>> > > ...
>> > > ....
>> > > jjain.protocol.ip.sip."full" - general classes only used at this
>> level
>> > > jain.protocol.ip.sip."full".header - headers used only at this
>> level
>> > > jain.protocol.ip.sip."full".message - messages used only at this
>> level
>> > >
>> > > The API user could then pick the packages they need - say they
>> initially only
>> > > want the minimal features, but then realise they need to use
>> their application
>> > > behind a firewall - then they can simply add the
>> firewall-friendly package. The
>> > > RFC says "In general, each capability listed builds on the ones
>> above it" but it
>> > > is not hard to see that firewall-friendly and authentication may
>> be desired
>> > > without redirection for example.
>> > >
>> > > Is this what you hand in mind Itamar?
>> >
>> > --
>> > Gethin Liddell
>> > Ubiquity Software Corporation
>> >
>> > http://www.ubiquity.net
>> > mailto:gethin@ubiquity.net
>> >
>> > _______________________________________________
>> > SIP mailing list
>> > SIP@lists.bell-labs.com
>> > http://lists.bell-labs.com/mailman/listinfo/sip
>>
>> --
>> M.Ranganathan
>> NIST Advanced Networking Technologies Group,
>> 100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899.
>> Tel: 301 975 3664 Fax: 301 590 0932
>>
>> Hfæj)b? b²Ô^>X¬¶ÆÞ-YZnÇ(sm§ÿåSËlmée*¦ìr?¿?¨¥?©ÿ-+-SwèþÈ©
>

--
M.Ranganathan
NIST Advanced Networking Technologies Group,
100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899.
Tel: 301 975 3664 Fax: 301 590 0932

Hfæj)b? b²Ô^>X¬¶ÆÞ-YZnÇ(sm§ÿåSËlmée*¦ìr?¿?¨¥?©ÿ-+-SwèþÈ©

--------------5ED757744CA90ED956F10F08-- --------------E0D55AFF41A516B2A223F730 Content-Type: text/x-vcard; charset=us-ascii; name="bobby.sardana.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Bobby Sardana Content-Disposition: attachment; filename="bobby.sardana.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Sardana;Bobby x-mozilla-html:FALSE org:MobileRain Technologies, Inc.;Telecommunications adr:;;;;;; version:2.1 email;internet:bobby.sardana@mobilerain.com title:Engineer x-mozilla-cpt:;0 fn:Bobby Sardana end:vcard --------------E0D55AFF41A516B2A223F730-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 18 12:51:11 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA29295 for ; Wed, 18 Oct 2000 12:51:08 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0B6B24434C; Wed, 18 Oct 2000 11:51:06 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 4CF5D44336 for ; Wed, 18 Oct 2000 11:50:43 -0400 (EDT) Received: from dynamicsoft.com (userac41.ie.uudial.com [212.120.133.240]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id MAA27795; Wed, 18 Oct 2000 12:52:40 -0400 (EDT) Message-ID: <39EDD4E7.75D09818@dynamicsoft.com> From: Chris Harris Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: discussion@sipforum.org Cc: mranga@nist.gov, sip@lists.bell-labs.com, jainsip@sun.com Subject: Re: [SIPFORUM] Re: [SIP] JAIN SIP Specification References: <39EB464C.44254E5B@dynamicsoft.com> <00101814092004.10136@gethin> <39EDB3C4.282F1EFA@nist.gov> <39EDBC08.A51790EF@dynamicsoft.com> <39EDC2C5.A98A11BF@nist.gov> <39EDCF73.42981937@dynamicsoft.com> <39EDD212.39768977@mobilerain.com> Content-Type: multipart/alternative; boundary="------------815F573113775579630111EA" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 18 Oct 2000 17:50:47 +0100 --------------815F573113775579630111EA Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Bobby Sardana wrote: > Greetings Chris: > > Just to add a pointer to this thread: > > Maintaining trasaction state is an application level functionality and > *shouldn't* be implemented in the base stack. For applications like > state oriented proxy server, the JAIN SIP can provide enough hooks for > event delivery but the state has to be maintained by the proxy server. Is simply sending up all received requests without any kind of transaction id really enough? What are the hooks you refer to? An application like a stateful proxy server will surely be able to handle this, but what about simple services? - shouldn't the API provide a convenient means to send responses, acks, cancel etc? > > > Pleas keep up the good work. It is really appreciated. > > Regards, > > Bobby.Sardana@mobilerain.com > > Chris Harris wrote: > >> "M. Ranganathan" wrote: >> >> > Hi Chris, >> > >> > Thanks for replying so promptly (I am sure you are flooded with >> > email ). >> >> I get one or two :) >> >> > >> > As you pointed out, I suppose we cannot do away with making >> > Messages >> > into classes because of the tie-in with java events (unfortunately) >> > but >> > I still like the notion of being able to specify interfaces where >> > ever >> > possible. >> >> I see where you're coming from alright, and I suppose changing >> header classes into interfaces, could fit in with Gethin's proposal >> nicely? >> >> > >> > I dont quite follow the motivation behind the following design >> > decision (excerpted from your reply): >> > >> > Maybe I've misunderstood what you're saying - but a JAIN SIP >> > implementation is only stateless when it comes to call state. The >> > JainSipProvider implementation must maintain transaction state - it >> > >> > simply exposes a reference to a transaction via the transaction id >> > for >> > the convenience of the JainSipListener. The service does not have >> > total >> > control over transacton state - the stack implementation does. >> > >> > It appears that I have indded mis-understood the architecture. Why >> > >> > should the above be so? Can one not rely on the JainSipListener to >> > keep >> > transaction state also, thereby making the stack simply a way of >> > recognising messages and triggering event handlers on the basis of >> > >> > message type. This would (IMHO) be a cleaner model yet. That >> > way, we >> > can do away with transaction identifiers being passed back and >> > forth and >> > keep all of this information in the handler. ( You may have to >> > extend >> > the architecture somewhat to deal with timeouts and failures so >> > that the >> > handler knows about transaction failure.) In any case, if this is >> > not a >> > viable idea, I would be grateful if you can explain why not (or >> > point me >> > to the portion of the spec that explains why not) so I can get a >> > better >> > understanding. >> >> It would be cleaner model, and personally I am in total agreement >> with you - but it means the application is forced to maintain >> transaction state, match up headers - which has been said places too >> much of a burden on applications. How about finding a way to let the >> application choose whether or not it wants to keep transaction >> state? >> >> > >> > >> > Regards, >> > >> > Ranga. >> > >> > Chris Harris wrote: >> > >> > > Hi Ranga, >> > > >> > > Response below... >> > > >> > > Chris >> > > >> > > "M. Ranganathan" wrote: >> > > >> > >> JAIN-SIP is a groovy idea. Hats off to the whole concept and >> > many >> > >> thanks to Chris and >> > >> the JAIN-SIP team for putting together a spec and more flower >> > power >> > >> to them :-) . In >> > >> particular I like the notion of treating UAS, Redirect and >> > Proxy >> > >> servers as merely >> > >> special cases of the general notion of Services and the idea of >> > >> > >> unifying these >> > >> notions with an event mechanism and event handlers. Second, I >> > like >> > >> the idea of >> > >> separation between a stateless event -oriented "stack" and a >> > bunch >> > >> of event >> > >> handlers that are triggered by the stack with all state >> > (including >> > >> transaction >> > >> state) being separated from the event stack via the JAIN-SIP >> > mapping >> > >> layer if you >> > >> will. ( Correct me if I wax poetic but have the wrong >> > >> understanding....) >> > > >> > >> >> > >> >> > >> I hope I will not be viewed as being too critical, but I would >> > >> > >> like to go one step >> > >> further than what Gethin is suggesting. I am all for using >> > >> interfaces as much as >> > >> possible and leaving class hierarchy definitions to implemeters. >> > >> > >> Defining class >> > >> hierarchies almost lays out an implementation and involves >> > >> considerable rework for >> > >> those who have a working java-based stack, but have not used the >> > >> > >> same classes. OK it >> > >> is just a matter of labor to map things to the JAIN-SIP class >> > >> hierarchy but it IS a >> > >> dis-incentive. >> > >> >> > >> 1. Lets use interfaces for all messages rather than actually >> > define >> > >> class >> > >> hierarchies ( yes Chris has pointed out the historical >> > precedent >> > >> behind actually >> > >> defining class hierarchies for messages. IMHO, there has to be >> > a >> > >> more compelling >> > >> reason than that.) >> > > >> > > I suppose all classes could be turned into interfaces, except for >> > the >> > > Message classes which must extend java.util.EventObject to fit >> > into >> > > the JAIN framework. >> > > >> > >> >> > >> >> > >> 2. The tie-in with the JAVA event mechanism has necessitated the >> > >> > >> explicit definition >> > >> of class hierarchies in certain places. Why not use callbacks >> > >> instead and do away >> > >> with this dependency as well? (Basically the same thing as >> > events >> > >> but does not tie >> > >> into the JAVA event mechanism and its associated limitations.) >> > > >> > > Unfortunately the JAIN framework expilicitly relies on the Java >> > Event >> > > model, and I don't think callbacks would be accepted within the >> > JAIN >> > > community. >> > > >> > >> >> > >> >> > >> Nice work and keep it rolling! Thanks. >> > > >> > > Couldn't do it without you guys - thank you! >> > > >> > >> >> > >> >> > >> Ranga. >> > >> >> > >> Gethin Liddell wrote: >> > >> >> > >> > All, >> > >> > >> > >> > This idea of abstraction of the JAIN API is certainly a valid >> > and >> > >> > interesting idea. However, i'm a bit concerened that the >> > proposed >> > >> >> > >> > solution of many different packages, will only seek to >> > complicate >> > >> and >> > >> > maybe enlarge the API. >> > >> > >> > >> > I too see no reason why there is an EntityHeader etc... and i >> > also >> > >> do >> > >> > not see any requirement for an InviteMessage, AckMessage >> > etc... >> > >> > >> > >> > How about if the format of the API remains as is: >> > >> > >> > >> > jain.protocol.ip.sip >> > >> > jain.protocol.ip.sip.header >> > >> > jain.protocol.ip.sip.message >> > >> > >> > >> > except that the messages available in the message package >> > >> consisted of >> > >> > BasicRequest/Response, MinimalRequest/Response etc... where >> > each >> > >> > message is extened in turn (e.g. Minimal extends Basic, >> > Moderate >> > >> > extends Minimal etc...), of course as Chris points out it is >> > not >> > >> hard >> > >> > to see that a combination would be required that is not >> > provided. >> > >> So >> > >> > in the interest of flexibility, it could be possible for the >> > user >> > >> to >> > >> > plug-in to the message class what extra headers it requires. >> > The >> > >> only >> > >> > issue then is that the user will have to use a "public Header >> > >> > getHeader(String headerName)" and then cast the header to >> > their >> > >> desired >> > >> > header type. Either that or create their own Message class >> > >> > (extending the current ones) that simply does the casting >> > >> automatically >> > >> > for them. Then after compiling, run an obfuscator on the code >> > and >> > >> it >> > >> > will automatically extract and only extract the Message, >> > Headers >> > >> and >> > >> > even methods that are used. >> > >> > >> > >> > This then will also cut down on the number of methods in the >> > >> Provider >> > >> > as there will be no need for the sendAck(AckMessage), >> > >> > sendInvite(InviteMessage) etc.. as they would be replaced by >> > the >> > >> > single method sendRequest(RequestMessage). >> > >> > >> > >> > I personally see three arguments for keeping the JAIN SIP >> > stack as >> > >> small >> > >> > as possible: >> > >> > >> > >> > 1) The first is for embedded applications where stack size has >> > to >> > >> be >> > >> > kept to a minimum as memory is at a premium. So if just using >> > the >> > >> >> > >> > Basic message suffices then this will compile and run with a >> > small >> > >> >> > >> > number of classes present from the stack. Don't forget, >> > >> obfuscation >> > >> > will help in extracting only the Messages, Headers and even >> > >> methods >> > >> > required from a jar file but it won't do everything. >> > >> > >> > >> > 2) The second is that users may be put off or confused by the >> > >> sheer >> > >> > size and complexity of the JAIN stack. So if only using the >> > >> > BasicMessage gets them on the first rung of the ladder then it >> > is >> > >> a >> > >> > good starting point and allows them to build up to bigger and >> > >> better >> > >> > things. >> > >> > >> > >> > 3) We also have to consider who is going to implement the JAIN >> > SIP >> > >> >> > >> > stack. If it is indeed overly complicated then no-one or a >> > single >> > >> > vendor may end up implmenting the stack and thus its >> > definition >> > >> and >> > >> > all the hard work that has gone into it is useless. >> > >> > >> > >> > On Mon, 16 Oct 2000, Chris Harris wrote: >> > >> > > Itamar, >> > >> > > >> > >> > > The idea of levelling the API based on what messages, >> > headers >> > >> and response codes >> > >> > > are understood is certainly an interesting one - minimal, >> > basic, >> > >> redirection, >> > >> > > firewall-friendly, negotiation, authentication and "full". >> > >> > > >> > >> > > jain.protocol.ip.sip >> > >> > > jain.protocol.ip.sip.header >> > >> > > jain.protocol.ip.sip.message >> > >> > > >> > >> > > could then become... >> > >> > > >> > >> > > jain.protocol.ip.sip - listener, provider, stack, general >> > >> classes used at all >> > >> > > levels >> > >> > > jain.protocol.ip.sip.header - contains base Header class >> > (and >> > >> requestHeader, >> > >> > > ResponseHeader, EntityHeader, GeneralHeader) >> > >> > > jain.protocol.ip.sip.message - contains base Message class >> > >> > > >> > >> > > jain.protocol.ip.sip.minimal - general classes used only at >> > this >> > >> level and above >> > >> > > >> > >> > > jain.protocol.ip.sip.minimal.header - headers used only at >> > this >> > >> level and above >> > >> > > jain.protocol.ip.sip.minimal.message - messages only used at >> > >> > >> this level and >> > >> > > above >> > >> > > >> > >> > > jain.protocol.ip.sip.basic - general classes used only at >> > this >> > >> level and above >> > >> > > jain.protocol.ip.sip.basic.header - headers used only at >> > this >> > >> level and above >> > >> > > jain.protocol.ip.sip.basic.message - messages used only at >> > this >> > >> level and above >> > >> > > ... >> > >> > > .... >> > >> > > jjain.protocol.ip.sip."full" - general classes only used at >> > this >> > >> level >> > >> > > jain.protocol.ip.sip."full".header - headers used only at >> > this >> > >> level >> > >> > > jain.protocol.ip.sip."full".message - messages used only at >> > this >> > >> level >> > >> > > >> > >> > > The API user could then pick the packages they need - say >> > they >> > >> initially only >> > >> > > want the minimal features, but then realise they need to use >> > >> > >> their application >> > >> > > behind a firewall - then they can simply add the >> > >> firewall-friendly package. The >> > >> > > RFC says "In general, each capability listed builds on the >> > ones >> > >> above it" but it >> > >> > > is not hard to see that firewall-friendly and authentication >> > may >> > >> be desired >> > >> > > without redirection for example. >> > >> > > >> > >> > > Is this what you hand in mind Itamar? >> > >> > >> > >> > -- >> > >> > Gethin Liddell >> > >> > Ubiquity Software Corporation >> > >> > >> > >> > http://www.ubiquity.net >> > >> > mailto:gethin@ubiquity.net >> > >> > >> > >> > _______________________________________________ >> > >> > SIP mailing list >> > >> > SIP@lists.bell-labs.com >> > >> > http://lists.bell-labs.com/mailman/listinfo/sip >> > >> >> > >> -- >> > >> M.Ranganathan >> > >> NIST Advanced Networking Technologies Group, >> > >> 100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899. >> > >> Tel: 301 975 3664 Fax: 301 590 0932 >> > >> >> > >> Hfæj)b? b²Ô^>X¬¶ÆÞ-YZnÇ(sm§ÿåSËlmée*¦ìr?¿?¨¥?©ÿ-+-SwèþÈ© >> > > >> > >> > -- >> > M.Ranganathan >> > NIST Advanced Networking Technologies Group, >> > 100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899. >> > Tel: 301 975 3664 Fax: 301 590 0932 >> > >> > Hfæj)b? b²Ô^>X¬¶ÆÞ-YZnÇ(sm§ÿåSËlmée*¦ìr?¿?¨¥?©ÿ-+-SwèþÈ© >> --------------815F573113775579630111EA Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit  

Bobby Sardana wrote:

Greetings Chris:

Just to add a pointer to this thread:

Maintaining trasaction state is an application level functionality and *shouldn't* be implemented in the base stack. For applications like state oriented proxy server, the JAIN SIP can provide enough hooks for event delivery but the state has to be maintained by the proxy server.

Is simply sending up all received requests without any kind of transaction id really enough? What are the hooks you refer to? An application like a stateful proxy server will surely be able to handle this, but what about simple services? - shouldn't the API provide a convenient means to send responses, acks, cancel etc?
 

Pleas keep up the good work. It is really appreciated.

Regards,

Bobby.Sardana@mobilerain.com

Chris Harris wrote:

"M. Ranganathan" wrote:
Hi Chris,

Thanks for replying so promptly (I am sure you are flooded with email ).

I get one or two :)
 
As you pointed out, I suppose we cannot do away with making Messages
into classes because of the tie-in with java events (unfortunately) but
I still like the notion of being able to specify  interfaces where ever
possible.
I see where you're coming from alright, and I suppose changing header classes into interfaces, could fit in with Gethin's proposal nicely?
 
 I dont quite follow  the motivation behind the following design
decision (excerpted from your reply):

Maybe I've misunderstood what you're saying - but a JAIN SIP
implementation is only stateless when it comes to call state. The
JainSipProvider implementation must maintain transaction state - it
simply exposes a reference to a transaction via the transaction id for
the convenience of the JainSipListener. The service does not have total
control over transacton state - the stack implementation does.

It appears that I have indded mis-understood the architecture.  Why
should the above be so? Can one not rely on the JainSipListener to keep
transaction state also, thereby making the stack simply a way of
recognising messages and triggering  event handlers on the basis of
message type. This would (IMHO) be a cleaner model yet.    That way,  we
can do away with transaction identifiers being passed back and forth and
keep all of this information in the handler.  ( You may have to extend
the architecture somewhat to deal with timeouts and failures so that the
handler knows about transaction failure.) In any case, if this is not a
viable idea, I would be grateful if you can explain why not (or point me
to the portion of the spec that explains why not) so I can get a better
understanding.

It would be cleaner model, and personally I am in total agreement with you - but it means the application is forced to maintain transaction state, match up headers - which has been said places too much of a burden on applications. How about finding a way to let the application choose whether or not it wants to keep transaction state?
 

Regards,

Ranga.

Chris Harris wrote:

> Hi Ranga,
>
> Response below...
>
> Chris
>
> "M. Ranganathan" wrote:
>
>> JAIN-SIP is a groovy idea. Hats off to the whole concept and many
>> thanks to Chris and
>> the JAIN-SIP team for putting together a spec and more flower power
>> to them :-) .  In
>> particular I like the notion of treating UAS,  Redirect and Proxy
>> servers as merely
>> special cases of the general notion of Services and  the idea of
>> unifying these
>> notions with an event mechanism and  event handlers.  Second, I like
>> the idea of
>> separation between a  stateless  event -oriented "stack" and a bunch
>> of event
>> handlers that are triggered by the stack with all state (including
>> transaction
>> state) being separated from the event stack via the JAIN-SIP mapping
>> layer if you
>> will.  ( Correct me if I  wax poetic but have the wrong
>> understanding....)
>
>>
>>
>> I hope I  will not be viewed as being too critical,  but I would
>> like to go  one step
>> further than what Gethin is suggesting.   I am all for using
>> interfaces as much as
>> possible and leaving class hierarchy definitions to implemeters.
>> Defining class
>> hierarchies almost lays out an implementation and involves
>> considerable rework for
>> those who have a working java-based stack, but have not used the
>> same classes. OK it
>> is just a matter of labor to map things to the JAIN-SIP class
>> hierarchy but it  IS a
>> dis-incentive.
>>
>> 1. Lets use interfaces for all messages rather than actually define
>> class
>> hierarchies  ( yes Chris has pointed out the historical precedent
>> behind actually
>> defining class hierarchies for messages. IMHO,  there has to be a
>> more compelling
>> reason than that.)
>
> I suppose all classes could be turned into interfaces, except for the
> Message classes which must extend java.util.EventObject to fit into
> the JAIN framework.
>
>>
>>
>> 2. The tie-in with the JAVA event mechanism has necessitated the
>> explicit definition
>> of class hierarchies in certain places.  Why not use callbacks
>> instead and do away
>> with this dependency as well?  (Basically the same thing as events
>> but does not tie
>> into the JAVA event mechanism and its associated limitations.)
>
> Unfortunately the JAIN framework expilicitly relies on the Java Event
> model, and I don't think callbacks would be accepted within the JAIN
> community.
>
>>
>>
>> Nice work and keep it rolling!  Thanks.
>
> Couldn't do it without you guys - thank you!
>
>>
>>
>> Ranga.
>>
>> Gethin Liddell wrote:
>>
>> > All,
>> >
>> > This idea of abstraction of the JAIN API is certainly a valid and
>> > interesting idea.  However, i'm a bit concerened that the proposed
>>
>> > solution of many different packages, will only seek to complicate
>> and
>> > maybe enlarge the API.
>> >
>> > I too see no reason why there is an EntityHeader etc... and i also
>> do
>> > not see any requirement for an InviteMessage, AckMessage etc...
>> >
>> > How about if the format of the API remains as is:
>> >
>> > jain.protocol.ip.sip
>> > jain.protocol.ip.sip.header
>> > jain.protocol.ip.sip.message
>> >
>> > except that the messages available in the message package
>> consisted of
>> > BasicRequest/Response, MinimalRequest/Response etc... where each
>> > message is extened in turn (e.g. Minimal extends Basic, Moderate
>> > extends Minimal etc...), of course as Chris points out it is not
>> hard
>> > to see that a combination would be required that is not provided.
>> So
>> > in the interest of flexibility, it could be possible for the user
>> to
>> > plug-in to the message class what extra headers it requires.  The
>> only
>> > issue then is that the user will have to use a "public Header
>> > getHeader(String headerName)" and then cast the header to their
>> desired
>> > header type. Either that or create their own Message class
>> > (extending the current ones) that simply does the casting
>> automatically
>> > for them.  Then after compiling, run an obfuscator on the code and
>> it
>> > will automatically extract and only extract the Message, Headers
>> and
>> > even methods that are used.
>> >
>> > This then will also cut down on the number of methods in the
>> Provider
>> > as there will be no need for the sendAck(AckMessage),
>> > sendInvite(InviteMessage) etc.. as they would be replaced by the
>> > single method sendRequest(RequestMessage).
>> >
>> > I personally see three arguments for keeping the JAIN SIP stack as
>> small
>> > as possible:
>> >
>> > 1) The first is for embedded applications where stack size has to
>> be
>> > kept to a minimum as memory is at a premium.  So if just using the
>>
>> > Basic message suffices then this will compile and run with a small
>>
>> > number of classes present from the stack.  Don't forget,
>> obfuscation
>> > will help in extracting only the Messages, Headers and even
>> methods
>> > required from a jar file but it won't do everything.
>> >
>> > 2) The second is that users may be put off or confused by the
>> sheer
>> > size and complexity of the JAIN stack.  So if only using the
>> > BasicMessage gets them on the first rung of the ladder then it is
>> a
>> > good starting point and allows them to build up to bigger and
>> better
>> > things.
>> >
>> > 3) We also have to consider who is going to implement the JAIN SIP
>>
>> > stack. If it is indeed overly complicated then no-one or a single
>> > vendor may end up implmenting the stack and thus its definition
>> and
>> > all the hard work that has gone into it is useless.
>> >
>> > On Mon, 16 Oct 2000, Chris Harris wrote:
>> > > Itamar,
>> > >
>> > > The idea of levelling the API based on what messages, headers
>> and response codes
>> > > are understood is certainly an interesting one - minimal, basic,
>> redirection,
>> > > firewall-friendly, negotiation, authentication and "full".
>> > >
>> > > jain.protocol.ip.sip
>> > > jain.protocol.ip.sip.header
>> > > jain.protocol.ip.sip.message
>> > >
>> > > could then become...
>> > >
>> > > jain.protocol.ip.sip - listener, provider, stack, general
>> classes used at all
>> > > levels
>> > > jain.protocol.ip.sip.header - contains base Header class (and
>> requestHeader,
>> > > ResponseHeader, EntityHeader, GeneralHeader)
>> > > jain.protocol.ip.sip.message - contains base Message class
>> > >
>> > > jain.protocol.ip.sip.minimal - general classes used only at this
>> level and above
>> > >
>> > > jain.protocol.ip.sip.minimal.header - headers used only at this
>> level and above
>> > > jain.protocol.ip.sip.minimal.message - messages only used at
>> this level and
>> > > above
>> > >
>> > > jain.protocol.ip.sip.basic - general classes used only at this
>> level and above
>> > > jain.protocol.ip.sip.basic.header - headers used only at this
>> level and above
>> > > jain.protocol.ip.sip.basic.message - messages used only at this
>> level and above
>> > > ...
>> > > ....
>> > > jjain.protocol.ip.sip."full" - general classes only used at this
>> level
>> > > jain.protocol.ip.sip."full".header - headers used only at this
>> level
>> > > jain.protocol.ip.sip."full".message - messages used only at this
>> level
>> > >
>> > > The API user could then pick the packages they need - say they
>> initially only
>> > > want the minimal features, but then realise they need to use
>> their application
>> > > behind a firewall - then they can simply add the
>> firewall-friendly package. The
>> > > RFC says "In general, each capability listed builds on the ones
>> above it" but it
>> > > is not hard to see that firewall-friendly and authentication may
>> be desired
>> > > without redirection for example.
>> > >
>> > > Is this what you hand in mind Itamar?
>> >
>> > --
>> > Gethin Liddell
>> > Ubiquity Software Corporation
>> >
>> > http://www.ubiquity.net
>> > mailto:gethin@ubiquity.net
>> >
>> > _______________________________________________
>> > SIP mailing list
>> > SIP@lists.bell-labs.com
>> > http://lists.bell-labs.com/mailman/listinfo/sip
>>
>> --
>> M.Ranganathan
>> NIST Advanced Networking Technologies Group,
>> 100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899.
>> Tel: 301 975 3664 Fax: 301 590 0932
>>
>> Hfæj)b? b²Ô^>X¬¶ÆÞ-YZnÇ(sm§ÿåSËlmée*¦ìr?¿?¨¥?©ÿ-+-SwèþÈ©
>

--
M.Ranganathan
NIST Advanced Networking Technologies Group,
100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899.
Tel: 301 975 3664 Fax: 301 590 0932

Hfæj)b? b²Ô^>X¬¶ÆÞ-YZnÇ(sm§ÿåSËlmée*¦ìr?¿?¨¥?©ÿ-+-SwèþÈ©

--------------815F573113775579630111EA-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 18 13:07:07 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA01326 for ; Wed, 18 Oct 2000 13:07:05 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2286244384; Wed, 18 Oct 2000 12:07:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 91CC044336 for ; Wed, 18 Oct 2000 12:06:50 -0400 (EDT) Received: from dynamicsoft.com (userac41.ie.uudial.com [212.120.133.240]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id NAA27980; Wed, 18 Oct 2000 13:08:52 -0400 (EDT) Message-ID: <39EDD8B4.4B48BA67@dynamicsoft.com> From: Chris Harris Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 Cc: sip@lists.bell-labs.com, "'SIPForum list'" , jainsip@sun.com Subject: Re: [SIP] JAIN SIP Specification References: <00101814092004.10136@gethin> <39EDB4AC.21D28150@dynamicsoft.com> <00101817321606.10136@gethin> Content-Type: multipart/alternative; boundary="------------59A37250B6D470D04D9A58E9" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 18 Oct 2000 18:07:00 +0100 --------------59A37250B6D470D04D9A58E9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit More comments... Gethin Liddell wrote: > Hi Chris, check comments in-line: > > On Wed, 18 Oct 2000, Chris Harris wrote: > > > > PS - I'm looking forward to seeing you at the JAIN Meeting next week! > > likewise, should be fun ;-) > > > Gethin Liddell wrote: > > > > I have removed EnityHeader etc...as for the RequestMessage classes - different classes > > exist because the headers applicable to each are different - hence the accessor > > methods on each are different. I guess we could have just a RequestMessage class - > > with accessor methods for only the headers common to all 6 methods, and then the > > user/implementor has to use the generic header methods for any other headers. If this > > is the case, then I don't think there is any need for layering the API as mentioned. > > My only concern is about the Ack and Cancel Messages, which although are requests - > > can in a sense be thought of as being logically separate to the other requests. > > I see no real problem with having a base RequestMethod with a basic > subset of methods present and no InviteMessage etc... So it may be > possible for a BYE to be sent with a Subject header in it. so what? > if the user really wants to do something dull like that then we can't > stop them anyway. Its hardly gonna crash anyone. I suppose not. > > > > > > > > > > > How about if the format of the API remains as is: > > > > > > jain.protocol.ip.sip > > > jain.protocol.ip.sip.header > > > jain.protocol.ip.sip.message > > > > > > except that the messages available in the message package consisted of > > > BasicRequest/Response, MinimalRequest/Response etc... where each > > > message is extened in turn (e.g. Minimal extends Basic, Moderate > > > extends Minimal etc...), of course as Chris points out it is not hard > > > to see that a combination would be required that is not provided. So > > > in the interest of flexibility, it could be possible for the user to > > > plug-in to the message class what extra headers it requires. The only > > > issue then is that the user will have to use a "public Header > > > getHeader(String headerName)" and then cast the header to their desired > > > header type. Either that or create their own Message class > > > (extending the current ones) that simply does the casting automatically > > > for them. Then after compiling, run an obfuscator on the code and it > > > will automatically extract and only extract the Message, Headers and > > > even methods that are used. > > > > > > This then will also cut down on the number of methods in the Provider > > > as there will be no need for the sendAck(AckMessage), > > > sendInvite(InviteMessage) etc.. as they would be replaced by the > > > single method sendRequest(RequestMessage). > > > > As I mentioned above, it may be useful to keep sendAck and sendCancel in addition to > > sendRequest. > > Again i don't really see why. The stack will have to examine the > method anyway for invite or other so it can easily understand that it > is an ACK or CANCEL. If what your trying to do is make it easy for the > stack to behave correctly on a CANCEL then i don't really think we are > gaining anything by having a sendCancel() method. The convenience methods e.g. sendCancel(clientTransactionId) were what I had in mind - now the application has to keep transaction state - but as Bobby suggests - this may be correct... > > > Also can i have some feed back on the idea of plugins. At the moment > it is only possible for a proprietary header to be constructed by doing > a getHeader() call and then parsing the header after a toString() (as > far as i can see). Would it not be nice to provide a way for the header > to automatically be constructed? That is can we not notify the provider > or messge or whatever at an early point of an additional header format > and expect that header format back when a getHeader(String MyHeader) > call is made. By that i mean can we not do something like the > following: > > //at init > Message.notifyOfProprietaryHeader(new MyHeader()); > > //then when message comes in > MyHeader myHeader = (MyHeader) message.getHeader("myheader"); Interesting - I suppose we could have some kind of header class registry in Message to match option tags to classes? > > > > *snip* > > Three very good reasons for using this Public Review period to make JAIN SIP realise > > its full potential! > > Can i ask, why is the public review only open until the 28th and what > happens after that? Just that there seems to be a good response from > the group at large and i think that any changes that occur will need to > be discussed further. The Public Review ccan be between 30 and 90 days - I went for the middle road - 45 days. I think we can extend it if necessary. > > > -- > Gethin Liddell > Ubiquity Software Corporation > > http://www.ubiquity.net > mailto:gethin@ubiquity.net --------------59A37250B6D470D04D9A58E9 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit More comments...

Gethin Liddell wrote:

Hi Chris, check comments in-line:

On Wed, 18 Oct 2000, Chris Harris wrote:
>
> PS - I'm looking forward to seeing you at the JAIN Meeting next week!

likewise, should be fun ;-)

> Gethin Liddell wrote:
>
> I have removed EnityHeader etc...as for the RequestMessage classes - different classes
> exist because the headers applicable to each are different - hence the accessor
> methods on each are different. I guess we could have just a RequestMessage class -
> with accessor methods for only the headers common to all 6 methods, and then the
> user/implementor has to use the generic header methods for any other headers. If this
> is the case, then I don't think there is any need for layering the API as mentioned.
> My only concern is about the Ack and Cancel Messages, which although are requests -
> can in a sense be thought of as being logically separate to the other requests.

I see no real problem with having a base RequestMethod with a basic
subset of methods present and no InviteMessage etc...  So it may be
possible for a BYE to be sent with a Subject header in it.  so what?
if the user really wants to do something dull like that then we can't
stop them anyway.  Its hardly gonna crash anyone.

I suppose not.
 

> >
> >
> > How about if the format of the API remains as is:
> >
> > jain.protocol.ip.sip
> > jain.protocol.ip.sip.header
> > jain.protocol.ip.sip.message
> >
> > except that the messages available in the message package consisted of
> > BasicRequest/Response, MinimalRequest/Response etc... where each
> > message is extened in turn (e.g. Minimal extends Basic, Moderate
> > extends Minimal etc...), of course as Chris points out it is not hard
> > to see that a combination would be required that is not provided. So
> > in the interest of flexibility, it could be possible for the user to
> > plug-in to the message class what extra headers it requires.  The only
> > issue then is that the user will have to use a "public Header
> > getHeader(String headerName)" and then cast the header to their desired
> > header type. Either that or create their own Message class
> > (extending the current ones) that simply does the casting automatically
> > for them.  Then after compiling, run an obfuscator on the code and it
> > will automatically extract and only extract the Message, Headers and
> > even methods that are used.
> >
> > This then will also cut down on the number of methods in the Provider
> > as there will be no need for the sendAck(AckMessage),
> > sendInvite(InviteMessage) etc.. as they would be replaced by the
> > single method sendRequest(RequestMessage).
>
> As I mentioned above, it may be useful to keep sendAck and sendCancel in addition to
> sendRequest.

Again i don't really see why.  The stack will have to examine the
method anyway for invite or other so it can easily understand that it
is an ACK or CANCEL.  If what your trying to do is make it easy for the
stack to behave correctly on a CANCEL then i don't really think we are
gaining anything by having a sendCancel() method.

The convenience methods e.g. sendCancel(clientTransactionId) were what I had in mind - now the application has to keep transaction state - but as Bobby suggests - this may be correct...
 

Also can i have some feed back on the idea of plugins.  At the moment
it is only possible for a proprietary header to be constructed by doing
a getHeader() call and then parsing the header after a toString() (as
far as i can see).  Would it not be nice to provide a way for the header
to automatically be constructed?  That is can we not notify the provider
or messge or whatever at an early point of an additional header format
and expect that header format back when a getHeader(String MyHeader)
call is made.  By that i mean can we not do something like the
following:

//at init
Message.notifyOfProprietaryHeader(new MyHeader());

//then when message comes in
MyHeader myHeader = (MyHeader) message.getHeader("myheader");


Interesting - I suppose we could have some kind of header class registry in Message to match option tags to classes?

 

> *snip*
> Three very good reasons for using this Public Review period to make JAIN SIP realise
> its full potential!

Can i ask, why is the public review only open until the 28th and what
happens after that?  Just that there seems to be a good response from
the group at large and i think that any changes that occur will need to
be discussed further.

The Public Review ccan be between 30 and 90 days - I went for the middle road - 45 days. I think we can extend it if necessary.
 

--
Gethin Liddell
Ubiquity Software Corporation

http://www.ubiquity.net
mailto:gethin@ubiquity.net

--------------59A37250B6D470D04D9A58E9-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 18 13:10:14 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA01754 for ; Wed, 18 Oct 2000 13:10:11 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5252B443A5; Wed, 18 Oct 2000 12:08:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from guardian1.tlv.radvision.com (unknown [212.143.185.30]) by lists.bell-labs.com (Postfix) with ESMTP id 950284434C for ; Wed, 18 Oct 2000 12:07:37 -0400 (EDT) Received: from nt-mail.tlv.radvision.com ([172.20.2.100]) by guardian1.tlv.radvision.com (Post.Office MTA v3.5.3 release 223 ID# 0-0U10L2S100V35) with ESMTP id com; Wed, 18 Oct 2000 20:06:23 +0200 Received: by NT-MAIL with Internet Mail Service (5.5.2650.21) id ; Wed, 18 Oct 2000 19:07:44 +0200 Message-ID: From: Itamar Gilad To: "'Bobby Sardana'" , discussion@sipforum.org Cc: mranga@nist.gov, sip@lists.bell-labs.com, jainsip@sun.com Subject: RE: [SIPFORUM] Re: [SIP] JAIN SIP Specification MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C03925.EE001590" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 18 Oct 2000 19:07:43 +0200 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_01C03925.EE001590 Content-Type: text/plain; charset="iso-8859-1" Hi again Chris, I'd like to re-emphasize what Bobby says below. The JAIN SIP specification presented here seems to deal just with the "message layer" i.e. parsing, encoding, message and message part containers. I'd like to join those who commend the fine and comprehensive work done. However, this layer has nothing to do with transactions and their state. It would be a mistake to rely on it to retain 'transaction-ids' and associate messages to them (please correct me if I'm misinterpreting your meaning). Note that identifying a transaction from a message is not a trivial matter and continuously more message fields are added to the "transaction key" in order to deal with spiraling, merging etc. A more straight-forward approach would be to put this functionality in the "transaction layer" where transaction objects live and make a clean separation between the two layers. Regards Itamar -----Original Message----- From: Bobby Sardana [mailto:bobby.sardana@mobilerain.com] Sent: Wed, October 18, 2000 6:39 PM To: discussion@sipforum.org Cc: mranga@nist.gov; sip@lists.bell-labs.com; jainsip@sun.com Subject: Re: [SIPFORUM] Re: [SIP] JAIN SIP Specification Greetings Chris: Just to add a pointer to this thread: Maintaining trasaction state is an application level functionality and *shouldn't* be implemented in the base stack. For applications like state oriented proxy server, the JAIN SIP can provide enough hooks for event delivery but the state has to be maintained by the proxy server. Pleas keep up the good work. It is really appreciated. Regards, Bobby.Sardana@mobilerain.com Chris Harris wrote: "M. Ranganathan" wrote: Hi Chris, Thanks for replying so promptly (I am sure you are flooded with email ). I get one or two :) As you pointed out, I suppose we cannot do away with making Messages into classes because of the tie-in with java events (unfortunately) but I still like the notion of being able to specify interfaces where ever possible. I see where you're coming from alright, and I suppose changing header classes into interfaces, could fit in with Gethin's proposal nicely? I dont quite follow the motivation behind the following design decision (excerpted from your reply): Maybe I've misunderstood what you're saying - but a JAIN SIP implementation is only stateless when it comes to call state. The JainSipProvider implementation must maintain transaction state - it simply exposes a reference to a transaction via the transaction id for the convenience of the JainSipListener. The service does not have total control over transacton state - the stack implementation does. It appears that I have indded mis-understood the architecture. Why should the above be so? Can one not rely on the JainSipListener to keep transaction state also, thereby making the stack simply a way of recognising messages and triggering event handlers on the basis of message type. This would (IMHO) be a cleaner model yet. That way, we can do away with transaction identifiers being passed back and forth and keep all of this information in the handler. ( You may have to extend the architecture somewhat to deal with timeouts and failures so that the handler knows about transaction failure.) In any case, if this is not a viable idea, I would be grateful if you can explain why not (or point me to the portion of the spec that explains why not) so I can get a better understanding. It would be cleaner model, and personally I am in total agreement with you - but it means the application is forced to maintain transaction state, match up headers - which has been said places too much of a burden on applications. How about finding a way to let the application choose whether or not it wants to keep transaction state? Regards, Ranga. Chris Harris wrote: > Hi Ranga, > > Response below... > > Chris > > "M. Ranganathan" wrote: > >> JAIN-SIP is a groovy idea. Hats off to the whole concept and many >> thanks to Chris and >> the JAIN-SIP team for putting together a spec and more flower power >> to them :-) . In >> particular I like the notion of treating UAS, Redirect and Proxy >> servers as merely >> special cases of the general notion of Services and the idea of >> unifying these >> notions with an event mechanism and event handlers. Second, I like >> the idea of >> separation between a stateless event -oriented "stack" and a bunch >> of event >> handlers that are triggered by the stack with all state (including >> transaction >> state) being separated from the event stack via the JAIN-SIP mapping >> layer if you >> will. ( Correct me if I wax poetic but have the wrong >> understanding....) > >> >> >> I hope I will not be viewed as being too critical, but I would >> like to go one step >> further than what Gethin is suggesting. I am all for using >> interfaces as much as >> possible and leaving class hierarchy definitions to implemeters. >> Defining class >> hierarchies almost lays out an implementation and involves >> considerable rework for >> those who have a working java-based stack, but have not used the >> same classes. OK it >> is just a matter of labor to map things to the JAIN-SIP class >> hierarchy but it IS a >> dis-incentive. >> >> 1. Lets use interfaces for all messages rather than actually define >> class >> hierarchies ( yes Chris has pointed out the historical precedent >> behind actually >> defining class hierarchies for messages. IMHO, there has to be a >> more compelling >> reason than that.) > > I suppose all classes could be turned into interfaces, except for the > Message classes which must extend java.util.EventObject to fit into > the JAIN framework. > >> >> >> 2. The tie-in with the JAVA event mechanism has necessitated the >> explicit definition >> of class hierarchies in certain places. Why not use callbacks >> instead and do away >> with this dependency as well? (Basically the same thing as events >> but does not tie >> into the JAVA event mechanism and its associated limitations.) > > Unfortunately the JAIN framework expilicitly relies on the Java Event > model, and I don't think callbacks would be accepted within the JAIN > community. > >> >> >> Nice work and keep it rolling! Thanks. > > Couldn't do it without you guys - thank you! > >> >> >> Ranga. >> >> Gethin Liddell wrote: >> >> > All, >> > >> > This idea of abstraction of the JAIN API is certainly a valid and >> > interesting idea. However, i'm a bit concerened that the proposed >> >> > solution of many different packages, will only seek to complicate >> and >> > maybe enlarge the API. >> > >> > I too see no reason why there is an EntityHeader etc... and i also >> do >> > not see any requirement for an InviteMessage, AckMessage etc... >> > >> > How about if the format of the API remains as is: >> > >> > jain.protocol.ip.sip >> > jain.protocol.ip.sip.header >> > jain.protocol.ip.sip.message >> > >> > except that the messages available in the message package >> consisted of >> > BasicRequest/Response, MinimalRequest/Response etc... where each >> > message is extened in turn (e.g. Minimal extends Basic, Moderate >> > extends Minimal etc...), of course as Chris points out it is not >> hard >> > to see that a combination would be required that is not provided. >> So >> > in the interest of flexibility, it could be possible for the user >> to >> > plug-in to the message class what extra headers it requires. The >> only >> > issue then is that the user will have to use a "public Header >> > getHeader(String headerName)" and then cast the header to their >> desired >> > header type. Either that or create their own Message class >> > (extending the current ones) that simply does the casting >> automatically >> > for them. Then after compiling, run an obfuscator on the code and >> it >> > will automatically extract and only extract the Message, Headers >> and >> > even methods that are used. >> > >> > This then will also cut down on the number of methods in the >> Provider >> > as there will be no need for the sendAck(AckMessage), >> > sendInvite(InviteMessage) etc.. as they would be replaced by the >> > single method sendRequest(RequestMessage). >> > >> > I personally see three arguments for keeping the JAIN SIP stack as >> small >> > as possible: >> > >> > 1) The first is for embedded applications where stack size has to >> be >> > kept to a minimum as memory is at a premium. So if just using the >> >> > Basic message suffices then this will compile and run with a small >> >> > number of classes present from the stack. Don't forget, >> obfuscation >> > will help in extracting only the Messages, Headers and even >> methods >> > required from a jar file but it won't do everything. >> > >> > 2) The second is that users may be put off or confused by the >> sheer >> > size and complexity of the JAIN stack. So if only using the >> > BasicMessage gets them on the first rung of the ladder then it is >> a >> > good starting point and allows them to build up to bigger and >> better >> > things. >> > >> > 3) We also have to consider who is going to implement the JAIN SIP >> >> > stack. If it is indeed overly complicated then no-one or a single >> > vendor may end up implmenting the stack and thus its definition >> and >> > all the hard work that has gone into it is useless. >> > >> > On Mon, 16 Oct 2000, Chris Harris wrote: >> > > Itamar, >> > > >> > > The idea of levelling the API based on what messages, headers >> and response codes >> > > are understood is certainly an interesting one - minimal, basic, >> redirection, >> > > firewall-friendly, negotiation, authentication and "full". >> > > >> > > jain.protocol.ip.sip >> > > jain.protocol.ip.sip.header >> > > jain.protocol.ip.sip.message >> > > >> > > could then become... >> > > >> > > jain.protocol.ip.sip - listener, provider, stack, general >> classes used at all >> > > levels >> > > jain.protocol.ip.sip.header - contains base Header class (and >> requestHeader, >> > > ResponseHeader, EntityHeader, GeneralHeader) >> > > jain.protocol.ip.sip.message - contains base Message class >> > > >> > > jain.protocol.ip.sip.minimal - general classes used only at this >> level and above >> > > >> > > jain.protocol.ip.sip.minimal.header - headers used only at this >> level and above >> > > jain.protocol.ip.sip.minimal.message - messages only used at >> this level and >> > > above >> > > >> > > jain.protocol.ip.sip.basic - general classes used only at this >> level and above >> > > jain.protocol.ip.sip.basic.header - headers used only at this >> level and above >> > > jain.protocol.ip.sip.basic.message - messages used only at this >> level and above >> > > ... >> > > .... >> > > jjain.protocol.ip.sip."full" - general classes only used at this >> level >> > > jain.protocol.ip.sip."full".header - headers used only at this >> level >> > > jain.protocol.ip.sip."full".message - messages used only at this >> level >> > > >> > > The API user could then pick the packages they need - say they >> initially only >> > > want the minimal features, but then realise they need to use >> their application >> > > behind a firewall - then they can simply add the >> firewall-friendly package. The >> > > RFC says "In general, each capability listed builds on the ones >> above it" but it >> > > is not hard to see that firewall-friendly and authentication may >> be desired >> > > without redirection for example. >> > > >> > > Is this what you hand in mind Itamar? >> > >> > -- >> > Gethin Liddell >> > Ubiquity Software Corporation >> > >> > http://www.ubiquity.net >> > mailto:gethin@ubiquity.net >> > >> > _______________________________________________ >> > SIP mailing list >> > SIP@lists.bell-labs.com >> > http://lists.bell-labs.com/mailman/listinfo/sip >> >> -- >> M.Ranganathan >> NIST Advanced Networking Technologies Group, >> 100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899. >> Tel: 301 975 3664 Fax: 301 590 0932 >> >> Hfæj)b? b²Ô^>X¬¶ÆÞ-YZnÇ(sm§ÿåSËlmée*¦ìr?¿?¨¥?©ÿ-+-SwèþÈ© > -- M.Ranganathan NIST Advanced Networking Technologies Group, 100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899. Tel: 301 975 3664 Fax: 301 590 0932 Hfæj)b? b²Ô^>X¬¶ÆÞ-YZnÇ(sm§ÿåSËlmée*¦ìr?¿?¨¥?©ÿ-+-SwèþÈ© ------_=_NextPart_001_01C03925.EE001590 Content-Type: text/html; charset="iso-8859-1"
Hi again Chris,
 
I'd like to re-emphasize what Bobby says below.  The JAIN SIP specification presented here seems to deal just with the "message layer" i.e. parsing, encoding, message and message part containers.  I'd like to join those who commend the fine and comprehensive work done.  However, this layer has nothing to do with transactions and their state.  It would be a mistake to rely on it to retain 'transaction-ids' and associate messages to them (please correct me if I'm misinterpreting your meaning). Note that identifying a transaction from a message is not a trivial matter and continuously more message fields are added to the "transaction key" in order to deal with spiraling, merging etc. A more straight-forward approach would be to put this functionality in the "transaction layer" where transaction objects live and make a clean separation between the two layers.
 
Regards
  Itamar
-----Original Message-----
From: Bobby Sardana [mailto:bobby.sardana@mobilerain.com]
Sent: Wed, October 18, 2000 6:39 PM
To: discussion@sipforum.org
Cc: mranga@nist.gov; sip@lists.bell-labs.com; jainsip@sun.com
Subject: Re: [SIPFORUM] Re: [SIP] JAIN SIP Specification

Greetings Chris:

Just to add a pointer to this thread:

Maintaining trasaction state is an application level functionality and *shouldn't* be implemented in the base stack. For applications like state oriented proxy server, the JAIN SIP can provide enough hooks for event delivery but the state has to be maintained by the proxy server.

Pleas keep up the good work. It is really appreciated.

Regards,

Bobby.Sardana@mobilerain.com

Chris Harris wrote:

"M. Ranganathan" wrote:
Hi Chris,

Thanks for replying so promptly (I am sure you are flooded with email ).

I get one or two :)

As you pointed out, I suppose we cannot do away with making Messages
into classes because of the tie-in with java events (unfortunately) but
I still like the notion of being able to specify  interfaces where ever
possible.
I see where you're coming from alright, and I suppose changing header classes into interfaces, could fit in with Gethin's proposal nicely?

 I dont quite follow  the motivation behind the following design
decision (excerpted from your reply):

Maybe I've misunderstood what you're saying - but a JAIN SIP
implementation is only stateless when it comes to call state. The
JainSipProvider implementation must maintain transaction state - it
simply exposes a reference to a transaction via the transaction id for
the convenience of the JainSipListener. The service does not have total
control over transacton state - the stack implementation does.

It appears that I have indded mis-understood the architecture.  Why
should the above be so? Can one not rely on the JainSipListener to keep
transaction state also, thereby making the stack simply a way of
recognising messages and triggering  event handlers on the basis of
message type. This would (IMHO) be a cleaner model yet.    That way,  we
can do away with transaction identifiers being passed back and forth and
keep all of this information in the handler.  ( You may have to extend
the architecture somewhat to deal with timeouts and failures so that the
handler knows about transaction failure.) In any case, if this is not a
viable idea, I would be grateful if you can explain why not (or point me
to the portion of the spec that explains why not) so I can get a better
understanding.

It would be cleaner model, and personally I am in total agreement with you - but it means the application is forced to maintain transaction state, match up headers - which has been said places too much of a burden on applications. How about finding a way to let the application choose whether or not it wants to keep transaction state?
 

Regards,

Ranga.

Chris Harris wrote:

> Hi Ranga,
>
> Response below...
>
> Chris
>
> "M. Ranganathan" wrote:
>
>> JAIN-SIP is a groovy idea. Hats off to the whole concept and many
>> thanks to Chris and
>> the JAIN-SIP team for putting together a spec and more flower power
>> to them :-) .  In
>> particular I like the notion of treating UAS,  Redirect and Proxy
>> servers as merely
>> special cases of the general notion of Services and  the idea of
>> unifying these
>> notions with an event mechanism and  event handlers.  Second, I like
>> the idea of
>> separation between a  stateless  event -oriented "stack" and a bunch
>> of event
>> handlers that are triggered by the stack with all state (including
>> transaction
>> state) being separated from the event stack via the JAIN-SIP mapping
>> layer if you
>> will.  ( Correct me if I  wax poetic but have the wrong
>> understanding....)
>
>>
>>
>> I hope I  will not be viewed as being too critical,  but I would
>> like to go  one step
>> further than what Gethin is suggesting.   I am all for using
>> interfaces as much as
>> possible and leaving class hierarchy definitions to implemeters.
>> Defining class
>> hierarchies almost lays out an implementation and involves
>> considerable rework for
>> those who have a working java-based stack, but have not used the
>> same classes. OK it
>> is just a matter of labor to map things to the JAIN-SIP class
>> hierarchy but it  IS a
>> dis-incentive.
>>
>> 1. Lets use interfaces for all messages rather than actually define
>> class
>> hierarchies  ( yes Chris has pointed out the historical precedent
>> behind actually
>> defining class hierarchies for messages. IMHO,  there has to be a
>> more compelling
>> reason than that.)
>
> I suppose all classes could be turned into interfaces, except for the
> Message classes which must extend java.util.EventObject to fit into
> the JAIN framework.
>
>>
>>
>> 2. The tie-in with the JAVA event mechanism has necessitated the
>> explicit definition
>> of class hierarchies in certain places.  Why not use callbacks
>> instead and do away
>> with this dependency as well?  (Basically the same thing as events
>> but does not tie
>> into the JAVA event mechanism and its associated limitations.)
>
> Unfortunately the JAIN framework expilicitly relies on the Java Event
> model, and I don't think callbacks would be accepted within the JAIN
> community.
>
>>
>>
>> Nice work and keep it rolling!  Thanks.
>
> Couldn't do it without you guys - thank you!
>
>>
>>
>> Ranga.
>>
>> Gethin Liddell wrote:
>>
>> > All,
>> >
>> > This idea of abstraction of the JAIN API is certainly a valid and
>> > interesting idea.  However, i'm a bit concerened that the proposed
>>
>> > solution of many different packages, will only seek to complicate
>> and
>> > maybe enlarge the API.
>> >
>> > I too see no reason why there is an EntityHeader etc... and i also
>> do
>> > not see any requirement for an InviteMessage, AckMessage etc...
>> >
>> > How about if the format of the API remains as is:
>> >
>> > jain.protocol.ip.sip
>> > jain.protocol.ip.sip.header
>> > jain.protocol.ip.sip.message
>> >
>> > except that the messages available in the message package
>> consisted of
>> > BasicRequest/Response, MinimalRequest/Response etc... where each
>> > message is extened in turn (e.g. Minimal extends Basic, Moderate
>> > extends Minimal etc...), of course as Chris points out it is not
>> hard
>> > to see that a combination would be required that is not provided.
>> So
>> > in the interest of flexibility, it could be possible for the user
>> to
>> > plug-in to the message class what extra headers it requires.  The
>> only
>> > issue then is that the user will have to use a "public Header
>> > getHeader(String headerName)" and then cast the header to their
>> desired
>> > header type. Either that or create their own Message class
>> > (extending the current ones) that simply does the casting
>> automatically
>> > for them.  Then after compiling, run an obfuscator on the code and
>> it
>> > will automatically extract and only extract the Message, Headers
>> and
>> > even methods that are used.
>> >
>> > This then will also cut down on the number of methods in the
>> Provider
>> > as there will be no need for the sendAck(AckMessage),
>> > sendInvite(InviteMessage) etc.. as they would be replaced by the
>> > single method sendRequest(RequestMessage).
>> >
>> > I personally see three arguments for keeping the JAIN SIP stack as
>> small
>> > as possible:
>> >
>> > 1) The first is for embedded applications where stack size has to
>> be
>> > kept to a minimum as memory is at a premium.  So if just using the
>>
>> > Basic message suffices then this will compile and run with a small
>>
>> > number of classes present from the stack.  Don't forget,
>> obfuscation
>> > will help in extracting only the Messages, Headers and even
>> methods
>> > required from a jar file but it won't do everything.
>> >
>> > 2) The second is that users may be put off or confused by the
>> sheer
>> > size and complexity of the JAIN stack.  So if only using the
>> > BasicMessage gets them on the first rung of the ladder then it is
>> a
>> > good starting point and allows them to build up to bigger and
>> better
>> > things.
>> >
>> > 3) We also have to consider who is going to implement the JAIN SIP
>>
>> > stack. If it is indeed overly complicated then no-one or a single
>> > vendor may end up implmenting the stack and thus its definition
>> and
>> > all the hard work that has gone into it is useless.
>> >
>> > On Mon, 16 Oct 2000, Chris Harris wrote:
>> > > Itamar,
>> > >
>> > > The idea of levelling the API based on what messages, headers
>> and response codes
>> > > are understood is certainly an interesting one - minimal, basic,
>> redirection,
>> > > firewall-friendly, negotiation, authentication and "full".
>> > >
>> > > jain.protocol.ip.sip
>> > > jain.protocol.ip.sip.header
>> > > jain.protocol.ip.sip.message
>> > >
>> > > could then become...
>> > >
>> > > jain.protocol.ip.sip - listener, provider, stack, general
>> classes used at all
>> > > levels
>> > > jain.protocol.ip.sip.header - contains base Header class (and
>> requestHeader,
>> > > ResponseHeader, EntityHeader, GeneralHeader)
>> > > jain.protocol.ip.sip.message - contains base Message class
>> > >
>> > > jain.protocol.ip.sip.minimal - general classes used only at this
>> level and above
>> > >
>> > > jain.protocol.ip.sip.minimal.header - headers used only at this
>> level and above
>> > > jain.protocol.ip.sip.minimal.message - messages only used at
>> this level and
>> > > above
>> > >
>> > > jain.protocol.ip.sip.basic - general classes used only at this
>> level and above
>> > > jain.protocol.ip.sip.basic.header - headers used only at this
>> level and above
>> > > jain.protocol.ip.sip.basic.message - messages used only at this
>> level and above
>> > > ...
>> > > ....
>> > > jjain.protocol.ip.sip."full" - general classes only used at this
>> level
>> > > jain.protocol.ip.sip."full".header - headers used only at this
>> level
>> > > jain.protocol.ip.sip."full".message - messages used only at this
>> level
>> > >
>> > > The API user could then pick the packages they need - say they
>> initially only
>> > > want the minimal features, but then realise they need to use
>> their application
>> > > behind a firewall - then they can simply add the
>> firewall-friendly package. The
>> > > RFC says "In general, each capability listed builds on the ones
>> above it" but it
>> > > is not hard to see that firewall-friendly and authentication may
>> be desired
>> > > without redirection for example.
>> > >
>> > > Is this what you hand in mind Itamar?
>> >
>> > --
>> > Gethin Liddell
>> > Ubiquity Software Corporation
>> >
>> > http://www.ubiquity.net
>> > mailto:gethin@ubiquity.net
>> >
>> > _______________________________________________
>> > SIP mailing list
>> > SIP@lists.bell-labs.com
>> > http://lists.bell-labs.com/mailman/listinfo/sip
>>
>> --
>> M.Ranganathan
>> NIST Advanced Networking Technologies Group,
>> 100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899.
>> Tel: 301 975 3664 Fax: 301 590 0932
>>
>> Hfæj)b? b²Ô^>X¬¶ÆÞ-YZnÇ(sm§ÿåSËlmée*¦ìr?¿?¨¥?©ÿ-+-SwèþÈ©
>

--
M.Ranganathan
NIST Advanced Networking Technologies Group,
100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899.
Tel: 301 975 3664 Fax: 301 590 0932

Hfæj)b? b²Ô^>X¬¶ÆÞ-YZnÇ(sm§ÿåSËlmée*¦ìr?¿?¨¥?©ÿ-+-SwèþÈ©

------_=_NextPart_001_01C03925.EE001590-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 18 13:20:55 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA03036 for ; Wed, 18 Oct 2000 13:20:51 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4C6B1443A9; Wed, 18 Oct 2000 12:08:15 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from wusr3.mobilerain.com (sdsl-208-185-234-252.dsl.sjc.megapath.net [208.185.234.252]) by lists.bell-labs.com (Postfix) with ESMTP id AFEA544336 for ; Wed, 18 Oct 2000 12:07:03 -0400 (EDT) Received: from mobilerain.com (IDENT:dsardana@localhost [127.0.0.1]) by wusr3.mobilerain.com (8.9.3/8.9.3) with ESMTP id KAA05513; Wed, 18 Oct 2000 10:03:48 -0700 Message-ID: <39EDD7F4.D1273442@mobilerain.com> From: Bobby Sardana Organization: MobileRain Technologies, Inc. X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: discussion@sipforum.org Cc: mranga@nist.gov, sip@lists.bell-labs.com, jainsip@sun.com Subject: Re: [SIPFORUM] Re: [SIP] JAIN SIP Specification References: <39EB464C.44254E5B@dynamicsoft.com> <00101814092004.10136@gethin> <39EDB3C4.282F1EFA@nist.gov> <39EDBC08.A51790EF@dynamicsoft.com> <39EDC2C5.A98A11BF@nist.gov> <39EDCF73.42981937@dynamicsoft.com> <39EDD212.39768977@mobilerain.com> <39EDD4E7.75D09818@dynamicsoft.com> Content-Type: multipart/mixed; boundary="------------26E6AFA32D2879111D105559" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 18 Oct 2000 10:03:48 -0700 This is a multi-part message in MIME format. --------------26E6AFA32D2879111D105559 Content-Type: multipart/alternative; boundary="------------6B9963CFBA548EFC7E04674F" --------------6B9963CFBA548EFC7E04674F Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Chris Harris wrote: > > > Bobby Sardana wrote: > >> Greetings Chris: >> >> Just to add a pointer to this thread: >> >> Maintaining trasaction state is an application level functionality >> and *shouldn't* be implemented in the base stack. For applications >> like state oriented proxy server, the JAIN SIP can provide enough >> hooks for event delivery but the state has to be maintained by the >> proxy server. > > Is simply sending up all received requests without any kind of > transaction id really enough? Yes. In the case of SIP there actually is no such thing as TransactionID, compared to some other protocols like TCAP. The TrasactionID in case of SIP is a composite collection of headers. The headers, once parsed, are available to the application. The application then should track what state it should maintain. It is equivalent to a Call Model vs Encoding/Decoding of protocols like INAP. > What are the hooks you refer to? The hooks I refer to are the delegation event delivery mechanism via JainSipListener. > An application like a stateful proxy server will surely be able to > handle this, but what about simple services? - shouldn't the API > provide a convenient means to send responses, acks, cancel etc? Here you are referring to the Call Model - which manages the protocol/application state. All I am suggesting is that it should be independent of the stack. Regards, Bobby.Sardana@mobilerain.com > > >> >> >> Pleas keep up the good work. It is really appreciated. >> >> Regards, >> >> Bobby.Sardana@mobilerain.com >> >> Chris Harris wrote: >> >> > "M. Ranganathan" wrote: >> > >> >> Hi Chris, >> >> >> >> Thanks for replying so promptly (I am sure you are flooded with >> >> email ). >> > >> > I get one or two :) >> > >> >> >> >> As you pointed out, I suppose we cannot do away with making >> >> Messages >> >> into classes because of the tie-in with java events >> >> (unfortunately) but >> >> I still like the notion of being able to specify interfaces >> >> where ever >> >> possible. >> > >> > I see where you're coming from alright, and I suppose changing >> > header classes into interfaces, could fit in with Gethin's proposal >> > nicely? >> > >> >> >> >> I dont quite follow the motivation behind the following design >> >> decision (excerpted from your reply): >> >> >> >> Maybe I've misunderstood what you're saying - but a JAIN SIP >> >> implementation is only stateless when it comes to call state. The >> >> >> >> JainSipProvider implementation must maintain transaction state - >> >> it >> >> simply exposes a reference to a transaction via the transaction >> >> id for >> >> the convenience of the JainSipListener. The service does not have >> >> total >> >> control over transacton state - the stack implementation does. >> >> >> >> It appears that I have indded mis-understood the architecture. >> >> Why >> >> should the above be so? Can one not rely on the JainSipListener >> >> to keep >> >> transaction state also, thereby making the stack simply a way of >> >> recognising messages and triggering event handlers on the basis >> >> of >> >> message type. This would (IMHO) be a cleaner model yet. That >> >> way, we >> >> can do away with transaction identifiers being passed back and >> >> forth and >> >> keep all of this information in the handler. ( You may have to >> >> extend >> >> the architecture somewhat to deal with timeouts and failures so >> >> that the >> >> handler knows about transaction failure.) In any case, if this is >> >> not a >> >> viable idea, I would be grateful if you can explain why not (or >> >> point me >> >> to the portion of the spec that explains why not) so I can get a >> >> better >> >> understanding. >> > >> > It would be cleaner model, and personally I am in total agreement >> > with you - but it means the application is forced to maintain >> > transaction state, match up headers - which has been said places >> > too much of a burden on applications. How about finding a way to >> > let the application choose whether or not it wants to keep >> > transaction state? >> > >> >> >> >> >> >> Regards, >> >> >> >> Ranga. >> >> >> >> Chris Harris wrote: >> >> >> >> > Hi Ranga, >> >> > >> >> > Response below... >> >> > >> >> > Chris >> >> > >> >> > "M. Ranganathan" wrote: >> >> > >> >> >> JAIN-SIP is a groovy idea. Hats off to the whole concept and >> >> many >> >> >> thanks to Chris and >> >> >> the JAIN-SIP team for putting together a spec and more flower >> >> power >> >> >> to them :-) . In >> >> >> particular I like the notion of treating UAS, Redirect and >> >> Proxy >> >> >> servers as merely >> >> >> special cases of the general notion of Services and the idea >> >> of >> >> >> unifying these >> >> >> notions with an event mechanism and event handlers. Second, >> >> I like >> >> >> the idea of >> >> >> separation between a stateless event -oriented "stack" and a >> >> bunch >> >> >> of event >> >> >> handlers that are triggered by the stack with all state >> >> (including >> >> >> transaction >> >> >> state) being separated from the event stack via the JAIN-SIP >> >> mapping >> >> >> layer if you >> >> >> will. ( Correct me if I wax poetic but have the wrong >> >> >> understanding....) >> >> > >> >> >> >> >> >> >> >> >> I hope I will not be viewed as being too critical, but I >> >> would >> >> >> like to go one step >> >> >> further than what Gethin is suggesting. I am all for using >> >> >> interfaces as much as >> >> >> possible and leaving class hierarchy definitions to >> >> implemeters. >> >> >> Defining class >> >> >> hierarchies almost lays out an implementation and involves >> >> >> considerable rework for >> >> >> those who have a working java-based stack, but have not used >> >> the >> >> >> same classes. OK it >> >> >> is just a matter of labor to map things to the JAIN-SIP class >> >> >> hierarchy but it IS a >> >> >> dis-incentive. >> >> >> >> >> >> 1. Lets use interfaces for all messages rather than actually >> >> define >> >> >> class >> >> >> hierarchies ( yes Chris has pointed out the historical >> >> precedent >> >> >> behind actually >> >> >> defining class hierarchies for messages. IMHO, there has to >> >> be a >> >> >> more compelling >> >> >> reason than that.) >> >> > >> >> > I suppose all classes could be turned into interfaces, except >> >> for the >> >> > Message classes which must extend java.util.EventObject to fit >> >> into >> >> > the JAIN framework. >> >> > >> >> >> >> >> >> >> >> >> 2. The tie-in with the JAVA event mechanism has necessitated >> >> the >> >> >> explicit definition >> >> >> of class hierarchies in certain places. Why not use callbacks >> >> >> >> >> instead and do away >> >> >> with this dependency as well? (Basically the same thing as >> >> events >> >> >> but does not tie >> >> >> into the JAVA event mechanism and its associated limitations.) >> >> >> >> > >> >> > Unfortunately the JAIN framework expilicitly relies on the Java >> >> Event >> >> > model, and I don't think callbacks would be accepted within the >> >> JAIN >> >> > community. >> >> > >> >> >> >> >> >> >> >> >> Nice work and keep it rolling! Thanks. >> >> > >> >> > Couldn't do it without you guys - thank you! >> >> > >> >> >> >> >> >> >> >> >> Ranga. >> >> >> >> >> >> Gethin Liddell wrote: >> >> >> >> >> >> > All, >> >> >> > >> >> >> > This idea of abstraction of the JAIN API is certainly a >> >> valid and >> >> >> > interesting idea. However, i'm a bit concerened that the >> >> proposed >> >> >> >> >> >> > solution of many different packages, will only seek to >> >> complicate >> >> >> and >> >> >> > maybe enlarge the API. >> >> >> > >> >> >> > I too see no reason why there is an EntityHeader etc... and >> >> i also >> >> >> do >> >> >> > not see any requirement for an InviteMessage, AckMessage >> >> etc... >> >> >> > >> >> >> > How about if the format of the API remains as is: >> >> >> > >> >> >> > jain.protocol.ip.sip >> >> >> > jain.protocol.ip.sip.header >> >> >> > jain.protocol.ip.sip.message >> >> >> > >> >> >> > except that the messages available in the message package >> >> >> consisted of >> >> >> > BasicRequest/Response, MinimalRequest/Response etc... where >> >> each >> >> >> > message is extened in turn (e.g. Minimal extends Basic, >> >> Moderate >> >> >> > extends Minimal etc...), of course as Chris points out it is >> >> not >> >> >> hard >> >> >> > to see that a combination would be required that is not >> >> provided. >> >> >> So >> >> >> > in the interest of flexibility, it could be possible for the >> >> user >> >> >> to >> >> >> > plug-in to the message class what extra headers it >> >> requires. The >> >> >> only >> >> >> > issue then is that the user will have to use a "public >> >> Header >> >> >> > getHeader(String headerName)" and then cast the header to >> >> their >> >> >> desired >> >> >> > header type. Either that or create their own Message class >> >> >> > (extending the current ones) that simply does the casting >> >> >> automatically >> >> >> > for them. Then after compiling, run an obfuscator on the >> >> code and >> >> >> it >> >> >> > will automatically extract and only extract the Message, >> >> Headers >> >> >> and >> >> >> > even methods that are used. >> >> >> > >> >> >> > This then will also cut down on the number of methods in the >> >> >> >> >> Provider >> >> >> > as there will be no need for the sendAck(AckMessage), >> >> >> > sendInvite(InviteMessage) etc.. as they would be replaced by >> >> the >> >> >> > single method sendRequest(RequestMessage). >> >> >> > >> >> >> > I personally see three arguments for keeping the JAIN SIP >> >> stack as >> >> >> small >> >> >> > as possible: >> >> >> > >> >> >> > 1) The first is for embedded applications where stack size >> >> has to >> >> >> be >> >> >> > kept to a minimum as memory is at a premium. So if just >> >> using the >> >> >> >> >> >> > Basic message suffices then this will compile and run with a >> >> small >> >> >> >> >> >> > number of classes present from the stack. Don't forget, >> >> >> obfuscation >> >> >> > will help in extracting only the Messages, Headers and even >> >> >> methods >> >> >> > required from a jar file but it won't do everything. >> >> >> > >> >> >> > 2) The second is that users may be put off or confused by >> >> the >> >> >> sheer >> >> >> > size and complexity of the JAIN stack. So if only using the >> >> >> >> >> > BasicMessage gets them on the first rung of the ladder then >> >> it is >> >> >> a >> >> >> > good starting point and allows them to build up to bigger >> >> and >> >> >> better >> >> >> > things. >> >> >> > >> >> >> > 3) We also have to consider who is going to implement the >> >> JAIN SIP >> >> >> >> >> >> > stack. If it is indeed overly complicated then no-one or a >> >> single >> >> >> > vendor may end up implmenting the stack and thus its >> >> definition >> >> >> and >> >> >> > all the hard work that has gone into it is useless. >> >> >> > >> >> >> > On Mon, 16 Oct 2000, Chris Harris wrote: >> >> >> > > Itamar, >> >> >> > > >> >> >> > > The idea of levelling the API based on what messages, >> >> headers >> >> >> and response codes >> >> >> > > are understood is certainly an interesting one - minimal, >> >> basic, >> >> >> redirection, >> >> >> > > firewall-friendly, negotiation, authentication and "full". >> >> >> >> >> > > >> >> >> > > jain.protocol.ip.sip >> >> >> > > jain.protocol.ip.sip.header >> >> >> > > jain.protocol.ip.sip.message >> >> >> > > >> >> >> > > could then become... >> >> >> > > >> >> >> > > jain.protocol.ip.sip - listener, provider, stack, general >> >> >> classes used at all >> >> >> > > levels >> >> >> > > jain.protocol.ip.sip.header - contains base Header class >> >> (and >> >> >> requestHeader, >> >> >> > > ResponseHeader, EntityHeader, GeneralHeader) >> >> >> > > jain.protocol.ip.sip.message - contains base Message class >> >> >> >> >> > > >> >> >> > > jain.protocol.ip.sip.minimal - general classes used only >> >> at this >> >> >> level and above >> >> >> > > >> >> >> > > jain.protocol.ip.sip.minimal.header - headers used only at >> >> this >> >> >> level and above >> >> >> > > jain.protocol.ip.sip.minimal.message - messages only used >> >> at >> >> >> this level and >> >> >> > > above >> >> >> > > >> >> >> > > jain.protocol.ip.sip.basic - general classes used only at >> >> this >> >> >> level and above >> >> >> > > jain.protocol.ip.sip.basic.header - headers used only at >> >> this >> >> >> level and above >> >> >> > > jain.protocol.ip.sip.basic.message - messages used only at >> >> this >> >> >> level and above >> >> >> > > ... >> >> >> > > .... >> >> >> > > jjain.protocol.ip.sip."full" - general classes only used >> >> at this >> >> >> level >> >> >> > > jain.protocol.ip.sip."full".header - headers used only at >> >> this >> >> >> level >> >> >> > > jain.protocol.ip.sip."full".message - messages used only >> >> at this >> >> >> level >> >> >> > > >> >> >> > > The API user could then pick the packages they need - say >> >> they >> >> >> initially only >> >> >> > > want the minimal features, but then realise they need to >> >> use >> >> >> their application >> >> >> > > behind a firewall - then they can simply add the >> >> >> firewall-friendly package. The >> >> >> > > RFC says "In general, each capability listed builds on the >> >> ones >> >> >> above it" but it >> >> >> > > is not hard to see that firewall-friendly and >> >> authentication may >> >> >> be desired >> >> >> > > without redirection for example. >> >> >> > > >> >> >> > > Is this what you hand in mind Itamar? >> >> >> > >> >> >> > -- >> >> >> > Gethin Liddell >> >> >> > Ubiquity Software Corporation >> >> >> > >> >> >> > http://www.ubiquity.net >> >> >> > mailto:gethin@ubiquity.net >> >> >> > >> >> >> > _______________________________________________ >> >> >> > SIP mailing list >> >> >> > SIP@lists.bell-labs.com >> >> >> > http://lists.bell-labs.com/mailman/listinfo/sip >> >> >> >> >> >> -- >> >> >> M.Ranganathan >> >> >> NIST Advanced Networking Technologies Group, >> >> >> 100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899. >> >> >> Tel: 301 975 3664 Fax: 301 590 0932 >> >> >> >> >> >> Hfæj)b? b²Ô^>X¬¶ÆÞ-YZnÇ(sm§ÿåSËlmée*¦ìr?¿?¨¥?©ÿ-+-SwèþÈ© >> >> > >> >> >> >> -- >> >> M.Ranganathan >> >> NIST Advanced Networking Technologies Group, >> >> 100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899. >> >> Tel: 301 975 3664 Fax: 301 590 0932 >> >> >> >> Hfæj)b? b²Ô^>X¬¶ÆÞ-YZnÇ(sm§ÿåSËlmée*¦ìr?¿?¨¥?©ÿ-+-SwèþÈ© >> > --------------6B9963CFBA548EFC7E04674F Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Chris Harris wrote:
 

Bobby Sardana wrote:

Greetings Chris:

Just to add a pointer to this thread:

Maintaining trasaction state is an application level functionality and *shouldn't* be implemented in the base stack. For applications like state oriented proxy server, the JAIN SIP can provide enough hooks for event delivery but the state has to be maintained by the proxy server.

Is simply sending up all received requests without any kind of transaction id really enough?
Yes. In the case of SIP there actually is no such thing as TransactionID, compared to some other protocols like TCAP. The TrasactionID in case of SIP is a composite collection of headers. The headers, once parsed, are available to the application. The application then should track what state it should maintain. It is equivalent to a Call Model vs Encoding/Decoding of protocols like INAP.
What are the hooks you refer to?
The hooks I refer to are the delegation event delivery mechanism via JainSipListener.
An application like a stateful proxy server will surely be able to handle this, but what about simple services? - shouldn't the API provide a convenient means to send responses, acks, cancel etc?
Here you are referring to the Call Model - which manages the protocol/application state. All I am suggesting is that it should be independent of the stack.

Regards,

Bobby.Sardana@mobilerain.com
 

 
 

Pleas keep up the good work. It is really appreciated.

Regards,

Bobby.Sardana@mobilerain.com

Chris Harris wrote:

"M. Ranganathan" wrote:
Hi Chris,

Thanks for replying so promptly (I am sure you are flooded with email ).

I get one or two :)
 
As you pointed out, I suppose we cannot do away with making Messages
into classes because of the tie-in with java events (unfortunately) but
I still like the notion of being able to specify  interfaces where ever
possible.
I see where you're coming from alright, and I suppose changing header classes into interfaces, could fit in with Gethin's proposal nicely?
 
 I dont quite follow  the motivation behind the following design
decision (excerpted from your reply):

Maybe I've misunderstood what you're saying - but a JAIN SIP
implementation is only stateless when it comes to call state. The
JainSipProvider implementation must maintain transaction state - it
simply exposes a reference to a transaction via the transaction id for
the convenience of the JainSipListener. The service does not have total
control over transacton state - the stack implementation does.

It appears that I have indded mis-understood the architecture.  Why
should the above be so? Can one not rely on the JainSipListener to keep
transaction state also, thereby making the stack simply a way of
recognising messages and triggering  event handlers on the basis of
message type. This would (IMHO) be a cleaner model yet.    That way,  we
can do away with transaction identifiers being passed back and forth and
keep all of this information in the handler.  ( You may have to extend
the architecture somewhat to deal with timeouts and failures so that the
handler knows about transaction failure.) In any case, if this is not a
viable idea, I would be grateful if you can explain why not (or point me
to the portion of the spec that explains why not) so I can get a better
understanding.

It would be cleaner model, and personally I am in total agreement with you - but it means the application is forced to maintain transaction state, match up headers - which has been said places too much of a burden on applications. How about finding a way to let the application choose whether or not it wants to keep transaction state?
 

Regards,

Ranga.

Chris Harris wrote:

> Hi Ranga,
>
> Response below...
>
> Chris
>
> "M. Ranganathan" wrote:
>
>> JAIN-SIP is a groovy idea. Hats off to the whole concept and many
>> thanks to Chris and
>> the JAIN-SIP team for putting together a spec and more flower power
>> to them :-) .  In
>> particular I like the notion of treating UAS,  Redirect and Proxy
>> servers as merely
>> special cases of the general notion of Services and  the idea of
>> unifying these
>> notions with an event mechanism and  event handlers.  Second, I like
>> the idea of
>> separation between a  stateless  event -oriented "stack" and a bunch
>> of event
>> handlers that are triggered by the stack with all state (including
>> transaction
>> state) being separated from the event stack via the JAIN-SIP mapping
>> layer if you
>> will.  ( Correct me if I  wax poetic but have the wrong
>> understanding....)
>
>>
>>
>> I hope I  will not be viewed as being too critical,  but I would
>> like to go  one step
>> further than what Gethin is suggesting.   I am all for using
>> interfaces as much as
>> possible and leaving class hierarchy definitions to implemeters.
>> Defining class
>> hierarchies almost lays out an implementation and involves
>> considerable rework for
>> those who have a working java-based stack, but have not used the
>> same classes. OK it
>> is just a matter of labor to map things to the JAIN-SIP class
>> hierarchy but it  IS a
>> dis-incentive.
>>
>> 1. Lets use interfaces for all messages rather than actually define
>> class
>> hierarchies  ( yes Chris has pointed out the historical precedent
>> behind actually
>> defining class hierarchies for messages. IMHO,  there has to be a
>> more compelling
>> reason than that.)
>
> I suppose all classes could be turned into interfaces, except for the
> Message classes which must extend java.util.EventObject to fit into
> the JAIN framework.
>
>>
>>
>> 2. The tie-in with the JAVA event mechanism has necessitated the
>> explicit definition
>> of class hierarchies in certain places.  Why not use callbacks
>> instead and do away
>> with this dependency as well?  (Basically the same thing as events
>> but does not tie
>> into the JAVA event mechanism and its associated limitations.)
>
> Unfortunately the JAIN framework expilicitly relies on the Java Event
> model, and I don't think callbacks would be accepted within the JAIN
> community.
>
>>
>>
>> Nice work and keep it rolling!  Thanks.
>
> Couldn't do it without you guys - thank you!
>
>>
>>
>> Ranga.
>>
>> Gethin Liddell wrote:
>>
>> > All,
>> >
>> > This idea of abstraction of the JAIN API is certainly a valid and
>> > interesting idea.  However, i'm a bit concerened that the proposed
>>
>> > solution of many different packages, will only seek to complicate
>> and
>> > maybe enlarge the API.
>> >
>> > I too see no reason why there is an EntityHeader etc... and i also
>> do
>> > not see any requirement for an InviteMessage, AckMessage etc...
>> >
>> > How about if the format of the API remains as is:
>> >
>> > jain.protocol.ip.sip
>> > jain.protocol.ip.sip.header
>> > jain.protocol.ip.sip.message
>> >
>> > except that the messages available in the message package
>> consisted of
>> > BasicRequest/Response, MinimalRequest/Response etc... where each
>> > message is extened in turn (e.g. Minimal extends Basic, Moderate
>> > extends Minimal etc...), of course as Chris points out it is not
>> hard
>> > to see that a combination would be required that is not provided.
>> So
>> > in the interest of flexibility, it could be possible for the user
>> to
>> > plug-in to the message class what extra headers it requires.  The
>> only
>> > issue then is that the user will have to use a "public Header
>> > getHeader(String headerName)" and then cast the header to their
>> desired
>> > header type. Either that or create their own Message class
>> > (extending the current ones) that simply does the casting
>> automatically
>> > for them.  Then after compiling, run an obfuscator on the code and
>> it
>> > will automatically extract and only extract the Message, Headers
>> and
>> > even methods that are used.
>> >
>> > This then will also cut down on the number of methods in the
>> Provider
>> > as there will be no need for the sendAck(AckMessage),
>> > sendInvite(InviteMessage) etc.. as they would be replaced by the
>> > single method sendRequest(RequestMessage).
>> >
>> > I personally see three arguments for keeping the JAIN SIP stack as
>> small
>> > as possible:
>> >
>> > 1) The first is for embedded applications where stack size has to
>> be
>> > kept to a minimum as memory is at a premium.  So if just using the
>>
>> > Basic message suffices then this will compile and run with a small
>>
>> > number of classes present from the stack.  Don't forget,
>> obfuscation
>> > will help in extracting only the Messages, Headers and even
>> methods
>> > required from a jar file but it won't do everything.
>> >
>> > 2) The second is that users may be put off or confused by the
>> sheer
>> > size and complexity of the JAIN stack.  So if only using the
>> > BasicMessage gets them on the first rung of the ladder then it is
>> a
>> > good starting point and allows them to build up to bigger and
>> better
>> > things.
>> >
>> > 3) We also have to consider who is going to implement the JAIN SIP
>>
>> > stack. If it is indeed overly complicated then no-one or a single
>> > vendor may end up implmenting the stack and thus its definition
>> and
>> > all the hard work that has gone into it is useless.
>> >
>> > On Mon, 16 Oct 2000, Chris Harris wrote:
>> > > Itamar,
>> > >
>> > > The idea of levelling the API based on what messages, headers
>> and response codes
>> > > are understood is certainly an interesting one - minimal, basic,
>> redirection,
>> > > firewall-friendly, negotiation, authentication and "full".
>> > >
>> > > jain.protocol.ip.sip
>> > > jain.protocol.ip.sip.header
>> > > jain.protocol.ip.sip.message
>> > >
>> > > could then become...
>> > >
>> > > jain.protocol.ip.sip - listener, provider, stack, general
>> classes used at all
>> > > levels
>> > > jain.protocol.ip.sip.header - contains base Header class (and
>> requestHeader,
>> > > ResponseHeader, EntityHeader, GeneralHeader)
>> > > jain.protocol.ip.sip.message - contains base Message class
>> > >
>> > > jain.protocol.ip.sip.minimal - general classes used only at this
>> level and above
>> > >
>> > > jain.protocol.ip.sip.minimal.header - headers used only at this
>> level and above
>> > > jain.protocol.ip.sip.minimal.message - messages only used at
>> this level and
>> > > above
>> > >
>> > > jain.protocol.ip.sip.basic - general classes used only at this
>> level and above
>> > > jain.protocol.ip.sip.basic.header - headers used only at this
>> level and above
>> > > jain.protocol.ip.sip.basic.message - messages used only at this
>> level and above
>> > > ...
>> > > ....
>> > > jjain.protocol.ip.sip."full" - general classes only used at this
>> level
>> > > jain.protocol.ip.sip."full".header - headers used only at this
>> level
>> > > jain.protocol.ip.sip."full".message - messages used only at this
>> level
>> > >
>> > > The API user could then pick the packages they need - say they
>> initially only
>> > > want the minimal features, but then realise they need to use
>> their application
>> > > behind a firewall - then they can simply add the
>> firewall-friendly package. The
>> > > RFC says "In general, each capability listed builds on the ones
>> above it" but it
>> > > is not hard to see that firewall-friendly and authentication may
>> be desired
>> > > without redirection for example.
>> > >
>> > > Is this what you hand in mind Itamar?
>> >
>> > --
>> > Gethin Liddell
>> > Ubiquity Software Corporation
>> >
>> > http://www.ubiquity.net
>> > mailto:gethin@ubiquity.net
>> >
>> > _______________________________________________
>> > SIP mailing list
>> > SIP@lists.bell-labs.com
>> > http://lists.bell-labs.com/mailman/listinfo/sip
>>
>> --
>> M.Ranganathan
>> NIST Advanced Networking Technologies Group,
>> 100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899.
>> Tel: 301 975 3664 Fax: 301 590 0932
>>
>> Hfæj)b? b²Ô^>X¬¶ÆÞ-YZnÇ(sm§ÿåSËlmée*¦ìr?¿?¨¥?©ÿ-+-SwèþÈ©
>

--
M.Ranganathan
NIST Advanced Networking Technologies Group,
100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899.
Tel: 301 975 3664 Fax: 301 590 0932

Hfæj)b? b²Ô^>X¬¶ÆÞ-YZnÇ(sm§ÿåSËlmée*¦ìr?¿?¨¥?©ÿ-+-SwèþÈ©

--------------6B9963CFBA548EFC7E04674F-- --------------26E6AFA32D2879111D105559 Content-Type: text/x-vcard; charset=us-ascii; name="bobby.sardana.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Bobby Sardana Content-Disposition: attachment; filename="bobby.sardana.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Sardana;Bobby x-mozilla-html:FALSE org:MobileRain Technologies, Inc.;Telecommunications adr:;;;;;; version:2.1 email;internet:bobby.sardana@mobilerain.com title:Engineer x-mozilla-cpt:;0 fn:Bobby Sardana end:vcard --------------26E6AFA32D2879111D105559-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 18 13:30:52 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA04491 for ; Wed, 18 Oct 2000 13:30:50 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6B89E44338; Wed, 18 Oct 2000 12:29:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from thalia.fm.intel.com (thalia.fm.intel.com [132.233.247.11]) by lists.bell-labs.com (Postfix) with ESMTP id 0D97F44336 for ; Wed, 18 Oct 2000 12:28:17 -0400 (EDT) Received: from SMTP (fmsmsxvs04-1.fm.intel.com [132.233.42.204]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.32 2000/10/12 22:57:04 dmccart Exp $) with SMTP id RAA11691 for ; Wed, 18 Oct 2000 17:29:17 GMT Received: from fmsmsx26.fm.intel.com ([132.233.48.26]) by 132.233.48.204 (Norton AntiVirus for Internet Email Gateways 1.0) ; Wed, 18 Oct 2000 17:28:01 0000 (GMT) Received: by fmsmsx26.fm.intel.com with Internet Mail Service (5.5.2650.21) id ; Wed, 18 Oct 2000 10:27:14 -0700 Message-ID: From: "Schmidlin, David" To: "'sip@lists.bell-labs.com'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] Overviews of How to test SIP. Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 18 Oct 2000 10:27:11 -0700 Does any one know of good doc's that describe methods on how to test SIP? Thanks, Dave _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 18 13:45:39 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA06358 for ; Wed, 18 Oct 2000 13:45:36 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8399D4436B; Wed, 18 Oct 2000 12:45:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id C350044337 for ; Wed, 18 Oct 2000 12:44:12 -0400 (EDT) Received: from dynamicsoft.com ([212.120.151.56]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id NAA28330; Wed, 18 Oct 2000 13:45:59 -0400 (EDT) Message-ID: <39EDE166.57FC2ED5@dynamicsoft.com> From: Chris Harris Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Itamar Gilad Cc: "'Bobby Sardana'" , discussion@sipforum.org, mranga@nist.gov, sip@lists.bell-labs.com, jainsip@Sun.COM Subject: Re: [SIPFORUM] Re: [SIP] JAIN SIP Specification References: Content-Type: multipart/alternative; boundary="------------A2C381E9D2124B1DE8A2CE37" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 18 Oct 2000 18:44:06 +0100 --------------A2C381E9D2124B1DE8A2CE37 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Itamar, It is for the very reason that identifying a transaction from a message is not a trivial matter that I wanted to put the transaction handling inside the JainSipProvider. I don't think the spec should just deal with just the message layer. How many people are going to write JAIN SIP applications if they have to implement their own transaction keys? I'd imagine very few. Regards, Chris Itamar Gilad wrote: > Hi again Chris,I'd like to re-emphasize what Bobby says below. The > JAIN SIP specification presented here seems to deal just with the > "message layer" i.e. parsing, encoding, message and message part > containers. I'd like to join those who commend the fine and > comprehensive work done. However, this layer has nothing to do with > transactions and their state. It would be a mistake to rely on it to > retain 'transaction-ids' and associate messages to them (please > correct me if I'm misinterpreting your meaning). Note that identifying > a transaction from a message is not a trivial matter and continuously > more message fields are added to the "transaction key" in order to > deal with spiraling, merging etc. A more straight-forward approach > would be to put this functionality in the "transaction layer" where > transaction objects live and make a clean separation between the two > layers.Regards Itamar > -----Original Message----- > From: Bobby Sardana [mailto:bobby.sardana@mobilerain.com] > Sent: Wed, October 18, 2000 6:39 PM > To: discussion@sipforum.org > Cc: mranga@nist.gov; sip@lists.bell-labs.com; jainsip@sun.com > Subject: Re: [SIPFORUM] Re: [SIP] JAIN SIP Specification > > > Greetings Chris: > > Just to add a pointer to this thread: > > Maintaining trasaction state is an application level > functionality and *shouldn't* be implemented in the base > stack. For applications like state oriented proxy server, > the JAIN SIP can provide enough hooks for event delivery but > the state has to be maintained by the proxy server. > > Pleas keep up the good work. It is really appreciated. > > Regards, > > Bobby.Sardana@mobilerain.com > > Chris Harris wrote: > > > "M. Ranganathan" wrote: > > > > > Hi Chris, > > > > > > Thanks for replying so promptly (I am sure you are > > > flooded with email ). > > > > I get one or two :) > > > > > > > > As you pointed out, I suppose we cannot do away with > > > making Messages > > > into classes because of the tie-in with java events > > > (unfortunately) but > > > I still like the notion of being able to specify > > > interfaces where ever > > > possible. > > > > I see where you're coming from alright, and I suppose > > changing header classes into interfaces, could fit in with > > Gethin's proposal nicely? > > > > > > > > I dont quite follow the motivation behind the following > > > design > > > decision (excerpted from your reply): > > > > > > Maybe I've misunderstood what you're saying - but a JAIN > > > SIP > > > implementation is only stateless when it comes to call > > > state. The > > > JainSipProvider implementation must maintain transaction > > > state - it > > > simply exposes a reference to a transaction via the > > > transaction id for > > > the convenience of the JainSipListener. The service does > > > not have total > > > control over transacton state - the stack implementation > > > does. > > > > > > It appears that I have indded mis-understood the > > > architecture. Why > > > should the above be so? Can one not rely on the > > > JainSipListener to keep > > > transaction state also, thereby making the stack simply a > > > way of > > > recognising messages and triggering event handlers on > > > the basis of > > > message type. This would (IMHO) be a cleaner model > > > yet. That way, we > > > can do away with transaction identifiers being passed > > > back and forth and > > > keep all of this information in the handler. ( You may > > > have to extend > > > the architecture somewhat to deal with timeouts and > > > failures so that the > > > handler knows about transaction failure.) In any case, if > > > this is not a > > > viable idea, I would be grateful if you can explain why > > > not (or point me > > > to the portion of the spec that explains why not) so I > > > can get a better > > > understanding. > > > > It would be cleaner model, and personally I am in total > > agreement with you - but it means the application is > > forced to maintain transaction state, match up headers - > > which has been said places too much of a burden on > > applications. How about finding a way to let the > > application choose whether or not it wants to keep > > transaction state? > > > > > > > > > > > Regards, > > > > > > Ranga. > > > > > > Chris Harris wrote: > > > > > > > Hi Ranga, > > > > > > > > Response below... > > > > > > > > Chris > > > > > > > > "M. Ranganathan" wrote: > > > > > > > >> JAIN-SIP is a groovy idea. Hats off to the whole > > > concept and many > > > >> thanks to Chris and > > > >> the JAIN-SIP team for putting together a spec and more > > > flower power > > > >> to them :-) . In > > > >> particular I like the notion of treating UAS, > > > Redirect and Proxy > > > >> servers as merely > > > >> special cases of the general notion of Services and > > > the idea of > > > >> unifying these > > > >> notions with an event mechanism and event handlers. > > > Second, I like > > > >> the idea of > > > >> separation between a stateless event -oriented > > > "stack" and a bunch > > > >> of event > > > >> handlers that are triggered by the stack with all > > > state (including > > > >> transaction > > > >> state) being separated from the event stack via the > > > JAIN-SIP mapping > > > >> layer if you > > > >> will. ( Correct me if I wax poetic but have the > > > wrong > > > >> understanding....) > > > > > > > >> > > > >> > > > >> I hope I will not be viewed as being too critical, > > > but I would > > > >> like to go one step > > > >> further than what Gethin is suggesting. I am all for > > > using > > > >> interfaces as much as > > > >> possible and leaving class hierarchy definitions to > > > implemeters. > > > >> Defining class > > > >> hierarchies almost lays out an implementation and > > > involves > > > >> considerable rework for > > > >> those who have a working java-based stack, but have > > > not used the > > > >> same classes. OK it > > > >> is just a matter of labor to map things to the > > > JAIN-SIP class > > > >> hierarchy but it IS a > > > >> dis-incentive. > > > >> > > > >> 1. Lets use interfaces for all messages rather than > > > actually define > > > >> class > > > >> hierarchies ( yes Chris has pointed out the > > > historical precedent > > > >> behind actually > > > >> defining class hierarchies for messages. IMHO, there > > > has to be a > > > >> more compelling > > > >> reason than that.) > > > > > > > > I suppose all classes could be turned into interfaces, > > > except for the > > > > Message classes which must extend java.util.EventObject > > > to fit into > > > > the JAIN framework. > > > > > > > >> > > > >> > > > >> 2. The tie-in with the JAVA event mechanism has > > > necessitated the > > > >> explicit definition > > > >> of class hierarchies in certain places. Why not use > > > callbacks > > > >> instead and do away > > > >> with this dependency as well? (Basically the same > > > thing as events > > > >> but does not tie > > > >> into the JAVA event mechanism and its associated > > > limitations.) > > > > > > > > Unfortunately the JAIN framework expilicitly relies on > > > the Java Event > > > > model, and I don't think callbacks would be accepted > > > within the JAIN > > > > community. > > > > > > > >> > > > >> > > > >> Nice work and keep it rolling! Thanks. > > > > > > > > Couldn't do it without you guys - thank you! > > > > > > > >> > > > >> > > > >> Ranga. > > > >> > > > >> Gethin Liddell wrote: > > > >> > > > >> > All, > > > >> > > > > >> > This idea of abstraction of the JAIN API is > > > certainly a valid and > > > >> > interesting idea. However, i'm a bit concerened > > > that the proposed > > > >> > > > >> > solution of many different packages, will only seek > > > to complicate > > > >> and > > > >> > maybe enlarge the API. > > > >> > > > > >> > I too see no reason why there is an EntityHeader > > > etc... and i also > > > >> do > > > >> > not see any requirement for an InviteMessage, > > > AckMessage etc... > > > >> > > > > >> > How about if the format of the API remains as is: > > > >> > > > > >> > jain.protocol.ip.sip > > > >> > jain.protocol.ip.sip.header > > > >> > jain.protocol.ip.sip.message > > > >> > > > > >> > except that the messages available in the message > > > package > > > >> consisted of > > > >> > BasicRequest/Response, MinimalRequest/Response > > > etc... where each > > > >> > message is extened in turn (e.g. Minimal extends > > > Basic, Moderate > > > >> > extends Minimal etc...), of course as Chris points > > > out it is not > > > >> hard > > > >> > to see that a combination would be required that is > > > not provided. > > > >> So > > > >> > in the interest of flexibility, it could be possible > > > for the user > > > >> to > > > >> > plug-in to the message class what extra headers it > > > requires. The > > > >> only > > > >> > issue then is that the user will have to use a > > > "public Header > > > >> > getHeader(String headerName)" and then cast the > > > header to their > > > >> desired > > > >> > header type. Either that or create their own Message > > > class > > > >> > (extending the current ones) that simply does the > > > casting > > > >> automatically > > > >> > for them. Then after compiling, run an obfuscator > > > on the code and > > > >> it > > > >> > will automatically extract and only extract the > > > Message, Headers > > > >> and > > > >> > even methods that are used. > > > >> > > > > >> > This then will also cut down on the number of > > > methods in the > > > >> Provider > > > >> > as there will be no need for the > > > sendAck(AckMessage), > > > >> > sendInvite(InviteMessage) etc.. as they would be > > > replaced by the > > > >> > single method sendRequest(RequestMessage). > > > >> > > > > >> > I personally see three arguments for keeping the > > > JAIN SIP stack as > > > >> small > > > >> > as possible: > > > >> > > > > >> > 1) The first is for embedded applications where > > > stack size has to > > > >> be > > > >> > kept to a minimum as memory is at a premium. So if > > > just using the > > > >> > > > >> > Basic message suffices then this will compile and > > > run with a small > > > >> > > > >> > number of classes present from the stack. Don't > > > forget, > > > >> obfuscation > > > >> > will help in extracting only the Messages, Headers > > > and even > > > >> methods > > > >> > required from a jar file but it won't do everything. > > > > > > >> > > > > >> > 2) The second is that users may be put off or > > > confused by the > > > >> sheer > > > >> > size and complexity of the JAIN stack. So if only > > > using the > > > >> > BasicMessage gets them on the first rung of the > > > ladder then it is > > > >> a > > > >> > good starting point and allows them to build up to > > > bigger and > > > >> better > > > >> > things. > > > >> > > > > >> > 3) We also have to consider who is going to > > > implement the JAIN SIP > > > >> > > > >> > stack. If it is indeed overly complicated then > > > no-one or a single > > > >> > vendor may end up implmenting the stack and thus its > > > definition > > > >> and > > > >> > all the hard work that has gone into it is useless. > > > >> > > > > >> > On Mon, 16 Oct 2000, Chris Harris wrote: > > > >> > > Itamar, > > > >> > > > > > >> > > The idea of levelling the API based on what > > > messages, headers > > > >> and response codes > > > >> > > are understood is certainly an interesting one - > > > minimal, basic, > > > >> redirection, > > > >> > > firewall-friendly, negotiation, authentication and > > > "full". > > > >> > > > > > >> > > jain.protocol.ip.sip > > > >> > > jain.protocol.ip.sip.header > > > >> > > jain.protocol.ip.sip.message > > > >> > > > > > >> > > could then become... > > > >> > > > > > >> > > jain.protocol.ip.sip - listener, provider, stack, > > > general > > > >> classes used at all > > > >> > > levels > > > >> > > jain.protocol.ip.sip.header - contains base Header > > > class (and > > > >> requestHeader, > > > >> > > ResponseHeader, EntityHeader, GeneralHeader) > > > >> > > jain.protocol.ip.sip.message - contains base > > > Message class > > > >> > > > > > >> > > jain.protocol.ip.sip.minimal - general classes > > > used only at this > > > >> level and above > > > >> > > > > > >> > > jain.protocol.ip.sip.minimal.header - headers used > > > only at this > > > >> level and above > > > >> > > jain.protocol.ip.sip.minimal.message - messages > > > only used at > > > >> this level and > > > >> > > above > > > >> > > > > > >> > > jain.protocol.ip.sip.basic - general classes used > > > only at this > > > >> level and above > > > >> > > jain.protocol.ip.sip.basic.header - headers used > > > only at this > > > >> level and above > > > >> > > jain.protocol.ip.sip.basic.message - messages used > > > only at this > > > >> level and above > > > >> > > ... > > > >> > > .... > > > >> > > jjain.protocol.ip.sip."full" - general classes > > > only used at this > > > >> level > > > >> > > jain.protocol.ip.sip."full".header - headers used > > > only at this > > > >> level > > > >> > > jain.protocol.ip.sip."full".message - messages > > > used only at this > > > >> level > > > >> > > > > > >> > > The API user could then pick the packages they > > > need - say they > > > >> initially only > > > >> > > want the minimal features, but then realise they > > > need to use > > > >> their application > > > >> > > behind a firewall - then they can simply add the > > > >> firewall-friendly package. The > > > >> > > RFC says "In general, each capability listed > > > builds on the ones > > > >> above it" but it > > > >> > > is not hard to see that firewall-friendly and > > > authentication may > > > >> be desired > > > >> > > without redirection for example. > > > >> > > > > > >> > > Is this what you hand in mind Itamar? > > > >> > > > > >> > -- > > > >> > Gethin Liddell > > > >> > Ubiquity Software Corporation > > > >> > > > > >> > http://www.ubiquity.net > > > >> > mailto:gethin@ubiquity.net > > > >> > > > > >> > _______________________________________________ > > > >> > SIP mailing list > > > >> > SIP@lists.bell-labs.com > > > >> > http://lists.bell-labs.com/mailman/listinfo/sip > > > >> > > > >> -- > > > >> M.Ranganathan > > > >> NIST Advanced Networking Technologies Group, > > > >> 100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899. > > > >> Tel: 301 975 3664 Fax: 301 590 0932 > > > >> > > > >> Hfæj)b? > > > b²Ô^>X¬¶ÆÞ-YZnÇ(sm§ÿåSËlmée*¦ìr?¿?¨¥?©ÿ-+-SwèþÈ© > > > > > > > > > > -- > > > M.Ranganathan > > > NIST Advanced Networking Technologies Group, > > > 100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899. > > > Tel: 301 975 3664 Fax: 301 590 0932 > > > > > > Hfæj)b? b²Ô^>X¬¶ÆÞ-YZnÇ(sm§ÿåSËlmée*¦ìr?¿?¨¥?©ÿ-+-SwèþÈ© > > --------------A2C381E9D2124B1DE8A2CE37 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Itamar,

It is for the very reason that identifying a transaction from a message is not a trivial matter that I wanted to put the transaction handling inside the JainSipProvider. I don't think the spec should just deal with just the message layer. How many people are going to write JAIN SIP applications if they have to implement their own transaction keys? I'd imagine very few.

Regards,
Chris

Itamar Gilad wrote:

 Hi again Chris,I'd like to re-emphasize what Bobby says below.  The JAIN SIP specification presented here seems to deal just with the "message layer" i.e. parsing, encoding, message and message part containers.  I'd like to join those who commend the fine and comprehensive work done.  However, this layer has nothing to do with transactions and their state.  It would be a mistake to rely on it to retain 'transaction-ids' and associate messages to them (please correct me if I'm misinterpreting your meaning). Note that identifying a transaction from a message is not a trivial matter and continuously more message fields are added to the "transaction key" in order to deal with spiraling, merging etc. A more straight-forward approach would be to put this functionality in the "transaction layer" where transaction objects live and make a clean separation between the two layers.Regards Itamar
-----Original Message-----
From: Bobby Sardana [mailto:bobby.sardana@mobilerain.com]
Sent: Wed, October 18, 2000 6:39 PM
To: discussion@sipforum.org
Cc: mranga@nist.gov; sip@lists.bell-labs.com; jainsip@sun.com
Subject: Re: [SIPFORUM] Re: [SIP] JAIN SIP Specification
 
Greetings Chris:

Just to add a pointer to this thread:

Maintaining trasaction state is an application level functionality and *shouldn't* be implemented in the base stack. For applications like state oriented proxy server, the JAIN SIP can provide enough hooks for event delivery but the state has to be maintained by the proxy server.

Pleas keep up the good work. It is really appreciated.

Regards,

Bobby.Sardana@mobilerain.com

Chris Harris wrote:

"M. Ranganathan" wrote:
Hi Chris,

Thanks for replying so promptly (I am sure you are flooded with email ).

I get one or two :)
 
As you pointed out, I suppose we cannot do away with making Messages
into classes because of the tie-in with java events (unfortunately) but
I still like the notion of being able to specify  interfaces where ever
possible.
I see where you're coming from alright, and I suppose changing header classes into interfaces, could fit in with Gethin's proposal nicely?
 
 I dont quite follow  the motivation behind the following design
decision (excerpted from your reply):

Maybe I've misunderstood what you're saying - but a JAIN SIP
implementation is only stateless when it comes to call state. The
JainSipProvider implementation must maintain transaction state - it
simply exposes a reference to a transaction via the transaction id for
the convenience of the JainSipListener. The service does not have total
control over transacton state - the stack implementation does.

It appears that I have indded mis-understood the architecture.  Why
should the above be so? Can one not rely on the JainSipListener to keep
transaction state also, thereby making the stack simply a way of
recognising messages and triggering  event handlers on the basis of
message type. This would (IMHO) be a cleaner model yet.    That way,  we
can do away with transaction identifiers being passed back and forth and
keep all of this information in the handler.  ( You may have to extend
the architecture somewhat to deal with timeouts and failures so that the
handler knows about transaction failure.) In any case, if this is not a
viable idea, I would be grateful if you can explain why not (or point me
to the portion of the spec that explains why not) so I can get a better
understanding.

It would be cleaner model, and personally I am in total agreement with you - but it means the application is forced to maintain transaction state, match up headers - which has been said places too much of a burden on applications. How about finding a way to let the application choose whether or not it wants to keep transaction state?
 

Regards,

Ranga.

Chris Harris wrote:

> Hi Ranga,
>
> Response below...
>
> Chris
>
> "M. Ranganathan" wrote:
>
>> JAIN-SIP is a groovy idea. Hats off to the whole concept and many
>> thanks to Chris and
>> the JAIN-SIP team for putting together a spec and more flower power
>> to them :-) .  In
>> particular I like the notion of treating UAS,  Redirect and Proxy
>> servers as merely
>> special cases of the general notion of Services and  the idea of
>> unifying these
>> notions with an event mechanism and  event handlers.  Second, I like
>> the idea of
>> separation between a  stateless  event -oriented "stack" and a bunch
>> of event
>> handlers that are triggered by the stack with all state (including
>> transaction
>> state) being separated from the event stack via the JAIN-SIP mapping
>> layer if you
>> will.  ( Correct me if I  wax poetic but have the wrong
>> understanding....)
>
>>
>>
>> I hope I  will not be viewed as being too critical,  but I would
>> like to go  one step
>> further than what Gethin is suggesting.   I am all for using
>> interfaces as much as
>> possible and leaving class hierarchy definitions to implemeters.
>> Defining class
>> hierarchies almost lays out an implementation and involves
>> considerable rework for
>> those who have a working java-based stack, but have not used the
>> same classes. OK it
>> is just a matter of labor to map things to the JAIN-SIP class
>> hierarchy but it  IS a
>> dis-incentive.
>>
>> 1. Lets use interfaces for all messages rather than actually define
>> class
>> hierarchies  ( yes Chris has pointed out the historical precedent
>> behind actually
>> defining class hierarchies for messages. IMHO,  there has to be a
>> more compelling
>> reason than that.)
>
> I suppose all classes could be turned into interfaces, except for the
> Message classes which must extend java.util.EventObject to fit into
> the JAIN framework.
>
>>
>>
>> 2. The tie-in with the JAVA event mechanism has necessitated the
>> explicit definition
>> of class hierarchies in certain places.  Why not use callbacks
>> instead and do away
>> with this dependency as well?  (Basically the same thing as events
>> but does not tie
>> into the JAVA event mechanism and its associated limitations.)
>
> Unfortunately the JAIN framework expilicitly relies on the Java Event
> model, and I don't think callbacks would be accepted within the JAIN
> community.
>
>>
>>
>> Nice work and keep it rolling!  Thanks.
>
> Couldn't do it without you guys - thank you!
>
>>
>>
>> Ranga.
>>
>> Gethin Liddell wrote:
>>
>> > All,
>> >
>> > This idea of abstraction of the JAIN API is certainly a valid and
>> > interesting idea.  However, i'm a bit concerened that the proposed
>>
>> > solution of many different packages, will only seek to complicate
>> and
>> > maybe enlarge the API.
>> >
>> > I too see no reason why there is an EntityHeader etc... and i also
>> do
>> > not see any requirement for an InviteMessage, AckMessage etc...
>> >
>> > How about if the format of the API remains as is:
>> >
>> > jain.protocol.ip.sip
>> > jain.protocol.ip.sip.header
>> > jain.protocol.ip.sip.message
>> >
>> > except that the messages available in the message package
>> consisted of
>> > BasicRequest/Response, MinimalRequest/Response etc... where each
>> > message is extened in turn (e.g. Minimal extends Basic, Moderate
>> > extends Minimal etc...), of course as Chris points out it is not
>> hard
>> > to see that a combination would be required that is not provided.
>> So
>> > in the interest of flexibility, it could be possible for the user
>> to
>> > plug-in to the message class what extra headers it requires.  The
>> only
>> > issue then is that the user will have to use a "public Header
>> > getHeader(String headerName)" and then cast the header to their
>> desired
>> > header type. Either that or create their own Message class
>> > (extending the current ones) that simply does the casting
>> automatically
>> > for them.  Then after compiling, run an obfuscator on the code and
>> it
>> > will automatically extract and only extract the Message, Headers
>> and
>> > even methods that are used.
>> >
>> > This then will also cut down on the number of methods in the
>> Provider
>> > as there will be no need for the sendAck(AckMessage),
>> > sendInvite(InviteMessage) etc.. as they would be replaced by the
>> > single method sendRequest(RequestMessage).
>> >
>> > I personally see three arguments for keeping the JAIN SIP stack as
>> small
>> > as possible:
>> >
>> > 1) The first is for embedded applications where stack size has to
>> be
>> > kept to a minimum as memory is at a premium.  So if just using the
>>
>> > Basic message suffices then this will compile and run with a small
>>
>> > number of classes present from the stack.  Don't forget,
>> obfuscation
>> > will help in extracting only the Messages, Headers and even
>> methods
>> > required from a jar file but it won't do everything.
>> >
>> > 2) The second is that users may be put off or confused by the
>> sheer
>> > size and complexity of the JAIN stack.  So if only using the
>> > BasicMessage gets them on the first rung of the ladder then it is
>> a
>> > good starting point and allows them to build up to bigger and
>> better
>> > things.
>> >
>> > 3) We also have to consider who is going to implement the JAIN SIP
>>
>> > stack. If it is indeed overly complicated then no-one or a single
>> > vendor may end up implmenting the stack and thus its definition
>> and
>> > all the hard work that has gone into it is useless.
>> >
>> > On Mon, 16 Oct 2000, Chris Harris wrote:
>> > > Itamar,
>> > >
>> > > The idea of levelling the API based on what messages, headers
>> and response codes
>> > > are understood is certainly an interesting one - minimal, basic,
>> redirection,
>> > > firewall-friendly, negotiation, authentication and "full".
>> > >
>> > > jain.protocol.ip.sip
>> > > jain.protocol.ip.sip.header
>> > > jain.protocol.ip.sip.message
>> > >
>> > > could then become...
>> > >
>> > > jain.protocol.ip.sip - listener, provider, stack, general
>> classes used at all
>> > > levels
>> > > jain.protocol.ip.sip.header - contains base Header class (and
>> requestHeader,
>> > > ResponseHeader, EntityHeader, GeneralHeader)
>> > > jain.protocol.ip.sip.message - contains base Message class
>> > >
>> > > jain.protocol.ip.sip.minimal - general classes used only at this
>> level and above
>> > >
>> > > jain.protocol.ip.sip.minimal.header - headers used only at this
>> level and above
>> > > jain.protocol.ip.sip.minimal.message - messages only used at
>> this level and
>> > > above
>> > >
>> > > jain.protocol.ip.sip.basic - general classes used only at this
>> level and above
>> > > jain.protocol.ip.sip.basic.header - headers used only at this
>> level and above
>> > > jain.protocol.ip.sip.basic.message - messages used only at this
>> level and above
>> > > ...
>> > > ....
>> > > jjain.protocol.ip.sip."full" - general classes only used at this
>> level
>> > > jain.protocol.ip.sip."full".header - headers used only at this
>> level
>> > > jain.protocol.ip.sip."full".message - messages used only at this
>> level
>> > >
>> > > The API user could then pick the packages they need - say they
>> initially only
>> > > want the minimal features, but then realise they need to use
>> their application
>> > > behind a firewall - then they can simply add the
>> firewall-friendly package. The
>> > > RFC says "In general, each capability listed builds on the ones
>> above it" but it
>> > > is not hard to see that firewall-friendly and authentication may
>> be desired
>> > > without redirection for example.
>> > >
>> > > Is this what you hand in mind Itamar?
>> >
>> > --
>> > Gethin Liddell
>> > Ubiquity Software Corporation
>> >
>> > http://www.ubiquity.net
>> > mailto:gethin@ubiquity.net
>> >
>> > _______________________________________________
>> > SIP mailing list
>> > SIP@lists.bell-labs.com
>> > http://lists.bell-labs.com/mailman/listinfo/sip
>>
>> --
>> M.Ranganathan
>> NIST Advanced Networking Technologies Group,
>> 100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899.
>> Tel: 301 975 3664 Fax: 301 590 0932
>>
>> Hfæj)b? b²Ô^>X¬¶ÆÞ-YZnÇ(sm§ÿåSËlmée*¦ìr?¿?¨¥?©ÿ-+-SwèþÈ©
>

--
M.Ranganathan
NIST Advanced Networking Technologies Group,
100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899.
Tel: 301 975 3664 Fax: 301 590 0932

Hfæj)b? b²Ô^>X¬¶ÆÞ-YZnÇ(sm§ÿåSËlmée*¦ìr?¿?¨¥?©ÿ-+-SwèþÈ©

--------------A2C381E9D2124B1DE8A2CE37-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 18 13:58:06 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA07866 for ; Wed, 18 Oct 2000 13:58:04 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 63D3E4437C; Wed, 18 Oct 2000 12:58:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ns1.comversens.com (ns1.comversens.com [63.64.185.10]) by lists.bell-labs.com (Postfix) with ESMTP id DF38044373 for ; Wed, 18 Oct 2000 12:57:14 -0400 (EDT) Received: from mail-bridge.btrd.bostontechnology.com (host.comversens.com [63.64.185.2]) by ns1.comversens.com (8.9.1b+Sun/8.9.1) with ESMTP id NAA29124 for ; Wed, 18 Oct 2000 13:57:56 -0400 (EDT) Received: by mail-bridge.btrd.bostontechnology.com with Internet Mail Service (5.5.2652.78) id ; Wed, 18 Oct 2000 13:55:22 -0400 Message-ID: <35A7D40B978CD311AF05002048404D3401F2BA3F@wm2.btrd.bostontechnology.com> From: "Oughton, Andre" To: "'SIP@lists.bell-labs.com'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] un-subscribed Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 18 Oct 2000 13:54:34 -0400 un-subscribed _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 18 14:01:08 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA08175 for ; Wed, 18 Oct 2000 14:00:36 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 29843443A1; Wed, 18 Oct 2000 12:58:13 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from guardian1.tlv.radvision.com (unknown [212.143.185.30]) by lists.bell-labs.com (Postfix) with ESMTP id 66DCC44373 for ; Wed, 18 Oct 2000 12:57:33 -0400 (EDT) Received: from nt-mail.tlv.radvision.com ([172.20.2.100]) by guardian1.tlv.radvision.com (Post.Office MTA v3.5.3 release 223 ID# 0-0U10L2S100V35) with ESMTP id com; Wed, 18 Oct 2000 20:56:20 +0200 Received: by NT-MAIL with Internet Mail Service (5.5.2650.21) id ; Wed, 18 Oct 2000 19:57:41 +0200 Message-ID: From: Itamar Gilad To: "'discussion@sipforum.org'" , Itamar Gilad Cc: "'Bobby Sardana'" , mranga@nist.gov, sip@lists.bell-labs.com, jainsip@Sun.COM Subject: RE: [SIPFORUM] Re: [SIP] JAIN SIP Specification MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0392C.E89A1450" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 18 Oct 2000 19:57:41 +0200 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_01C0392C.E89A1450 Content-Type: text/plain; charset="iso-8859-1" Chris, I agree that few SIP applications would like to bother with transaction mapping. This is clearly the responsibility of the stack as is transaction management in general. However in a previous thread you explained that the issue of managing call and transaction state is outside the scope of this API specification, which led me to believe that the goal is to define message-related functionality. I think that injecting transaction keys into the mix is crossing the lines you defined. Regards, Itamar -----Original Message----- From: Chris Harris [mailto:charris@dynamicsoft.com] Sent: Wed, October 18, 2000 7:44 PM To: Itamar Gilad Cc: 'Bobby Sardana'; discussion@sipforum.org; mranga@nist.gov; sip@lists.bell-labs.com; jainsip@Sun.COM Subject: Re: [SIPFORUM] Re: [SIP] JAIN SIP Specification Itamar, It is for the very reason that identifying a transaction from a message is not a trivial matter that I wanted to put the transaction handling inside the JainSipProvider. I don't think the spec should just deal with just the message layer. How many people are going to write JAIN SIP applications if they have to implement their own transaction keys? I'd imagine very few. Regards, Chris Itamar Gilad wrote: Hi again Chris,I'd like to re-emphasize what Bobby says below. The JAIN SIP specification presented here seems to deal just with the "message layer" i.e. parsing, encoding, message and message part containers. I'd like to join those who commend the fine and comprehensive work done. However, this layer has nothing to do with transactions and their state. It would be a mistake to rely on it to retain 'transaction-ids' and associate messages to them (please correct me if I'm misinterpreting your meaning). Note that identifying a transaction from a message is not a trivial matter and continuously more message fields are added to the "transaction key" in order to deal with spiraling, merging etc. A more straight-forward approach would be to put this functionality in the "transaction layer" where transaction objects live and make a clean separation between the two layers.Regards Itamar -----Original Message----- From: Bobby Sardana [ mailto:bobby.sardana@mobilerain.com ] Sent: Wed, October 18, 2000 6:39 PM To: discussion@sipforum.org Cc: mranga@nist.gov; sip@lists.bell-labs.com; jainsip@sun.com Subject: Re: [SIPFORUM] Re: [SIP] JAIN SIP Specification Greetings Chris: Just to add a pointer to this thread: Maintaining trasaction state is an application level functionality and *shouldn't* be implemented in the base stack. For applications like state oriented proxy server, the JAIN SIP can provide enough hooks for event delivery but the state has to be maintained by the proxy server. Pleas keep up the good work. It is really appreciated. Regards, Bobby.Sardana@mobilerain.com Chris Harris wrote: "M. Ranganathan" wrote: Hi Chris, Thanks for replying so promptly (I am sure you are flooded with email ). I get one or two :) As you pointed out, I suppose we cannot do away with making Messages into classes because of the tie-in with java events (unfortunately) but I still like the notion of being able to specify interfaces where ever possible. I see where you're coming from alright, and I suppose changing header classes into interfaces, could fit in with Gethin's proposal nicely? I dont quite follow the motivation behind the following design decision (excerpted from your reply): Maybe I've misunderstood what you're saying - but a JAIN SIP implementation is only stateless when it comes to call state. The JainSipProvider implementation must maintain transaction state - it simply exposes a reference to a transaction via the transaction id for the convenience of the JainSipListener. The service does not have total control over transacton state - the stack implementation does. It appears that I have indded mis-understood the architecture. Why should the above be so? Can one not rely on the JainSipListener to keep transaction state also, thereby making the stack simply a way of recognising messages and triggering event handlers on the basis of message type. This would (IMHO) be a cleaner model yet. That way, we can do away with transaction identifiers being passed back and forth and keep all of this information in the handler. ( You may have to extend the architecture somewhat to deal with timeouts and failures so that the handler knows about transaction failure.) In any case, if this is not a viable idea, I would be grateful if you can explain why not (or point me to the portion of the spec that explains why not) so I can get a better understanding. It would be cleaner model, and personally I am in total agreement with you - but it means the application is forced to maintain transaction state, match up headers - which has been said places too much of a burden on applications. How about finding a way to let the application choose whether or not it wants to keep transaction state? Regards, Ranga. Chris Harris wrote: > Hi Ranga, > > Response below... > > Chris > > "M. Ranganathan" wrote: > >> JAIN-SIP is a groovy idea. Hats off to the whole concept and many >> thanks to Chris and >> the JAIN-SIP team for putting together a spec and more flower power >> to them :-) . In >> particular I like the notion of treating UAS, Redirect and Proxy >> servers as merely >> special cases of the general notion of Services and the idea of >> unifying these >> notions with an event mechanism and event handlers. Second, I like >> the idea of >> separation between a stateless event -oriented "stack" and a bunch >> of event >> handlers that are triggered by the stack with all state (including >> transaction >> state) being separated from the event stack via the JAIN-SIP mapping >> layer if you >> will. ( Correct me if I wax poetic but have the wrong >> understanding....) > >> >> >> I hope I will not be viewed as being too critical, but I would >> like to go one step >> further than what Gethin is suggesting. I am all for using >> interfaces as much as >> possible and leaving class hierarchy definitions to implemeters. >> Defining class >> hierarchies almost lays out an implementation and involves >> considerable rework for >> those who have a working java-based stack, but have not used the >> same classes. OK it >> is just a matter of labor to map things to the JAIN-SIP class >> hierarchy but it IS a >> dis-incentive. >> >> 1. Lets use interfaces for all messages rather than actually define >> class >> hierarchies ( yes Chris has pointed out the historical precedent >> behind actually >> defining class hierarchies for messages. IMHO, there has to be a >> more compelling >> reason than that.) > > I suppose all classes could be turned into interfaces, except for the > Message classes which must extend java.util.EventObject to fit into > the JAIN framework. > >> >> >> 2. The tie-in with the JAVA event mechanism has necessitated the >> explicit definition >> of class hierarchies in certain places. Why not use callbacks >> instead and do away >> with this dependency as well? (Basically the same thing as events >> but does not tie >> into the JAVA event mechanism and its associated limitations.) > > Unfortunately the JAIN framework expilicitly relies on the Java Event > model, and I don't think callbacks would be accepted within the JAIN > community. > >> >> >> Nice work and keep it rolling! Thanks. > > Couldn't do it without you guys - thank you! > >> >> >> Ranga. >> >> Gethin Liddell wrote: >> >> > All, >> > >> > This idea of abstraction of the JAIN API is certainly a valid and >> > interesting idea. However, i'm a bit concerened that the proposed >> >> > solution of many different packages, will only seek to complicate >> and >> > maybe enlarge the API. >> > >> > I too see no reason why there is an EntityHeader etc... and i also >> do >> > not see any requirement for an InviteMessage, AckMessage etc... >> > >> > How about if the format of the API remains as is: >> > >> > jain.protocol.ip.sip >> > jain.protocol.ip.sip.header >> > jain.protocol.ip.sip.message >> > >> > except that the messages available in the message package >> consisted of >> > BasicRequest/Response, MinimalRequest/Response etc... where each >> > message is extened in turn (e.g. Minimal extends Basic, Moderate >> > extends Minimal etc...), of course as Chris points out it is not >> hard >> > to see that a combination would be required that is not provided. >> So >> > in the interest of flexibility, it could be possible for the user >> to >> > plug-in to the message class what extra headers it requires. The >> only >> > issue then is that the user will have to use a "public Header >> > getHeader(String headerName)" and then cast the header to their >> desired >> > header type. Either that or create their own Message class >> > (extending the current ones) that simply does the casting >> automatically >> > for them. Then after compiling, run an obfuscator on the code and >> it >> > will automatically extract and only extract the Message, Headers >> and >> > even methods that are used. >> > >> > This then will also cut down on the number of methods in the >> Provider >> > as there will be no need for the sendAck(AckMessage), >> > sendInvite(InviteMessage) etc.. as they would be replaced by the >> > single method sendRequest(RequestMessage). >> > >> > I personally see three arguments for keeping the JAIN SIP stack as >> small >> > as possible: >> > >> > 1) The first is for embedded applications where stack size has to >> be >> > kept to a minimum as memory is at a premium. So if just using the >> >> > Basic message suffices then this will compile and run with a small >> >> > number of classes present from the stack. Don't forget, >> obfuscation >> > will help in extracting only the Messages, Headers and even >> methods >> > required from a jar file but it won't do everything. >> > >> > 2) The second is that users may be put off or confused by the >> sheer >> > size and complexity of the JAIN stack. So if only using the >> > BasicMessage gets them on the first rung of the ladder then it is >> a >> > good starting point and allows them to build up to bigger and >> better >> > things. >> > >> > 3) We also have to consider who is going to implement the JAIN SIP >> >> > stack. If it is indeed overly complicated then no-one or a single >> > vendor may end up implmenting the stack and thus its definition >> and >> > all the hard work that has gone into it is useless. >> > >> > On Mon, 16 Oct 2000, Chris Harris wrote: >> > > Itamar, >> > > >> > > The idea of levelling the API based on what messages, headers >> and response codes >> > > are understood is certainly an interesting one - minimal, basic, >> redirection, >> > > firewall-friendly, negotiation, authentication and "full". >> > > >> > > jain.protocol.ip.sip >> > > jain.protocol.ip.sip.header >> > > jain.protocol.ip.sip.message >> > > >> > > could then become... >> > > >> > > jain.protocol.ip.sip - listener, provider, stack, general >> classes used at all >> > > levels >> > > jain.protocol.ip.sip.header - contains base Header class (and >> requestHeader, >> > > ResponseHeader, EntityHeader, GeneralHeader) >> > > jain.protocol.ip.sip.message - contains base Message class >> > > >> > > jain.protocol.ip.sip.minimal - general classes used only at this >> level and above >> > > >> > > jain.protocol.ip.sip.minimal.header - headers used only at this >> level and above >> > > jain.protocol.ip.sip.minimal.message - messages only used at >> this level and >> > > above >> > > >> > > jain.protocol.ip.sip.basic - general classes used only at this >> level and above >> > > jain.protocol.ip.sip.basic.header - headers used only at this >> level and above >> > > jain.protocol.ip.sip.basic.message - messages used only at this >> level and above >> > > ... >> > > .... >> > > jjain.protocol.ip.sip."full" - general classes only used at this >> level >> > > jain.protocol.ip.sip."full".header - headers used only at this >> level >> > > jain.protocol.ip.sip."full".message - messages used only at this >> level >> > > >> > > The API user could then pick the packages they need - say they >> initially only >> > > want the minimal features, but then realise they need to use >> their application >> > > behind a firewall - then they can simply add the >> firewall-friendly package. The >> > > RFC says "In general, each capability listed builds on the ones >> above it" but it >> > > is not hard to see that firewall-friendly and authentication may >> be desired >> > > without redirection for example. >> > > >> > > Is this what you hand in mind Itamar? >> > >> > -- >> > Gethin Liddell >> > Ubiquity Software Corporation >> > >> > http://www.ubiquity.net >> > mailto:gethin@ubiquity.net >> > >> > _______________________________________________ >> > SIP mailing list >> > SIP@lists.bell-labs.com >> > http://lists.bell-labs.com/mailman/listinfo/sip >> >> -- >> M.Ranganathan >> NIST Advanced Networking Technologies Group, >> 100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899. >> Tel: 301 975 3664 Fax: 301 590 0932 >> >> Hfæj)b? b²Ô^>X¬¶ÆÞ-YZnÇ(sm§ÿåSËlmée*¦ìr?¿?¨¥?©ÿ-+-SwèþÈ© > -- M.Ranganathan NIST Advanced Networking Technologies Group, 100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899. Tel: 301 975 3664 Fax: 301 590 0932 Hfæj)b? b²Ô^>X¬¶ÆÞ-YZnÇ(sm§ÿåSËlmée*¦ìr?¿?¨¥?©ÿ-+-SwèþÈ© ------_=_NextPart_001_01C0392C.E89A1450 Content-Type: text/html; charset="iso-8859-1"
Chris, 
 
I agree that few SIP applications would like to bother with transaction mapping.  This is clearly the responsibility of the stack as is transaction management in general.  However in a previous thread you explained that the issue of managing call and transaction state is outside the scope of this API specification, which led me to believe that the goal is to define message-related functionality. I think that injecting transaction keys into the mix is crossing the lines you defined.
 
Regards,
  Itamar
-----Original Message-----
From: Chris Harris [mailto:charris@dynamicsoft.com]
Sent: Wed, October 18, 2000 7:44 PM
To: Itamar Gilad
Cc: 'Bobby Sardana'; discussion@sipforum.org; mranga@nist.gov; sip@lists.bell-labs.com; jainsip@Sun.COM
Subject: Re: [SIPFORUM] Re: [SIP] JAIN SIP Specification

Itamar,

It is for the very reason that identifying a transaction from a message is not a trivial matter that I wanted to put the transaction handling inside the JainSipProvider. I don't think the spec should just deal with just the message layer. How many people are going to write JAIN SIP applications if they have to implement their own transaction keys? I'd imagine very few.

Regards,
Chris

Itamar Gilad wrote:

 Hi again Chris,I'd like to re-emphasize what Bobby says below.  The JAIN SIP specification presented here seems to deal just with the "message layer" i.e. parsing, encoding, message and message part containers.  I'd like to join those who commend the fine and comprehensive work done.  However, this layer has nothing to do with transactions and their state.  It would be a mistake to rely on it to retain 'transaction-ids' and associate messages to them (please correct me if I'm misinterpreting your meaning). Note that identifying a transaction from a message is not a trivial matter and continuously more message fields are added to the "transaction key" in order to deal with spiraling, merging etc. A more straight-forward approach would be to put this functionality in the "transaction layer" where transaction objects live and make a clean separation between the two layers.Regards Itamar
-----Original Message-----
From: Bobby Sardana [mailto:bobby.sardana@mobilerain.com]
Sent: Wed, October 18, 2000 6:39 PM
To: discussion@sipforum.org
Cc: mranga@nist.gov; sip@lists.bell-labs.com; jainsip@sun.com
Subject: Re: [SIPFORUM] Re: [SIP] JAIN SIP Specification
 
Greetings Chris:

Just to add a pointer to this thread:

Maintaining trasaction state is an application level functionality and *shouldn't* be implemented in the base stack. For applications like state oriented proxy server, the JAIN SIP can provide enough hooks for event delivery but the state has to be maintained by the proxy server.

Pleas keep up the good work. It is really appreciated.

Regards,

Bobby.Sardana@mobilerain.com

Chris Harris wrote:

"M. Ranganathan" wrote:
Hi Chris,

Thanks for replying so promptly (I am sure you are flooded with email ).

I get one or two :)

As you pointed out, I suppose we cannot do away with making Messages
into classes because of the tie-in with java events (unfortunately) but
I still like the notion of being able to specify  interfaces where ever
possible.
I see where you're coming from alright, and I suppose changing header classes into interfaces, could fit in with Gethin's proposal nicely?

 I dont quite follow  the motivation behind the following design
decision (excerpted from your reply):

Maybe I've misunderstood what you're saying - but a JAIN SIP
implementation is only stateless when it comes to call state. The
JainSipProvider implementation must maintain transaction state - it
simply exposes a reference to a transaction via the transaction id for
the convenience of the JainSipListener. The service does not have total
control over transacton state - the stack implementation does.

It appears that I have indded mis-understood the architecture.  Why
should the above be so? Can one not rely on the JainSipListener to keep
transaction state also, thereby making the stack simply a way of
recognising messages and triggering  event handlers on the basis of
message type. This would (IMHO) be a cleaner model yet.    That way,  we
can do away with transaction identifiers being passed back and forth and
keep all of this information in the handler.  ( You may have to extend
the architecture somewhat to deal with timeouts and failures so that the
handler knows about transaction failure.) In any case, if this is not a
viable idea, I would be grateful if you can explain why not (or point me
to the portion of the spec that explains why not) so I can get a better
understanding.

It would be cleaner model, and personally I am in total agreement with you - but it means the application is forced to maintain transaction state, match up headers - which has been said places too much of a burden on applications. How about finding a way to let the application choose whether or not it wants to keep transaction state?
 

Regards,

Ranga.

Chris Harris wrote:

> Hi Ranga,
>
> Response below...
>
> Chris
>
> "M. Ranganathan" wrote:
>
>> JAIN-SIP is a groovy idea. Hats off to the whole concept and many
>> thanks to Chris and
>> the JAIN-SIP team for putting together a spec and more flower power
>> to them :-) .  In
>> particular I like the notion of treating UAS,  Redirect and Proxy
>> servers as merely
>> special cases of the general notion of Services and  the idea of
>> unifying these
>> notions with an event mechanism and  event handlers.  Second, I like
>> the idea of
>> separation between a  stateless  event -oriented "stack" and a bunch
>> of event
>> handlers that are triggered by the stack with all state (including
>> transaction
>> state) being separated from the event stack via the JAIN-SIP mapping
>> layer if you
>> will.  ( Correct me if I  wax poetic but have the wrong
>> understanding....)
>
>>
>>
>> I hope I  will not be viewed as being too critical,  but I would
>> like to go  one step
>> further than what Gethin is suggesting.   I am all for using
>> interfaces as much as
>> possible and leaving class hierarchy definitions to implemeters.
>> Defining class
>> hierarchies almost lays out an implementation and involves
>> considerable rework for
>> those who have a working java-based stack, but have not used the
>> same classes. OK it
>> is just a matter of labor to map things to the JAIN-SIP class
>> hierarchy but it  IS a
>> dis-incentive.
>>
>> 1. Lets use interfaces for all messages rather than actually define
>> class
>> hierarchies  ( yes Chris has pointed out the historical precedent
>> behind actually
>> defining class hierarchies for messages. IMHO,  there has to be a
>> more compelling
>> reason than that.)
>
> I suppose all classes could be turned into interfaces, except for the
> Message classes which must extend java.util.EventObject to fit into
> the JAIN framework.
>
>>
>>
>> 2. The tie-in with the JAVA event mechanism has necessitated the
>> explicit definition
>> of class hierarchies in certain places.  Why not use callbacks
>> instead and do away
>> with this dependency as well?  (Basically the same thing as events
>> but does not tie
>> into the JAVA event mechanism and its associated limitations.)
>
> Unfortunately the JAIN framework expilicitly relies on the Java Event
> model, and I don't think callbacks would be accepted within the JAIN
> community.
>
>>
>>
>> Nice work and keep it rolling!  Thanks.
>
> Couldn't do it without you guys - thank you!
>
>>
>>
>> Ranga.
>>
>> Gethin Liddell wrote:
>>
>> > All,
>> >
>> > This idea of abstraction of the JAIN API is certainly a valid and
>> > interesting idea.  However, i'm a bit concerened that the proposed
>>
>> > solution of many different packages, will only seek to complicate
>> and
>> > maybe enlarge the API.
>> >
>> > I too see no reason why there is an EntityHeader etc... and i also
>> do
>> > not see any requirement for an InviteMessage, AckMessage etc...
>> >
>> > How about if the format of the API remains as is:
>> >
>> > jain.protocol.ip.sip
>> > jain.protocol.ip.sip.header
>> > jain.protocol.ip.sip.message
>> >
>> > except that the messages available in the message package
>> consisted of
>> > BasicRequest/Response, MinimalRequest/Response etc... where each
>> > message is extened in turn (e.g. Minimal extends Basic, Moderate
>> > extends Minimal etc...), of course as Chris points out it is not
>> hard
>> > to see that a combination would be required that is not provided.
>> So
>> > in the interest of flexibility, it could be possible for the user
>> to
>> > plug-in to the message class what extra headers it requires.  The
>> only
>> > issue then is that the user will have to use a "public Header
>> > getHeader(String headerName)" and then cast the header to their
>> desired
>> > header type. Either that or create their own Message class
>> > (extending the current ones) that simply does the casting
>> automatically
>> > for them.  Then after compiling, run an obfuscator on the code and
>> it
>> > will automatically extract and only extract the Message, Headers
>> and
>> > even methods that are used.
>> >
>> > This then will also cut down on the number of methods in the
>> Provider
>> > as there will be no need for the sendAck(AckMessage),
>> > sendInvite(InviteMessage) etc.. as they would be replaced by the
>> > single method sendRequest(RequestMessage).
>> >
>> > I personally see three arguments for keeping the JAIN SIP stack as
>> small
>> > as possible:
>> >
>> > 1) The first is for embedded applications where stack size has to
>> be
>> > kept to a minimum as memory is at a premium.  So if just using the
>>
>> > Basic message suffices then this will compile and run with a small
>>
>> > number of classes present from the stack.  Don't forget,
>> obfuscation
>> > will help in extracting only the Messages, Headers and even
>> methods
>> > required from a jar file but it won't do everything.
>> >
>> > 2) The second is that users may be put off or confused by the
>> sheer
>> > size and complexity of the JAIN stack.  So if only using the
>> > BasicMessage gets them on the first rung of the ladder then it is
>> a
>> > good starting point and allows them to build up to bigger and
>> better
>> > things.
>> >
>> > 3) We also have to consider who is going to implement the JAIN SIP
>>
>> > stack. If it is indeed overly complicated then no-one or a single
>> > vendor may end up implmenting the stack and thus its definition
>> and
>> > all the hard work that has gone into it is useless.
>> >
>> > On Mon, 16 Oct 2000, Chris Harris wrote:
>> > > Itamar,
>> > >
>> > > The idea of levelling the API based on what messages, headers
>> and response codes
>> > > are understood is certainly an interesting one - minimal, basic,
>> redirection,
>> > > firewall-friendly, negotiation, authentication and "full".
>> > >
>> > > jain.protocol.ip.sip
>> > > jain.protocol.ip.sip.header
>> > > jain.protocol.ip.sip.message
>> > >
>> > > could then become...
>> > >
>> > > jain.protocol.ip.sip - listener, provider, stack, general
>> classes used at all
>> > > levels
>> > > jain.protocol.ip.sip.header - contains base Header class (and
>> requestHeader,
>> > > ResponseHeader, EntityHeader, GeneralHeader)
>> > > jain.protocol.ip.sip.message - contains base Message class
>> > >
>> > > jain.protocol.ip.sip.minimal - general classes used only at this
>> level and above
>> > >
>> > > jain.protocol.ip.sip.minimal.header - headers used only at this
>> level and above
>> > > jain.protocol.ip.sip.minimal.message - messages only used at
>> this level and
>> > > above
>> > >
>> > > jain.protocol.ip.sip.basic - general classes used only at this
>> level and above
>> > > jain.protocol.ip.sip.basic.header - headers used only at this
>> level and above
>> > > jain.protocol.ip.sip.basic.message - messages used only at this
>> level and above
>> > > ...
>> > > ....
>> > > jjain.protocol.ip.sip."full" - general classes only used at this
>> level
>> > > jain.protocol.ip.sip."full".header - headers used only at this
>> level
>> > > jain.protocol.ip.sip."full".message - messages used only at this
>> level
>> > >
>> > > The API user could then pick the packages they need - say they
>> initially only
>> > > want the minimal features, but then realise they need to use
>> their application
>> > > behind a firewall - then they can simply add the
>> firewall-friendly package. The
>> > > RFC says "In general, each capability listed builds on the ones
>> above it" but it
>> > > is not hard to see that firewall-friendly and authentication may
>> be desired
>> > > without redirection for example.
>> > >
>> > > Is this what you hand in mind Itamar?
>> >
>> > --
>> > Gethin Liddell
>> > Ubiquity Software Corporation
>> >
>> > http://www.ubiquity.net
>> > mailto:gethin@ubiquity.net
>> >
>> > _______________________________________________
>> > SIP mailing list
>> > SIP@lists.bell-labs.com
>> > http://lists.bell-labs.com/mailman/listinfo/sip
>>
>> --
>> M.Ranganathan
>> NIST Advanced Networking Technologies Group,
>> 100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899.
>> Tel: 301 975 3664 Fax: 301 590 0932
>>
>> Hfæj)b? b²Ô^>X¬¶ÆÞ-YZnÇ(sm§ÿåSËlmée*¦ìr?¿?¨¥?©ÿ-+-SwèþÈ©
>

--
M.Ranganathan
NIST Advanced Networking Technologies Group,
100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899.
Tel: 301 975 3664 Fax: 301 590 0932

Hfæj)b? b²Ô^>X¬¶ÆÞ-YZnÇ(sm§ÿåSËlmée*¦ìr?¿?¨¥?©ÿ-+-SwèþÈ©

------_=_NextPart_001_01C0392C.E89A1450-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 18 14:06:26 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA08880 for ; Wed, 18 Oct 2000 14:06:23 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 178A7443B2; Wed, 18 Oct 2000 12:58:22 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ns1.comversens.com (ns1.comversens.com [63.64.185.10]) by lists.bell-labs.com (Postfix) with ESMTP id 3BAAB44373 for ; Wed, 18 Oct 2000 12:57:41 -0400 (EDT) Received: from mail-bridge.btrd.bostontechnology.com (host.comversens.com [63.64.185.2]) by ns1.comversens.com (8.9.1b+Sun/8.9.1) with ESMTP id NAA29167 for ; Wed, 18 Oct 2000 13:58:23 -0400 (EDT) Received: by mail-bridge.btrd.bostontechnology.com with Internet Mail Service (5.5.2652.78) id ; Wed, 18 Oct 2000 13:55:49 -0400 Message-ID: <35A7D40B978CD311AF05002048404D3401F2BA40@wm2.btrd.bostontechnology.com> From: "Oughton, Andre" To: "'SIP@lists.bell-labs.com'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] un-subscribe Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 18 Oct 2000 13:55:04 -0400 un-subscribe _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 18 14:13:48 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA09789 for ; Wed, 18 Oct 2000 14:13:42 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9EB6A443BD; Wed, 18 Oct 2000 13:11:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from is1-55.antd.nist.gov (is1-60.antd.nist.gov [129.6.60.251]) by lists.bell-labs.com (Postfix) with ESMTP id 5A563443B2 for ; Wed, 18 Oct 2000 13:10:33 -0400 (EDT) Received: from nist.gov (IDENT:mranga@stinkbug.antd.nist.gov [129.6.55.9]) by is1-55.antd.nist.gov (8.9.3/8.9.3) with ESMTP id OAA27361; Wed, 18 Oct 2000 14:05:56 -0400 (EDT) Message-ID: <39EDE794.83D92EE5@nist.gov> From: "M. Ranganathan" Reply-To: mranga@nist.gov Organization: NIST advanced networking technologies group X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Cc: "'discussion@sipforum.org'" , jainsip@Sun.COM Subject: Re: [SIPFORUM] Re: [SIP] JAIN SIP Specification References: Content-Type: multipart/alternative; boundary="------------7EF56907BE4D8015F3F5B793" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 18 Oct 2000 14:10:28 -0400 --------------7EF56907BE4D8015F3F5B793 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: base64 Chris Itamar and others, Here's a suggestion (shoot down if it makes no sense): Would a "reasonable middle ground" be to provide a set of "util api" that manages transaction state mapping. It could be an optional part of the core API spec or just a suggested addendum (if people think this is the right way to go....). I think it does not need to be part of the "stack". I guess what I am pushing for keeping the stack stateless, minimal in implementation complexity and minimal in definition with everything else being moved into the service layer and/or helper classes for common things services may want to do (like mapping transaction state etc.) A minimal implementation does not have to include the helper classes.... Regards, Ranga. Itamar Gilad wrote: > Chris, I agree that few SIP applications would like to bother with > transaction mapping. This is clearly the responsibility of the stack > as is transaction management in general. However in a previous thread > you explained that the issue of managing call and transaction state is > outside the scope of this API specification, which led me to believe > that the goal is to define message-related functionality. I think that > injecting transaction keys into the mix is crossing the lines you > defined.Regards, Itamar > > -----Original Message----- > From: Chris Harris [mailto:charris@dynamicsoft.com] > Sent: Wed, October 18, 2000 7:44 PM > To: Itamar Gilad > Cc: 'Bobby Sardana'; discussion@sipforum.org; > mranga@nist.gov; sip@lists.bell-labs.com; jainsip@Sun.COM > Subject: Re: [SIPFORUM] Re: [SIP] JAIN SIP Specification > Itamar, > > It is for the very reason that identifying a transaction > from a message is not a trivial matter that I wanted to put > the transaction handling inside the JainSipProvider. I don't > think the spec should just deal with just the message layer. > How many people are going to write JAIN SIP applications if > they have to implement their own transaction keys? I'd > imagine very few. > > Regards, > Chris > > Itamar Gilad wrote: > > > Hi again Chris,I'd like to re-emphasize what Bobby says > > below. The JAIN SIP specification presented here seems to > > deal just with the "message layer" i.e. parsing, encoding, > > message and message part containers. I'd like to join > > those who commend the fine and comprehensive work done. > > However, this layer has nothing to do with transactions > > and their state. It would be a mistake to rely on it to > > retain 'transaction-ids' and associate messages to them > > (please correct me if I'm misinterpreting your meaning). > > Note that identifying a transaction from a message is not > > a trivial matter and continuously more message fields are > > added to the "transaction key" in order to deal with > > spiraling, merging etc. A more straight-forward approach > > would be to put this functionality in the "transaction > > layer" where transaction objects live and make a clean > > separation between the two layers.Regards Itamar > > -----Original Message----- > > From: Bobby Sardana [mailto:bobby.sardana@mobilerain.com] > > Sent: Wed, October 18, 2000 6:39 PM > > To: discussion@sipforum.org > > Cc: mranga@nist.gov; sip@lists.bell-labs.com; > > jainsip@sun.com > > Subject: Re: [SIPFORUM] Re: [SIP] JAIN SIP Specification > > > > > > Greetings Chris: > > > > Just to add a pointer to this thread: > > > > Maintaining trasaction state is an application > > level functionality and *shouldn't* be > > implemented in the base stack. For applications > > like state oriented proxy server, the JAIN SIP > > can provide enough hooks for event delivery but > > the state has to be maintained by the proxy > > server. > > > > Pleas keep up the good work. It is really > > appreciated. > > > > Regards, > > > > Bobby.Sardana@mobilerain.com > > > > Chris Harris wrote: > > > > > "M. Ranganathan" wrote: > > > > > >> Hi Chris, > > >> > > >> Thanks for replying so promptly (I am sure > > >> you are flooded with email ). > > > > > > I get one or two :) > > > > > >> > > >> As you pointed out, I suppose we cannot do > > >> away with making Messages > > >> into classes because of the tie-in with java > > >> events (unfortunately) but > > >> I still like the notion of being able to > > >> specify interfaces where ever > > >> possible. > > > > > > I see where you're coming from alright, and I > > > suppose changing header classes into > > > interfaces, could fit in with Gethin's proposal > > > nicely? > > > > > >> > > >> I dont quite follow the motivation behind > > >> the following design > > >> decision (excerpted from your reply): > > >> > > >> Maybe I've misunderstood what you're saying - > > >> but a JAIN SIP > > >> implementation is only stateless when it > > >> comes to call state. The > > >> JainSipProvider implementation must maintain > > >> transaction state - it > > >> simply exposes a reference to a transaction > > >> via the transaction id for > > >> the convenience of the JainSipListener. The > > >> service does not have total > > >> control over transacton state - the stack > > >> implementation does. > > >> > > >> It appears that I have indded mis-understood > > >> the architecture. Why > > >> should the above be so? Can one not rely on > > >> the JainSipListener to keep > > >> transaction state also, thereby making the > > >> stack simply a way of > > >> recognising messages and triggering event > > >> handlers on the basis of > > >> message type. This would (IMHO) be a cleaner > > >> model yet. That way, we > > >> can do away with transaction identifiers > > >> being passed back and forth and > > >> keep all of this information in the handler. > > >> ( You may have to extend > > >> the architecture somewhat to deal with > > >> timeouts and failures so that the > > >> handler knows about transaction failure.) In > > >> any case, if this is not a > > >> viable idea, I would be grateful if you can > > >> explain why not (or point me > > >> to the portion of the spec that explains why > > >> not) so I can get a better > > >> understanding. > > > > > > It would be cleaner model, and personally I am > > > in total agreement with you - but it means the > > > application is forced to maintain transaction > > > state, match up headers - which has been said > > > places too much of a burden on applications. > > > How about finding a way to let the application > > > choose whether or not it wants to keep > > > transaction state? > > > > > >> > > >> > > >> Regards, > > >> > > >> Ranga. > > >> > > >> Chris Harris wrote: > > >> > > >> > Hi Ranga, > > >> > > > >> > Response below... > > >> > > > >> > Chris > > >> > > > >> > "M. Ranganathan" wrote: > > >> > > > >> >> JAIN-SIP is a groovy idea. Hats off to the > > >> whole concept and many > > >> >> thanks to Chris and > > >> >> the JAIN-SIP team for putting together a > > >> spec and more flower power > > >> >> to them :-) . In > > >> >> particular I like the notion of treating > > >> UAS, Redirect and Proxy > > >> >> servers as merely > > >> >> special cases of the general notion of > > >> Services and the idea of > > >> >> unifying these > > >> >> notions with an event mechanism and event > > >> handlers. Second, I like > > >> >> the idea of > > >> >> separation between a stateless event > > >> -oriented "stack" and a bunch > > >> >> of event > > >> >> handlers that are triggered by the stack > > >> with all state (including > > >> >> transaction > > >> >> state) being separated from the event > > >> stack via the JAIN-SIP mapping > > >> >> layer if you > > >> >> will. ( Correct me if I wax poetic but > > >> have the wrong > > >> >> understanding....) > > >> > > > >> >> > > >> >> > > >> >> I hope I will not be viewed as being too > > >> critical, but I would > > >> >> like to go one step > > >> >> further than what Gethin is suggesting. > > >> I am all for using > > >> >> interfaces as much as > > >> >> possible and leaving class hierarchy > > >> definitions to implemeters. > > >> >> Defining class > > >> >> hierarchies almost lays out an > > >> implementation and involves > > >> >> considerable rework for > > >> >> those who have a working java-based stack, > > >> but have not used the > > >> >> same classes. OK it > > >> >> is just a matter of labor to map things to > > >> the JAIN-SIP class > > >> >> hierarchy but it IS a > > >> >> dis-incentive. > > >> >> > > >> >> 1. Lets use interfaces for all messages > > >> rather than actually define > > >> >> class > > >> >> hierarchies ( yes Chris has pointed out > > >> the historical precedent > > >> >> behind actually > > >> >> defining class hierarchies for messages. > > >> IMHO, there has to be a > > >> >> more compelling > > >> >> reason than that.) > > >> > > > >> > I suppose all classes could be turned into > > >> interfaces, except for the > > >> > Message classes which must extend > > >> java.util.EventObject to fit into > > >> > the JAIN framework. > > >> > > > >> >> > > >> >> > > >> >> 2. The tie-in with the JAVA event > > >> mechanism has necessitated the > > >> >> explicit definition > > >> >> of class hierarchies in certain places. > > >> Why not use callbacks > > >> >> instead and do away > > >> >> with this dependency as well? (Basically > > >> the same thing as events > > >> >> but does not tie > > >> >> into the JAVA event mechanism and its > > >> associated limitations.) > > >> > > > >> > Unfortunately the JAIN framework > > >> expilicitly relies on the Java Event > > >> > model, and I don't think callbacks would be > > >> accepted within the JAIN > > >> > community. > > >> > > > >> >> > > >> >> > > >> >> Nice work and keep it rolling! Thanks. > > >> > > > >> > Couldn't do it without you guys - thank > > >> you! > > >> > > > >> >> > > >> >> > > >> >> Ranga. > > >> >> > > >> >> Gethin Liddell wrote: > > >> >> > > >> >> > All, > > >> >> > > > >> >> > This idea of abstraction of the JAIN API > > >> is certainly a valid and > > >> >> > interesting idea. However, i'm a bit > > >> concerened that the proposed > > >> >> > > >> >> > solution of many different packages, > > >> will only seek to complicate > > >> >> and > > >> >> > maybe enlarge the API. > > >> >> > > > >> >> > I too see no reason why there is an > > >> EntityHeader etc... and i also > > >> >> do > > >> >> > not see any requirement for an > > >> InviteMessage, AckMessage etc... > > >> >> > > > >> >> > How about if the format of the API > > >> remains as is: > > >> >> > > > >> >> > jain.protocol.ip.sip > > >> >> > jain.protocol.ip.sip.header > > >> >> > jain.protocol.ip.sip.message > > >> >> > > > >> >> > except that the messages available in > > >> the message package > > >> >> consisted of > > >> >> > BasicRequest/Response, > > >> MinimalRequest/Response etc... where each > > >> >> > message is extened in turn (e.g. Minimal > > >> extends Basic, Moderate > > >> >> > extends Minimal etc...), of course as > > >> Chris points out it is not > > >> >> hard > > >> >> > to see that a combination would be > > >> required that is not provided. > > >> >> So > > >> >> > in the interest of flexibility, it could > > >> be possible for the user > > >> >> to > > >> >> > plug-in to the message class what extra > > >> headers it requires. The > > >> >> only > > >> >> > issue then is that the user will have to > > >> use a "public Header > > >> >> > getHeader(String headerName)" and then > > >> cast the header to their > > >> >> desired > > >> >> > header type. Either that or create their > > >> own Message class > > >> >> > (extending the current ones) that simply > > >> does the casting > > >> >> automatically > > >> >> > for them. Then after compiling, run an > > >> obfuscator on the code and > > >> >> it > > >> >> > will automatically extract and only > > >> extract the Message, Headers > > >> >> and > > >> >> > even methods that are used. > > >> >> > > > >> >> > This then will also cut down on the > > >> number of methods in the > > >> >> Provider > > >> >> > as there will be no need for the > > >> sendAck(AckMessage), > > >> >> > sendInvite(InviteMessage) etc.. as they > > >> would be replaced by the > > >> >> > single method > > >> sendRequest(RequestMessage). > > >> >> > > > >> >> > I personally see three arguments for > > >> keeping the JAIN SIP stack as > > >> >> small > > >> >> > as possible: > > >> >> > > > >> >> > 1) The first is for embedded > > >> applications where stack size has to > > >> >> be > > >> >> > kept to a minimum as memory is at a > > >> premium. So if just using the > > >> >> > > >> >> > Basic message suffices then this will > > >> compile and run with a small > > >> >> > > >> >> > number of classes present from the > > >> stack. Don't forget, > > >> >> obfuscation > > >> >> > will help in extracting only the > > >> Messages, Headers and even > > >> >> methods > > >> >> > required from a jar file but it won't do > > >> everything. > > >> >> > > > >> >> > 2) The second is that users may be put > > >> off or confused by the > > >> >> sheer > > >> >> > size and complexity of the JAIN stack. > > >> So if only using the > > >> >> > BasicMessage gets them on the first rung > > >> of the ladder then it is > > >> >> a > > >> >> > good starting point and allows them to > > >> build up to bigger and > > >> >> better > > >> >> > things. > > >> >> > > > >> >> > 3) We also have to consider who is going > > >> to implement the JAIN SIP > > >> >> > > >> >> > stack. If it is indeed overly > > >> complicated then no-one or a single > > >> >> > vendor may end up implmenting the stack > > >> and thus its definition > > >> >> and > > >> >> > all the hard work that has gone into it > > >> is useless. > > >> >> > > > >> >> > On Mon, 16 Oct 2000, Chris Harris wrote: > > >> > > >> >> > > Itamar, > > >> >> > > > > >> >> > > The idea of levelling the API based on > > >> what messages, headers > > >> >> and response codes > > >> >> > > are understood is certainly an > > >> interesting one - minimal, basic, > > >> >> redirection, > > >> >> > > firewall-friendly, negotiation, > > >> authentication and "full". > > >> >> > > > > >> >> > > jain.protocol.ip.sip > > >> >> > > jain.protocol.ip.sip.header > > >> >> > > jain.protocol.ip.sip.message > > >> >> > > > > >> >> > > could then become... > > >> >> > > > > >> >> > > jain.protocol.ip.sip - listener, > > >> provider, stack, general > > >> >> classes used at all > > >> >> > > levels > > >> >> > > jain.protocol.ip.sip.header - contains > > >> base Header class (and > > >> >> requestHeader, > > >> >> > > ResponseHeader, EntityHeader, > > >> GeneralHeader) > > >> >> > > jain.protocol.ip.sip.message - > > >> contains base Message class > > >> >> > > > > >> >> > > jain.protocol.ip.sip.minimal - general > > >> classes used only at this > > >> >> level and above > > >> >> > > > > >> >> > > jain.protocol.ip.sip.minimal.header - > > >> headers used only at this > > >> >> level and above > > >> >> > > jain.protocol.ip.sip.minimal.message - > > >> messages only used at > > >> >> this level and > > >> >> > > above > > >> >> > > > > >> >> > > jain.protocol.ip.sip.basic - general > > >> classes used only at this > > >> >> level and above > > >> >> > > jain.protocol.ip.sip.basic.header - > > >> headers used only at this > > >> >> level and above > > >> >> > > jain.protocol.ip.sip.basic.message - > > >> messages used only at this > > >> >> level and above > > >> >> > > ... > > >> >> > > .... > > >> >> > > jjain.protocol.ip.sip."full" - general > > >> classes only used at this > > >> >> level > > >> >> > > jain.protocol.ip.sip."full".header - > > >> headers used only at this > > >> >> level > > >> >> > > jain.protocol.ip.sip."full".message - > > >> messages used only at this > > >> >> level > > >> >> > > > > >> >> > > The API user could then pick the > > >> packages they need - say they > > >> >> initially only > > >> >> > > want the minimal features, but then > > >> realise they need to use > > >> >> their application > > >> >> > > behind a firewall - then they can > > >> simply add the > > >> >> firewall-friendly package. The > > >> >> > > RFC says "In general, each capability > > >> listed builds on the ones > > >> >> above it" but it > > >> >> > > is not hard to see that > > >> firewall-friendly and authentication may > > >> >> be desired > > >> >> > > without redirection for example. > > >> >> > > > > >> >> > > Is this what you hand in mind Itamar? > > >> >> > > > >> >> > -- > > >> >> > Gethin Liddell > > >> >> > Ubiquity Software Corporation > > >> >> > > > >> >> > http://www.ubiquity.net > > >> >> > mailto:gethin@ubiquity.net > > >> >> > > > >> >> > > > >> _______________________________________________ > > >> > > >> >> > SIP mailing list > > >> >> > SIP@lists.bell-labs.com > > >> >> > > > >> http://lists.bell-labs.com/mailman/listinfo/sip > > >> > > >> >> > > >> >> -- > > >> >> M.Ranganathan > > >> >> NIST Advanced Networking Technologies > > >> Group, > > >> >> 100 Bureau Drive, Stop 8920, Gaithersburg, > > >> MD 20899. > > >> >> Tel: 301 975 3664 Fax: 301 590 0932 > > >> >> > > >> >> Hfæj)b? > > >> b²Ô^>X¬¶ÆÞ-YZnÇ(sm§ÿåSËlmée*¦ìr?¿?¨¥?©ÿ-+-SwèþÈ© > > >> > > >> > > > >> > > >> -- > > >> M.Ranganathan > > >> NIST Advanced Networking Technologies Group, > > >> 100 Bureau Drive, Stop 8920, Gaithersburg, MD > > >> 20899. > > >> Tel: 301 975 3664 Fax: 301 590 0932 > > >> > > >> Hfæj)b? > > >> b²Ô^>X¬¶ÆÞ-YZnÇ(sm§ÿåSËlmée*¦ìr?¿?¨¥?©ÿ-+-SwèþÈ© > > > -- M.Ranganathan NIST Advanced Networking Technologies Group, 100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899. Tel: 301 975 3664 Fax: 301 590 0932 --------------7EF56907BE4D8015F3F5B793 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Chris  Itamar and others,

Here's a suggestion (shoot down if it makes no sense):

Would a  "reasonable middle ground" be to provide a set of  "util api" that manages transaction state mapping.  It could be an optional  part of the  core API spec or just a suggested addendum (if  people think this is the right way to go....).  I think it does not need to be part of the "stack". I  guess what I am  pushing for keeping the stack stateless, minimal  in implementation complexity and minimal in definition with everything else being moved into the service layer and/or helper  classes for common things services may want to do (like mapping transaction state etc.) A minimal implementation does not have to include the helper classes....

Regards,

Ranga.
 

Itamar Gilad wrote:

Chris, I agree that few SIP applications would like to bother with transaction mapping.  This is clearly the responsibility of the stack as is transaction management in general.  However in a previous thread you explained that the issue of managing call and transaction state is outside the scope of this API specification, which led me to believe that the goal is to define message-related functionality. I think that injecting transaction keys into the mix is crossing the lines you defined.Regards,  Itamar
-----Original Message-----
From: Chris Harris [mailto:charris@dynamicsoft.com]
Sent: Wed, October 18, 2000 7:44 PM
To: Itamar Gilad
Cc: 'Bobby Sardana'; discussion@sipforum.org; mranga@nist.gov; sip@lists.bell-labs.com; jainsip@Sun.COM
Subject: Re: [SIPFORUM] Re: [SIP] JAIN SIP Specification
Itamar,

It is for the very reason that identifying a transaction from a message is not a trivial matter that I wanted to put the transaction handling inside the JainSipProvider. I don't think the spec should just deal with just the message layer. How many people are going to write JAIN SIP applications if they have to implement their own transaction keys? I'd imagine very few.

Regards,
Chris

Itamar Gilad wrote:

Hi again Chris,I'd like to re-emphasize what Bobby says below.  The JAIN SIP specification presented here seems to deal just with the "message layer" i.e. parsing, encoding, message and message part containers.  I'd like to join those who commend the fine and comprehensive work done.  However, this layer has nothing to do with transactions and their state.  It would be a mistake to rely on it to retain 'transaction-ids' and associate messages to them (please correct me if I'm misinterpreting your meaning). Note that identifying a transaction from a message is not a trivial matter and continuously more message fields are added to the "transaction key" in order to deal with spiraling, merging etc. A more straight-forward approach would be to put this functionality in the "transaction layer" where transaction objects live and make a clean separation between the two layers.Regards Itamar
-----Original Message-----
From: Bobby Sardana [mailto:bobby.sardana@mobilerain.com]
Sent: Wed, October 18, 2000 6:39 PM
To: discussion@sipforum.org
Cc: mranga@nist.gov; sip@lists.bell-labs.com; jainsip@sun.com
Subject: Re: [SIPFORUM] Re: [SIP] JAIN SIP Specification
 
Greetings Chris:

Just to add a pointer to this thread:

Maintaining trasaction state is an application level functionality and *shouldn't* be implemented in the base stack. For applications like state oriented proxy server, the JAIN SIP can provide enough hooks for event delivery but the state has to be maintained by the proxy server.

Pleas keep up the good work. It is really appreciated.

Regards,

Bobby.Sardana@mobilerain.com

Chris Harris wrote:

"M. Ranganathan" wrote:
Hi Chris,

Thanks for replying so promptly (I am sure you are flooded with email ).

I get one or two :)
 
As you pointed out, I suppose we cannot do away with making Messages
into classes because of the tie-in with java events (unfortunately) but
I still like the notion of being able to specify  interfaces where ever
possible.
I see where you're coming from alright, and I suppose changing header classes into interfaces, could fit in with Gethin's proposal nicely?
 
 I dont quite follow  the motivation behind the following design
decision (excerpted from your reply):

Maybe I've misunderstood what you're saying - but a JAIN SIP
implementation is only stateless when it comes to call state. The
JainSipProvider implementation must maintain transaction state - it
simply exposes a reference to a transaction via the transaction id for
the convenience of the JainSipListener. The service does not have total
control over transacton state - the stack implementation does.

It appears that I have indded mis-understood the architecture.  Why
should the above be so? Can one not rely on the JainSipListener to keep
transaction state also, thereby making the stack simply a way of
recognising messages and triggering  event handlers on the basis of
message type. This would (IMHO) be a cleaner model yet.    That way,  we
can do away with transaction identifiers being passed back and forth and
keep all of this information in the handler.  ( You may have to extend
the architecture somewhat to deal with timeouts and failures so that the
handler knows about transaction failure.) In any case, if this is not a
viable idea, I would be grateful if you can explain why not (or point me
to the portion of the spec that explains why not) so I can get a better
understanding.

It would be cleaner model, and personally I am in total agreement with you - but it means the application is forced to maintain transaction state, match up headers - which has been said places too much of a burden on applications. How about finding a way to let the application choose whether or not it wants to keep transaction state?
 

Regards,

Ranga.

Chris Harris wrote:

> Hi Ranga,
>
> Response below...
>
> Chris
>
> "M. Ranganathan" wrote:
>
>> JAIN-SIP is a groovy idea. Hats off to the whole concept and many
>> thanks to Chris and
>> the JAIN-SIP team for putting together a spec and more flower power
>> to them :-) .  In
>> particular I like the notion of treating UAS,  Redirect and Proxy
>> servers as merely
>> special cases of the general notion of Services and  the idea of
>> unifying these
>> notions with an event mechanism and  event handlers.  Second, I like
>> the idea of
>> separation between a  stateless  event -oriented "stack" and a bunch
>> of event
>> handlers that are triggered by the stack with all state (including
>> transaction
>> state) being separated from the event stack via the JAIN-SIP mapping
>> layer if you
>> will.  ( Correct me if I  wax poetic but have the wrong
>> understanding....)
>
>>
>>
>> I hope I  will not be viewed as being too critical,  but I would
>> like to go  one step
>> further than what Gethin is suggesting.   I am all for using
>> interfaces as much as
>> possible and leaving class hierarchy definitions to implemeters.
>> Defining class
>> hierarchies almost lays out an implementation and involves
>> considerable rework for
>> those who have a working java-based stack, but have not used the
>> same classes. OK it
>> is just a matter of labor to map things to the JAIN-SIP class
>> hierarchy but it  IS a
>> dis-incentive.
>>
>> 1. Lets use interfaces for all messages rather than actually define
>> class
>> hierarchies  ( yes Chris has pointed out the historical precedent
>> behind actually
>> defining class hierarchies for messages. IMHO,  there has to be a
>> more compelling
>> reason than that.)
>
> I suppose all classes could be turned into interfaces, except for the
> Message classes which must extend java.util.EventObject to fit into
> the JAIN framework.
>
>>
>>
>> 2. The tie-in with the JAVA event mechanism has necessitated the
>> explicit definition
>> of class hierarchies in certain places.  Why not use callbacks
>> instead and do away
>> with this dependency as well?  (Basically the same thing as events
>> but does not tie
>> into the JAVA event mechanism and its associated limitations.)
>
> Unfortunately the JAIN framework expilicitly relies on the Java Event
> model, and I don't think callbacks would be accepted within the JAIN
> community.
>
>>
>>
>> Nice work and keep it rolling!  Thanks.
>
> Couldn't do it without you guys - thank you!
>
>>
>>
>> Ranga.
>>
>> Gethin Liddell wrote:
>>
>> > All,
>> >
>> > This idea of abstraction of the JAIN API is certainly a valid and
>> > interesting idea.  However, i'm a bit concerened that the proposed
>>
>> > solution of many different packages, will only seek to complicate
>> and
>> > maybe enlarge the API.
>> >
>> > I too see no reason why there is an EntityHeader etc... and i also
>> do
>> > not see any requirement for an InviteMessage, AckMessage etc...
>> >
>> > How about if the format of the API remains as is:
>> >
>> > jain.protocol.ip.sip
>> > jain.protocol.ip.sip.header
>> > jain.protocol.ip.sip.message
>> >
>> > except that the messages available in the message package
>> consisted of
>> > BasicRequest/Response, MinimalRequest/Response etc... where each
>> > message is extened in turn (e.g. Minimal extends Basic, Moderate
>> > extends Minimal etc...), of course as Chris points out it is not
>> hard
>> > to see that a combination would be required that is not provided.
>> So
>> > in the interest of flexibility, it could be possible for the user
>> to
>> > plug-in to the message class what extra headers it requires.  The
>> only
>> > issue then is that the user will have to use a "public Header
>> > getHeader(String headerName)" and then cast the header to their
>> desired
>> > header type. Either that or create their own Message class
>> > (extending the current ones) that simply does the casting
>> automatically
>> > for them.  Then after compiling, run an obfuscator on the code and
>> it
>> > will automatically extract and only extract the Message, Headers
>> and
>> > even methods that are used.
>> >
>> > This then will also cut down on the number of methods in the
>> Provider
>> > as there will be no need for the sendAck(AckMessage),
>> > sendInvite(InviteMessage) etc.. as they would be replaced by the
>> > single method sendRequest(RequestMessage).
>> >
>> > I personally see three arguments for keeping the JAIN SIP stack as
>> small
>> > as possible:
>> >
>> > 1) The first is for embedded applications where stack size has to
>> be
>> > kept to a minimum as memory is at a premium.  So if just using the
>>
>> > Basic message suffices then this will compile and run with a small
>>
>> > number of classes present from the stack.  Don't forget,
>> obfuscation
>> > will help in extracting only the Messages, Headers and even
>> methods
>> > required from a jar file but it won't do everything.
>> >
>> > 2) The second is that users may be put off or confused by the
>> sheer
>> > size and complexity of the JAIN stack.  So if only using the
>> > BasicMessage gets them on the first rung of the ladder then it is
>> a
>> > good starting point and allows them to build up to bigger and
>> better
>> > things.
>> >
>> > 3) We also have to consider who is going to implement the JAIN SIP
>>
>> > stack. If it is indeed overly complicated then no-one or a single
>> > vendor may end up implmenting the stack and thus its definition
>> and
>> > all the hard work that has gone into it is useless.
>> >
>> > On Mon, 16 Oct 2000, Chris Harris wrote:
>> > > Itamar,
>> > >
>> > > The idea of levelling the API based on what messages, headers
>> and response codes
>> > > are understood is certainly an interesting one - minimal, basic,
>> redirection,
>> > > firewall-friendly, negotiation, authentication and "full".
>> > >
>> > > jain.protocol.ip.sip
>> > > jain.protocol.ip.sip.header
>> > > jain.protocol.ip.sip.message
>> > >
>> > > could then become...
>> > >
>> > > jain.protocol.ip.sip - listener, provider, stack, general
>> classes used at all
>> > > levels
>> > > jain.protocol.ip.sip.header - contains base Header class (and
>> requestHeader,
>> > > ResponseHeader, EntityHeader, GeneralHeader)
>> > > jain.protocol.ip.sip.message - contains base Message class
>> > >
>> > > jain.protocol.ip.sip.minimal - general classes used only at this
>> level and above
>> > >
>> > > jain.protocol.ip.sip.minimal.header - headers used only at this
>> level and above
>> > > jain.protocol.ip.sip.minimal.message - messages only used at
>> this level and
>> > > above
>> > >
>> > > jain.protocol.ip.sip.basic - general classes used only at this
>> level and above
>> > > jain.protocol.ip.sip.basic.header - headers used only at this
>> level and above
>> > > jain.protocol.ip.sip.basic.message - messages used only at this
>> level and above
>> > > ...
>> > > ....
>> > > jjain.protocol.ip.sip."full" - general classes only used at this
>> level
>> > > jain.protocol.ip.sip."full".header - headers used only at this
>> level
>> > > jain.protocol.ip.sip."full".message - messages used only at this
>> level
>> > >
>> > > The API user could then pick the packages they need - say they
>> initially only
>> > > want the minimal features, but then realise they need to use
>> their application
>> > > behind a firewall - then they can simply add the
>> firewall-friendly package. The
>> > > RFC says "In general, each capability listed builds on the ones
>> above it" but it
>> > > is not hard to see that firewall-friendly and authentication may
>> be desired
>> > > without redirection for example.
>> > >
>> > > Is this what you hand in mind Itamar?
>> >
>> > --
>> > Gethin Liddell
>> > Ubiquity Software Corporation
>> >
>> > http://www.ubiquity.net
>> > mailto:gethin@ubiquity.net
>> >
>> > _______________________________________________
>> > SIP mailing list
>> > SIP@lists.bell-labs.com
>> > http://lists.bell-labs.com/mailman/listinfo/sip
>>
>> --
>> M.Ranganathan
>> NIST Advanced Networking Technologies Group,
>> 100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899.
>> Tel: 301 975 3664 Fax: 301 590 0932
>>
>> Hfæj)b? b²Ô^>X¬¶ÆÞ-YZnÇ(sm§ÿåSËlmée*¦ìr?¿?¨¥?©ÿ-+-SwèþÈ©
>

--
M.Ranganathan
NIST Advanced Networking Technologies Group,
100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899.
Tel: 301 975 3664 Fax: 301 590 0932

Hfæj)b? b²Ô^>X¬¶ÆÞ-YZnÇ(sm§ÿåSËlmée*¦ìr?¿?¨¥?©ÿ-+-SwèþÈ©

-- 
M.Ranganathan
NIST Advanced Networking Technologies Group,
100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899. 
Tel: 301 975 3664 Fax: 301 590 0932
  --------------7EF56907BE4D8015F3F5B793-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 18 14:21:42 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA10775 for ; Wed, 18 Oct 2000 14:21:32 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D01AF443C7; Wed, 18 Oct 2000 13:18:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 2CCE8443BB for ; Wed, 18 Oct 2000 13:17:47 -0400 (EDT) Received: from dynamicsoft.com ([212.120.151.56]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id OAA28712; Wed, 18 Oct 2000 14:19:22 -0400 (EDT) Message-ID: <39EDE939.738861C5@dynamicsoft.com> From: Chris Harris Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: discussion@sipforum.org Cc: Itamar Gilad , "'Bobby Sardana'" , mranga@nist.gov, sip@lists.bell-labs.com, jainsip@Sun.COM Subject: Re: [SIPFORUM] Re: [SIP] JAIN SIP Specification References: Content-Type: multipart/alternative; boundary="------------A0F600EF083698B6A3663ED9" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 18 Oct 2000 19:17:30 +0100 --------------A0F600EF083698B6A3663ED9 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit OK - so if an application just sends a message to the Provider, it has to check all response messages to see if they match - this is so messy for an application. What if a response message never arrives - how should the Provider inform the application of a timeout? Call a timeout method and pass the request message back? Itamar Gilad wrote: > Chris, I agree that few SIP applications would like to bother with > transaction mapping. This is clearly the responsibility of the stack > as is transaction management in general. However in a previous thread > you explained that the issue of managing call and transaction state is > outside the scope of this API specification, which led me to believe > that the goal is to define message-related functionality. I think that > injecting transaction keys into the mix is crossing the lines you > defined. Regards, Itamar > > -----Original Message----- > From: Chris Harris [mailto:charris@dynamicsoft.com] > Sent: Wed, October 18, 2000 7:44 PM > To: Itamar Gilad > Cc: 'Bobby Sardana'; discussion@sipforum.org; > mranga@nist.gov; sip@lists.bell-labs.com; jainsip@Sun.COM > Subject: Re: [SIPFORUM] Re: [SIP] JAIN SIP Specification > > Itamar, > > It is for the very reason that identifying a transaction > from a message is not a trivial matter that I wanted to put > the transaction handling inside the JainSipProvider. I don't > think the spec should just deal with just the message layer. > How many people are going to write JAIN SIP applications if > they have to implement their own transaction keys? I'd > imagine very few. > > Regards, > Chris > > Itamar Gilad wrote: > > > Hi again Chris,I'd like to re-emphasize what Bobby says > > below. The JAIN SIP specification presented here seems to > > deal just with the "message layer" i.e. parsing, encoding, > > message and message part containers. I'd like to join > > those who commend the fine and comprehensive work done. > > However, this layer has nothing to do with transactions > > and their state. It would be a mistake to rely on it to > > retain 'transaction-ids' and associate messages to them > > (please correct me if I'm misinterpreting your meaning). > > Note that identifying a transaction from a message is not > > a trivial matter and continuously more message fields are > > added to the "transaction key" in order to deal with > > spiraling, merging etc. A more straight-forward approach > > would be to put this functionality in the "transaction > > layer" where transaction objects live and make a clean > > separation between the two layers.Regards Itamar > > -----Original Message----- > > From: Bobby Sardana [mailto:bobby.sardana@mobilerain.com] > > Sent: Wed, October 18, 2000 6:39 PM > > To: discussion@sipforum.org > > Cc: mranga@nist.gov; sip@lists.bell-labs.com; > > jainsip@sun.com > > Subject: Re: [SIPFORUM] Re: [SIP] JAIN SIP Specification > > > > > > Greetings Chris: > > > > Just to add a pointer to this thread: > > > > Maintaining trasaction state is an application > > level functionality and *shouldn't* be > > implemented in the base stack. For applications > > like state oriented proxy server, the JAIN SIP > > can provide enough hooks for event delivery but > > the state has to be maintained by the proxy > > server. > > > > Pleas keep up the good work. It is really > > appreciated. > > > > Regards, > > > > Bobby.Sardana@mobilerain.com > > > > Chris Harris wrote: > > > > > "M. Ranganathan" wrote: > > > > > >> Hi Chris, > > >> > > >> Thanks for replying so promptly (I am sure > > >> you are flooded with email ). > > > > > > I get one or two :) > > > > > >> > > >> As you pointed out, I suppose we cannot do > > >> away with making Messages > > >> into classes because of the tie-in with java > > >> events (unfortunately) but > > >> I still like the notion of being able to > > >> specify interfaces where ever > > >> possible. > > > > > > I see where you're coming from alright, and I > > > suppose changing header classes into > > > interfaces, could fit in with Gethin's proposal > > > nicely? > > > > > >> > > >> I dont quite follow the motivation behind > > >> the following design > > >> decision (excerpted from your reply): > > >> > > >> Maybe I've misunderstood what you're saying - > > >> but a JAIN SIP > > >> implementation is only stateless when it > > >> comes to call state. The > > >> JainSipProvider implementation must maintain > > >> transaction state - it > > >> simply exposes a reference to a transaction > > >> via the transaction id for > > >> the convenience of the JainSipListener. The > > >> service does not have total > > >> control over transacton state - the stack > > >> implementation does. > > >> > > >> It appears that I have indded mis-understood > > >> the architecture. Why > > >> should the above be so? Can one not rely on > > >> the JainSipListener to keep > > >> transaction state also, thereby making the > > >> stack simply a way of > > >> recognising messages and triggering event > > >> handlers on the basis of > > >> message type. This would (IMHO) be a cleaner > > >> model yet. That way, we > > >> can do away with transaction identifiers > > >> being passed back and forth and > > >> keep all of this information in the handler. > > >> ( You may have to extend > > >> the architecture somewhat to deal with > > >> timeouts and failures so that the > > >> handler knows about transaction failure.) In > > >> any case, if this is not a > > >> viable idea, I would be grateful if you can > > >> explain why not (or point me > > >> to the portion of the spec that explains why > > >> not) so I can get a better > > >> understanding. > > > > > > It would be cleaner model, and personally I am > > > in total agreement with you - but it means the > > > application is forced to maintain transaction > > > state, match up headers - which has been said > > > places too much of a burden on applications. > > > How about finding a way to let the application > > > choose whether or not it wants to keep > > > transaction state? > > > > > >> > > >> > > >> Regards, > > >> > > >> Ranga. > > >> > > >> Chris Harris wrote: > > >> > > >> > Hi Ranga, > > >> > > > >> > Response below... > > >> > > > >> > Chris > > >> > > > >> > "M. Ranganathan" wrote: > > >> > > > >> >> JAIN-SIP is a groovy idea. Hats off to the > > >> whole concept and many > > >> >> thanks to Chris and > > >> >> the JAIN-SIP team for putting together a > > >> spec and more flower power > > >> >> to them :-) . In > > >> >> particular I like the notion of treating > > >> UAS, Redirect and Proxy > > >> >> servers as merely > > >> >> special cases of the general notion of > > >> Services and the idea of > > >> >> unifying these > > >> >> notions with an event mechanism and event > > >> handlers. Second, I like > > >> >> the idea of > > >> >> separation between a stateless event > > >> -oriented "stack" and a bunch > > >> >> of event > > >> >> handlers that are triggered by the stack > > >> with all state (including > > >> >> transaction > > >> >> state) being separated from the event > > >> stack via the JAIN-SIP mapping > > >> >> layer if you > > >> >> will. ( Correct me if I wax poetic but > > >> have the wrong > > >> >> understanding....) > > >> > > > >> >> > > >> >> > > >> >> I hope I will not be viewed as being too > > >> critical, but I would > > >> >> like to go one step > > >> >> further than what Gethin is suggesting. > > >> I am all for using > > >> >> interfaces as much as > > >> >> possible and leaving class hierarchy > > >> definitions to implemeters. > > >> >> Defining class > > >> >> hierarchies almost lays out an > > >> implementation and involves > > >> >> considerable rework for > > >> >> those who have a working java-based stack, > > >> but have not used the > > >> >> same classes. OK it > > >> >> is just a matter of labor to map things to > > >> the JAIN-SIP class > > >> >> hierarchy but it IS a > > >> >> dis-incentive. > > >> >> > > >> >> 1. Lets use interfaces for all messages > > >> rather than actually define > > >> >> class > > >> >> hierarchies ( yes Chris has pointed out > > >> the historical precedent > > >> >> behind actually > > >> >> defining class hierarchies for messages. > > >> IMHO, there has to be a > > >> >> more compelling > > >> >> reason than that.) > > >> > > > >> > I suppose all classes could be turned into > > >> interfaces, except for the > > >> > Message classes which must extend > > >> java.util.EventObject to fit into > > >> > the JAIN framework. > > >> > > > >> >> > > >> >> > > >> >> 2. The tie-in with the JAVA event > > >> mechanism has necessitated the > > >> >> explicit definition > > >> >> of class hierarchies in certain places. > > >> Why not use callbacks > > >> >> instead and do away > > >> >> with this dependency as well? (Basically > > >> the same thing as events > > >> >> but does not tie > > >> >> into the JAVA event mechanism and its > > >> associated limitations.) > > >> > > > >> > Unfortunately the JAIN framework > > >> expilicitly relies on the Java Event > > >> > model, and I don't think callbacks would be > > >> accepted within the JAIN > > >> > community. > > >> > > > >> >> > > >> >> > > >> >> Nice work and keep it rolling! Thanks. > > >> > > > >> > Couldn't do it without you guys - thank > > >> you! > > >> > > > >> >> > > >> >> > > >> >> Ranga. > > >> >> > > >> >> Gethin Liddell wrote: > > >> >> > > >> >> > All, > > >> >> > > > >> >> > This idea of abstraction of the JAIN API > > >> is certainly a valid and > > >> >> > interesting idea. However, i'm a bit > > >> concerened that the proposed > > >> >> > > >> >> > solution of many different packages, > > >> will only seek to complicate > > >> >> and > > >> >> > maybe enlarge the API. > > >> >> > > > >> >> > I too see no reason why there is an > > >> EntityHeader etc... and i also > > >> >> do > > >> >> > not see any requirement for an > > >> InviteMessage, AckMessage etc... > > >> >> > > > >> >> > How about if the format of the API > > >> remains as is: > > >> >> > > > >> >> > jain.protocol.ip.sip > > >> >> > jain.protocol.ip.sip.header > > >> >> > jain.protocol.ip.sip.message > > >> >> > > > >> >> > except that the messages available in > > >> the message package > > >> >> consisted of > > >> >> > BasicRequest/Response, > > >> MinimalRequest/Response etc... where each > > >> >> > message is extened in turn (e.g. Minimal > > >> extends Basic, Moderate > > >> >> > extends Minimal etc...), of course as > > >> Chris points out it is not > > >> >> hard > > >> >> > to see that a combination would be > > >> required that is not provided. > > >> >> So > > >> >> > in the interest of flexibility, it could > > >> be possible for the user > > >> >> to > > >> >> > plug-in to the message class what extra > > >> headers it requires. The > > >> >> only > > >> >> > issue then is that the user will have to > > >> use a "public Header > > >> >> > getHeader(String headerName)" and then > > >> cast the header to their > > >> >> desired > > >> >> > header type. Either that or create their > > >> own Message class > > >> >> > (extending the current ones) that simply > > >> does the casting > > >> >> automatically > > >> >> > for them. Then after compiling, run an > > >> obfuscator on the code and > > >> >> it > > >> >> > will automatically extract and only > > >> extract the Message, Headers > > >> >> and > > >> >> > even methods that are used. > > >> >> > > > >> >> > This then will also cut down on the > > >> number of methods in the > > >> >> Provider > > >> >> > as there will be no need for the > > >> sendAck(AckMessage), > > >> >> > sendInvite(InviteMessage) etc.. as they > > >> would be replaced by the > > >> >> > single method > > >> sendRequest(RequestMessage). > > >> >> > > > >> >> > I personally see three arguments for > > >> keeping the JAIN SIP stack as > > >> >> small > > >> >> > as possible: > > >> >> > > > >> >> > 1) The first is for embedded > > >> applications where stack size has to > > >> >> be > > >> >> > kept to a minimum as memory is at a > > >> premium. So if just using the > > >> >> > > >> >> > Basic message suffices then this will > > >> compile and run with a small > > >> >> > > >> >> > number of classes present from the > > >> stack. Don't forget, > > >> >> obfuscation > > >> >> > will help in extracting only the > > >> Messages, Headers and even > > >> >> methods > > >> >> > required from a jar file but it won't do > > >> everything. > > >> >> > > > >> >> > 2) The second is that users may be put > > >> off or confused by the > > >> >> sheer > > >> >> > size and complexity of the JAIN stack. > > >> So if only using the > > >> >> > BasicMessage gets them on the first rung > > >> of the ladder then it is > > >> >> a > > >> >> > good starting point and allows them to > > >> build up to bigger and > > >> >> better > > >> >> > things. > > >> >> > > > >> >> > 3) We also have to consider who is going > > >> to implement the JAIN SIP > > >> >> > > >> >> > stack. If it is indeed overly > > >> complicated then no-one or a single > > >> >> > vendor may end up implmenting the stack > > >> and thus its definition > > >> >> and > > >> >> > all the hard work that has gone into it > > >> is useless. > > >> >> > > > >> >> > On Mon, 16 Oct 2000, Chris Harris wrote: > > >> > > >> >> > > Itamar, > > >> >> > > > > >> >> > > The idea of levelling the API based on > > >> what messages, headers > > >> >> and response codes > > >> >> > > are understood is certainly an > > >> interesting one - minimal, basic, > > >> >> redirection, > > >> >> > > firewall-friendly, negotiation, > > >> authentication and "full". > > >> >> > > > > >> >> > > jain.protocol.ip.sip > > >> >> > > jain.protocol.ip.sip.header > > >> >> > > jain.protocol.ip.sip.message > > >> >> > > > > >> >> > > could then become... > > >> >> > > > > >> >> > > jain.protocol.ip.sip - listener, > > >> provider, stack, general > > >> >> classes used at all > > >> >> > > levels > > >> >> > > jain.protocol.ip.sip.header - contains > > >> base Header class (and > > >> >> requestHeader, > > >> >> > > ResponseHeader, EntityHeader, > > >> GeneralHeader) > > >> >> > > jain.protocol.ip.sip.message - > > >> contains base Message class > > >> >> > > > > >> >> > > jain.protocol.ip.sip.minimal - general > > >> classes used only at this > > >> >> level and above > > >> >> > > > > >> >> > > jain.protocol.ip.sip.minimal.header - > > >> headers used only at this > > >> >> level and above > > >> >> > > jain.protocol.ip.sip.minimal.message - > > >> messages only used at > > >> >> this level and > > >> >> > > above > > >> >> > > > > >> >> > > jain.protocol.ip.sip.basic - general > > >> classes used only at this > > >> >> level and above > > >> >> > > jain.protocol.ip.sip.basic.header - > > >> headers used only at this > > >> >> level and above > > >> >> > > jain.protocol.ip.sip.basic.message - > > >> messages used only at this > > >> >> level and above > > >> >> > > ... > > >> >> > > .... > > >> >> > > jjain.protocol.ip.sip."full" - general > > >> classes only used at this > > >> >> level > > >> >> > > jain.protocol.ip.sip."full".header - > > >> headers used only at this > > >> >> level > > >> >> > > jain.protocol.ip.sip."full".message - > > >> messages used only at this > > >> >> level > > >> >> > > > > >> >> > > The API user could then pick the > > >> packages they need - say they > > >> >> initially only > > >> >> > > want the minimal features, but then > > >> realise they need to use > > >> >> their application > > >> >> > > behind a firewall - then they can > > >> simply add the > > >> >> firewall-friendly package. The > > >> >> > > RFC says "In general, each capability > > >> listed builds on the ones > > >> >> above it" but it > > >> >> > > is not hard to see that > > >> firewall-friendly and authentication may > > >> >> be desired > > >> >> > > without redirection for example. > > >> >> > > > > >> >> > > Is this what you hand in mind Itamar? > > >> >> > > > >> >> > -- > > >> >> > Gethin Liddell > > >> >> > Ubiquity Software Corporation > > >> >> > > > >> >> > http://www.ubiquity.net > > >> >> > mailto:gethin@ubiquity.net > > >> >> > > > >> >> > > > >> _______________________________________________ > > >> > > >> >> > SIP mailing list > > >> >> > SIP@lists.bell-labs.com > > >> >> > > > >> http://lists.bell-labs.com/mailman/listinfo/sip > > >> > > >> >> > > >> >> -- > > >> >> M.Ranganathan > > >> >> NIST Advanced Networking Technologies > > >> Group, > > >> >> 100 Bureau Drive, Stop 8920, Gaithersburg, > > >> MD 20899. > > >> >> Tel: 301 975 3664 Fax: 301 590 0932 > > >> >> > > >> >> Hfæj)b? > > >> b²Ô^>X¬¶ÆÞ-YZnÇ(sm§ÿåSËlmée*¦ìr?¿?¨¥?©ÿ-+-SwèþÈ© > > >> > > >> > > > >> > > >> -- > > >> M.Ranganathan > > >> NIST Advanced Networking Technologies Group, > > >> 100 Bureau Drive, Stop 8920, Gaithersburg, MD > > >> 20899. > > >> Tel: 301 975 3664 Fax: 301 590 0932 > > >> > > >> Hfæj)b? > > >> b²Ô^>X¬¶ÆÞ-YZnÇ(sm§ÿåSËlmée*¦ìr?¿?¨¥?©ÿ-+-SwèþÈ© > > > --------------A0F600EF083698B6A3663ED9 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit OK - so if an application just sends a message to the Provider, it has to check all response messages to see if they match - this is so messy for an application. What if a response message never arrives - how should the Provider inform the application of a timeout? Call a timeout method and pass the request message back?

Itamar Gilad wrote:

 Chris, I agree that few SIP applications would like to bother with transaction mapping.  This is clearly the responsibility of the stack as is transaction management in general. However in a previous thread you explained that the issue of managing call and transaction state is outside the scope of this API specification, which led me to believe that the goal is to define message-related functionality. I think that injecting transaction keys into the mix is crossing the lines you defined. Regards,  Itamar
-----Original Message-----
From: Chris Harris [mailto:charris@dynamicsoft.com]
Sent: Wed, October 18, 2000 7:44 PM
To: Itamar Gilad
Cc: 'Bobby Sardana'; discussion@sipforum.org; mranga@nist.gov; sip@lists.bell-labs.com; jainsip@Sun.COM
Subject: Re: [SIPFORUM] Re: [SIP] JAIN SIP Specification
 
Itamar,

It is for the very reason that identifying a transaction from a message is not a trivial matter that I wanted to put the transaction handling inside the JainSipProvider. I don't think the spec should just deal with just the message layer. How many people are going to write JAIN SIP applications if they have to implement their own transaction keys? I'd imagine very few.

Regards,
Chris

Itamar Gilad wrote:

Hi again Chris,I'd like to re-emphasize what Bobby says below.  The JAIN SIP specification presented here seems to deal just with the "message layer" i.e. parsing, encoding, message and message part containers.  I'd like to join those who commend the fine and comprehensive work done.  However, this layer has nothing to do with transactions and their state.  It would be a mistake to rely on it to retain 'transaction-ids' and associate messages to them (please correct me if I'm misinterpreting your meaning). Note that identifying a transaction from a message is not a trivial matter and continuously more message fields are added to the "transaction key" in order to deal with spiraling, merging etc. A more straight-forward approach would be to put this functionality in the "transaction layer" where transaction objects live and make a clean separation between the two layers.Regards Itamar
-----Original Message-----
From: Bobby Sardana [mailto:bobby.sardana@mobilerain.com]
Sent: Wed, October 18, 2000 6:39 PM
To: discussion@sipforum.org
Cc: mranga@nist.gov; sip@lists.bell-labs.com; jainsip@sun.com
Subject: Re: [SIPFORUM] Re: [SIP] JAIN SIP Specification
 
Greetings Chris:

Just to add a pointer to this thread:

Maintaining trasaction state is an application level functionality and *shouldn't* be implemented in the base stack. For applications like state oriented proxy server, the JAIN SIP can provide enough hooks for event delivery but the state has to be maintained by the proxy server.

Pleas keep up the good work. It is really appreciated.

Regards,

Bobby.Sardana@mobilerain.com

Chris Harris wrote:

"M. Ranganathan" wrote:
Hi Chris,

Thanks for replying so promptly (I am sure you are flooded with email ).

I get one or two :)
 
As you pointed out, I suppose we cannot do away with making Messages
into classes because of the tie-in with java events (unfortunately) but
I still like the notion of being able to specify  interfaces where ever
possible.
I see where you're coming from alright, and I suppose changing header classes into interfaces, could fit in with Gethin's proposal nicely?
 
 I dont quite follow  the motivation behind the following design
decision (excerpted from your reply):

Maybe I've misunderstood what you're saying - but a JAIN SIP
implementation is only stateless when it comes to call state. The
JainSipProvider implementation must maintain transaction state - it
simply exposes a reference to a transaction via the transaction id for
the convenience of the JainSipListener. The service does not have total
control over transacton state - the stack implementation does.

It appears that I have indded mis-understood the architecture.  Why
should the above be so? Can one not rely on the JainSipListener to keep
transaction state also, thereby making the stack simply a way of
recognising messages and triggering  event handlers on the basis of
message type. This would (IMHO) be a cleaner model yet.    That way,  we
can do away with transaction identifiers being passed back and forth and
keep all of this information in the handler.  ( You may have to extend
the architecture somewhat to deal with timeouts and failures so that the
handler knows about transaction failure.) In any case, if this is not a
viable idea, I would be grateful if you can explain why not (or point me
to the portion of the spec that explains why not) so I can get a better
understanding.

It would be cleaner model, and personally I am in total agreement with you - but it means the application is forced to maintain transaction state, match up headers - which has been said places too much of a burden on applications. How about finding a way to let the application choose whether or not it wants to keep transaction state?
 

Regards,

Ranga.

Chris Harris wrote:

> Hi Ranga,
>
> Response below...
>
> Chris
>
> "M. Ranganathan" wrote:
>
>> JAIN-SIP is a groovy idea. Hats off to the whole concept and many
>> thanks to Chris and
>> the JAIN-SIP team for putting together a spec and more flower power
>> to them :-) .  In
>> particular I like the notion of treating UAS,  Redirect and Proxy
>> servers as merely
>> special cases of the general notion of Services and  the idea of
>> unifying these
>> notions with an event mechanism and  event handlers.  Second, I like
>> the idea of
>> separation between a  stateless  event -oriented "stack" and a bunch
>> of event
>> handlers that are triggered by the stack with all state (including
>> transaction
>> state) being separated from the event stack via the JAIN-SIP mapping
>> layer if you
>> will.  ( Correct me if I  wax poetic but have the wrong
>> understanding....)
>
>>
>>
>> I hope I  will not be viewed as being too critical,  but I would
>> like to go  one step
>> further than what Gethin is suggesting.   I am all for using
>> interfaces as much as
>> possible and leaving class hierarchy definitions to implemeters.
>> Defining class
>> hierarchies almost lays out an implementation and involves
>> considerable rework for
>> those who have a working java-based stack, but have not used the
>> same classes. OK it
>> is just a matter of labor to map things to the JAIN-SIP class
>> hierarchy but it  IS a
>> dis-incentive.
>>
>> 1. Lets use interfaces for all messages rather than actually define
>> class
>> hierarchies  ( yes Chris has pointed out the historical precedent
>> behind actually
>> defining class hierarchies for messages. IMHO,  there has to be a
>> more compelling
>> reason than that.)
>
> I suppose all classes could be turned into interfaces, except for the
> Message classes which must extend java.util.EventObject to fit into
> the JAIN framework.
>
>>
>>
>> 2. The tie-in with the JAVA event mechanism has necessitated the
>> explicit definition
>> of class hierarchies in certain places.  Why not use callbacks
>> instead and do away
>> with this dependency as well?  (Basically the same thing as events
>> but does not tie
>> into the JAVA event mechanism and its associated limitations.)
>
> Unfortunately the JAIN framework expilicitly relies on the Java Event
> model, and I don't think callbacks would be accepted within the JAIN
> community.
>
>>
>>
>> Nice work and keep it rolling!  Thanks.
>
> Couldn't do it without you guys - thank you!
>
>>
>>
>> Ranga.
>>
>> Gethin Liddell wrote:
>>
>> > All,
>> >
>> > This idea of abstraction of the JAIN API is certainly a valid and
>> > interesting idea.  However, i'm a bit concerened that the proposed
>>
>> > solution of many different packages, will only seek to complicate
>> and
>> > maybe enlarge the API.
>> >
>> > I too see no reason why there is an EntityHeader etc... and i also
>> do
>> > not see any requirement for an InviteMessage, AckMessage etc...
>> >
>> > How about if the format of the API remains as is:
>> >
>> > jain.protocol.ip.sip
>> > jain.protocol.ip.sip.header
>> > jain.protocol.ip.sip.message
>> >
>> > except that the messages available in the message package
>> consisted of
>> > BasicRequest/Response, MinimalRequest/Response etc... where each
>> > message is extened in turn (e.g. Minimal extends Basic, Moderate
>> > extends Minimal etc...), of course as Chris points out it is not
>> hard
>> > to see that a combination would be required that is not provided.
>> So
>> > in the interest of flexibility, it could be possible for the user
>> to
>> > plug-in to the message class what extra headers it requires.  The
>> only
>> > issue then is that the user will have to use a "public Header
>> > getHeader(String headerName)" and then cast the header to their
>> desired
>> > header type. Either that or create their own Message class
>> > (extending the current ones) that simply does the casting
>> automatically
>> > for them.  Then after compiling, run an obfuscator on the code and
>> it
>> > will automatically extract and only extract the Message, Headers
>> and
>> > even methods that are used.
>> >
>> > This then will also cut down on the number of methods in the
>> Provider
>> > as there will be no need for the sendAck(AckMessage),
>> > sendInvite(InviteMessage) etc.. as they would be replaced by the
>> > single method sendRequest(RequestMessage).
>> >
>> > I personally see three arguments for keeping the JAIN SIP stack as
>> small
>> > as possible:
>> >
>> > 1) The first is for embedded applications where stack size has to
>> be
>> > kept to a minimum as memory is at a premium.  So if just using the
>>
>> > Basic message suffices then this will compile and run with a small
>>
>> > number of classes present from the stack.  Don't forget,
>> obfuscation
>> > will help in extracting only the Messages, Headers and even
>> methods
>> > required from a jar file but it won't do everything.
>> >
>> > 2) The second is that users may be put off or confused by the
>> sheer
>> > size and complexity of the JAIN stack.  So if only using the
>> > BasicMessage gets them on the first rung of the ladder then it is
>> a
>> > good starting point and allows them to build up to bigger and
>> better
>> > things.
>> >
>> > 3) We also have to consider who is going to implement the JAIN SIP
>>
>> > stack. If it is indeed overly complicated then no-one or a single
>> > vendor may end up implmenting the stack and thus its definition
>> and
>> > all the hard work that has gone into it is useless.
>> >
>> > On Mon, 16 Oct 2000, Chris Harris wrote:
>> > > Itamar,
>> > >
>> > > The idea of levelling the API based on what messages, headers
>> and response codes
>> > > are understood is certainly an interesting one - minimal, basic,
>> redirection,
>> > > firewall-friendly, negotiation, authentication and "full".
>> > >
>> > > jain.protocol.ip.sip
>> > > jain.protocol.ip.sip.header
>> > > jain.protocol.ip.sip.message
>> > >
>> > > could then become...
>> > >
>> > > jain.protocol.ip.sip - listener, provider, stack, general
>> classes used at all
>> > > levels
>> > > jain.protocol.ip.sip.header - contains base Header class (and
>> requestHeader,
>> > > ResponseHeader, EntityHeader, GeneralHeader)
>> > > jain.protocol.ip.sip.message - contains base Message class
>> > >
>> > > jain.protocol.ip.sip.minimal - general classes used only at this
>> level and above
>> > >
>> > > jain.protocol.ip.sip.minimal.header - headers used only at this
>> level and above
>> > > jain.protocol.ip.sip.minimal.message - messages only used at
>> this level and
>> > > above
>> > >
>> > > jain.protocol.ip.sip.basic - general classes used only at this
>> level and above
>> > > jain.protocol.ip.sip.basic.header - headers used only at this
>> level and above
>> > > jain.protocol.ip.sip.basic.message - messages used only at this
>> level and above
>> > > ...
>> > > ....
>> > > jjain.protocol.ip.sip."full" - general classes only used at this
>> level
>> > > jain.protocol.ip.sip."full".header - headers used only at this
>> level
>> > > jain.protocol.ip.sip."full".message - messages used only at this
>> level
>> > >
>> > > The API user could then pick the packages they need - say they
>> initially only
>> > > want the minimal features, but then realise they need to use
>> their application
>> > > behind a firewall - then they can simply add the
>> firewall-friendly package. The
>> > > RFC says "In general, each capability listed builds on the ones
>> above it" but it
>> > > is not hard to see that firewall-friendly and authentication may
>> be desired
>> > > without redirection for example.
>> > >
>> > > Is this what you hand in mind Itamar?
>> >
>> > --
>> > Gethin Liddell
>> > Ubiquity Software Corporation
>> >
>> > http://www.ubiquity.net
>> > mailto:gethin@ubiquity.net
>> >
>> > _______________________________________________
>> > SIP mailing list
>> > SIP@lists.bell-labs.com
>> > http://lists.bell-labs.com/mailman/listinfo/sip
>>
>> --
>> M.Ranganathan
>> NIST Advanced Networking Technologies Group,
>> 100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899.
>> Tel: 301 975 3664 Fax: 301 590 0932
>>
>> Hfæj)b? b²Ô^>X¬¶ÆÞ-YZnÇ(sm§ÿåSËlmée*¦ìr?¿?¨¥?©ÿ-+-SwèþÈ©
>

--
M.Ranganathan
NIST Advanced Networking Technologies Group,
100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899.
Tel: 301 975 3664 Fax: 301 590 0932

Hfæj)b? b²Ô^>X¬¶ÆÞ-YZnÇ(sm§ÿåSËlmée*¦ìr?¿?¨¥?©ÿ-+-SwèþÈ©

--------------A0F600EF083698B6A3663ED9-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 18 14:26:48 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA11453 for ; Wed, 18 Oct 2000 14:26:47 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 62B99443D0; Wed, 18 Oct 2000 13:20:06 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 1E3ED443CF for ; Wed, 18 Oct 2000 13:19:51 -0400 (EDT) Received: from dynamicsoft.com ([212.120.151.56]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id OAA28761; Wed, 18 Oct 2000 14:21:43 -0400 (EDT) Message-ID: <39EDE9C7.526D4225@dynamicsoft.com> From: Chris Harris Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: mranga@nist.gov Cc: sip@lists.bell-labs.com, "'discussion@sipforum.org'" , jainsip@sun.com Subject: Re: [SIPFORUM] Re: [SIP] JAIN SIP Specification References: <39EDE794.83D92EE5@nist.gov> Content-Type: multipart/alternative; boundary="------------4A552F0BBEE506B060A43CA1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 18 Oct 2000 19:19:51 +0100 --------------4A552F0BBEE506B060A43CA1 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit I like your suggestion - if an application has to keep track of transactions, lets make it as easy as possible for it. Alternatively we could define an API that sits on top of the current API. Then an application can use whichever level is more appropriate. "M. Ranganathan" wrote: > Chris Itamar and others, > > Here's a suggestion (shoot down if it makes no sense): > > Would a "reasonable middle ground" be to provide a set of "util api" > that manages transaction state mapping. It could be an optional part > of the core API spec or just a suggested addendum (if people think > this is the right way to go....). I think it does not need to be part > of the "stack". I guess what I am pushing for keeping the stack > stateless, minimal in implementation complexity and minimal in > definition with everything else being moved into the service layer > and/or helper classes for common things services may want to do (like > mapping transaction state etc.) A minimal implementation does not have > to include the helper classes.... > > Regards, > > Ranga. > > > Itamar Gilad wrote: > >> Chris, I agree that few SIP applications would like to bother with >> transaction mapping. This is clearly the responsibility of the >> stack as is transaction management in general. However in a >> previous thread you explained that the issue of managing call and >> transaction state is outside the scope of this API specification, >> which led me to believe that the goal is to define message-related >> functionality. I think that injecting transaction keys into the mix >> is crossing the lines you defined.Regards, Itamar >> >> -----Original Message----- >> From: Chris Harris [mailto:charris@dynamicsoft.com] >> Sent: Wed, October 18, 2000 7:44 PM >> To: Itamar Gilad >> Cc: 'Bobby Sardana'; discussion@sipforum.org; >> mranga@nist.gov; sip@lists.bell-labs.com; jainsip@Sun.COM >> Subject: Re: [SIPFORUM] Re: [SIP] JAIN SIP Specification >> Itamar, >> >> It is for the very reason that identifying a transaction >> from a message is not a trivial matter that I wanted to >> put the transaction handling inside the JainSipProvider. I >> don't think the spec should just deal with just the >> message layer. How many people are going to write JAIN SIP >> applications if they have to implement their own >> transaction keys? I'd imagine very few. >> >> Regards, >> Chris >> >> Itamar Gilad wrote: >> >> > Hi again Chris,I'd like to re-emphasize what Bobby says >> > below. The JAIN SIP specification presented here seems >> > to deal just with the "message layer" i.e. parsing, >> > encoding, message and message part containers. I'd like >> > to join those who commend the fine and comprehensive work >> > done. However, this layer has nothing to do with >> > transactions and their state. It would be a mistake to >> > rely on it to retain 'transaction-ids' and associate >> > messages to them (please correct me if I'm >> > misinterpreting your meaning). Note that identifying a >> > transaction from a message is not a trivial matter and >> > continuously more message fields are added to the >> > "transaction key" in order to deal with spiraling, >> > merging etc. A more straight-forward approach would be to >> > put this functionality in the "transaction layer" where >> > transaction objects live and make a clean separation >> > between the two layers.Regards Itamar >> > -----Original Message----- >> > From: Bobby Sardana [mailto:bobby.sardana@mobilerain.com] >> > >> > Sent: Wed, October 18, 2000 6:39 PM >> > To: discussion@sipforum.org >> > Cc: mranga@nist.gov; sip@lists.bell-labs.com; >> > jainsip@sun.com >> > Subject: Re: [SIPFORUM] Re: [SIP] JAIN SIP Specification >> > >> > >> > Greetings Chris: >> > >> > Just to add a pointer to this thread: >> > >> > Maintaining trasaction state is an application >> > level functionality and *shouldn't* be >> > implemented in the base stack. For applications >> > like state oriented proxy server, the JAIN SIP >> > can provide enough hooks for event delivery but >> > the state has to be maintained by the proxy >> > server. >> > >> > Pleas keep up the good work. It is really >> > appreciated. >> > >> > Regards, >> > >> > Bobby.Sardana@mobilerain.com >> > >> > Chris Harris wrote: >> > >> > > "M. Ranganathan" wrote: >> > > >> > > > Hi Chris, >> > > > >> > > > Thanks for replying so promptly (I am sure >> > > > you are flooded with email ). >> > > >> > > I get one or two :) >> > > >> > > > >> > > > As you pointed out, I suppose we cannot do >> > > > away with making Messages >> > > > into classes because of the tie-in with >> > > > java events (unfortunately) but >> > > > I still like the notion of being able to >> > > > specify interfaces where ever >> > > > possible. >> > > >> > > I see where you're coming from alright, and I >> > > suppose changing header classes into >> > > interfaces, could fit in with Gethin's >> > > proposal nicely? >> > > >> > > > >> > > > I dont quite follow the motivation behind >> > > > the following design >> > > > decision (excerpted from your reply): >> > > > >> > > > Maybe I've misunderstood what you're saying >> > > > - but a JAIN SIP >> > > > implementation is only stateless when it >> > > > comes to call state. The >> > > > JainSipProvider implementation must >> > > > maintain transaction state - it >> > > > simply exposes a reference to a transaction >> > > > via the transaction id for >> > > > the convenience of the JainSipListener. The >> > > > service does not have total >> > > > control over transacton state - the stack >> > > > implementation does. >> > > > >> > > > It appears that I have indded >> > > > mis-understood the architecture. Why >> > > > should the above be so? Can one not rely on >> > > > the JainSipListener to keep >> > > > transaction state also, thereby making the >> > > > stack simply a way of >> > > > recognising messages and triggering event >> > > > handlers on the basis of >> > > > message type. This would (IMHO) be a >> > > > cleaner model yet. That way, we >> > > > can do away with transaction identifiers >> > > > being passed back and forth and >> > > > keep all of this information in the >> > > > handler. ( You may have to extend >> > > > the architecture somewhat to deal with >> > > > timeouts and failures so that the >> > > > handler knows about transaction failure.) >> > > > In any case, if this is not a >> > > > viable idea, I would be grateful if you can >> > > > explain why not (or point me >> > > > to the portion of the spec that explains >> > > > why not) so I can get a better >> > > > understanding. >> > > >> > > It would be cleaner model, and personally I >> > > am in total agreement with you - but it means >> > > the application is forced to maintain >> > > transaction state, match up headers - which >> > > has been said places too much of a burden on >> > > applications. How about finding a way to let >> > > the application choose whether or not it >> > > wants to keep transaction state? >> > > >> > > > >> > > > >> > > > Regards, >> > > > >> > > > Ranga. >> > > > >> > > > Chris Harris wrote: >> > > > >> > > > > Hi Ranga, >> > > > > >> > > > > Response below... >> > > > > >> > > > > Chris >> > > > > >> > > > > "M. Ranganathan" wrote: >> > > > > >> > > > >> JAIN-SIP is a groovy idea. Hats off to >> > > > the whole concept and many >> > > > >> thanks to Chris and >> > > > >> the JAIN-SIP team for putting together a >> > > > spec and more flower power >> > > > >> to them :-) . In >> > > > >> particular I like the notion of treating >> > > > UAS, Redirect and Proxy >> > > > >> servers as merely >> > > > >> special cases of the general notion of >> > > > Services and the idea of >> > > > >> unifying these >> > > > >> notions with an event mechanism and >> > > > event handlers. Second, I like >> > > > >> the idea of >> > > > >> separation between a stateless event >> > > > -oriented "stack" and a bunch >> > > > >> of event >> > > > >> handlers that are triggered by the stack >> > > > with all state (including >> > > > >> transaction >> > > > >> state) being separated from the event >> > > > stack via the JAIN-SIP mapping >> > > > >> layer if you >> > > > >> will. ( Correct me if I wax poetic but >> > > > have the wrong >> > > > >> understanding....) >> > > > > >> > > > >> >> > > > >> >> > > > >> I hope I will not be viewed as being >> > > > too critical, but I would >> > > > >> like to go one step >> > > > >> further than what Gethin is >> > > > suggesting. I am all for using >> > > > >> interfaces as much as >> > > > >> possible and leaving class hierarchy >> > > > definitions to implemeters. >> > > > >> Defining class >> > > > >> hierarchies almost lays out an >> > > > implementation and involves >> > > > >> considerable rework for >> > > > >> those who have a working java-based >> > > > stack, but have not used the >> > > > >> same classes. OK it >> > > > >> is just a matter of labor to map things >> > > > to the JAIN-SIP class >> > > > >> hierarchy but it IS a >> > > > >> dis-incentive. >> > > > >> >> > > > >> 1. Lets use interfaces for all messages >> > > > rather than actually define >> > > > >> class >> > > > >> hierarchies ( yes Chris has pointed out >> > > > the historical precedent >> > > > >> behind actually >> > > > >> defining class hierarchies for messages. >> > > > IMHO, there has to be a >> > > > >> more compelling >> > > > >> reason than that.) >> > > > > >> > > > > I suppose all classes could be turned >> > > > into interfaces, except for the >> > > > > Message classes which must extend >> > > > java.util.EventObject to fit into >> > > > > the JAIN framework. >> > > > > >> > > > >> >> > > > >> >> > > > >> 2. The tie-in with the JAVA event >> > > > mechanism has necessitated the >> > > > >> explicit definition >> > > > >> of class hierarchies in certain places. >> > > > Why not use callbacks >> > > > >> instead and do away >> > > > >> with this dependency as well? >> > > > (Basically the same thing as events >> > > > >> but does not tie >> > > > >> into the JAVA event mechanism and its >> > > > associated limitations.) >> > > > > >> > > > > Unfortunately the JAIN framework >> > > > expilicitly relies on the Java Event >> > > > > model, and I don't think callbacks would >> > > > be accepted within the JAIN >> > > > > community. >> > > > > >> > > > >> >> > > > >> >> > > > >> Nice work and keep it rolling! Thanks. >> > > > > >> > > > > Couldn't do it without you guys - thank >> > > > you! >> > > > > >> > > > >> >> > > > >> >> > > > >> Ranga. >> > > > >> >> > > > >> Gethin Liddell wrote: >> > > > >> >> > > > >> > All, >> > > > >> > >> > > > >> > This idea of abstraction of the JAIN >> > > > API is certainly a valid and >> > > > >> > interesting idea. However, i'm a bit >> > > > concerened that the proposed >> > > > >> >> > > > >> > solution of many different packages, >> > > > will only seek to complicate >> > > > >> and >> > > > >> > maybe enlarge the API. >> > > > >> > >> > > > >> > I too see no reason why there is an >> > > > EntityHeader etc... and i also >> > > > >> do >> > > > >> > not see any requirement for an >> > > > InviteMessage, AckMessage etc... >> > > > >> > >> > > > >> > How about if the format of the API >> > > > remains as is: >> > > > >> > >> > > > >> > jain.protocol.ip.sip >> > > > >> > jain.protocol.ip.sip.header >> > > > >> > jain.protocol.ip.sip.message >> > > > >> > >> > > > >> > except that the messages available in >> > > > the message package >> > > > >> consisted of >> > > > >> > BasicRequest/Response, >> > > > MinimalRequest/Response etc... where each >> > > > >> > message is extened in turn (e.g. >> > > > Minimal extends Basic, Moderate >> > > > >> > extends Minimal etc...), of course as >> > > > Chris points out it is not >> > > > >> hard >> > > > >> > to see that a combination would be >> > > > required that is not provided. >> > > > >> So >> > > > >> > in the interest of flexibility, it >> > > > could be possible for the user >> > > > >> to >> > > > >> > plug-in to the message class what >> > > > extra headers it requires. The >> > > > >> only >> > > > >> > issue then is that the user will have >> > > > to use a "public Header >> > > > >> > getHeader(String headerName)" and then >> > > > cast the header to their >> > > > >> desired >> > > > >> > header type. Either that or create >> > > > their own Message class >> > > > >> > (extending the current ones) that >> > > > simply does the casting >> > > > >> automatically >> > > > >> > for them. Then after compiling, run >> > > > an obfuscator on the code and >> > > > >> it >> > > > >> > will automatically extract and only >> > > > extract the Message, Headers >> > > > >> and >> > > > >> > even methods that are used. >> > > > >> > >> > > > >> > This then will also cut down on the >> > > > number of methods in the >> > > > >> Provider >> > > > >> > as there will be no need for the >> > > > sendAck(AckMessage), >> > > > >> > sendInvite(InviteMessage) etc.. as >> > > > they would be replaced by the >> > > > >> > single method >> > > > sendRequest(RequestMessage). >> > > > >> > >> > > > >> > I personally see three arguments for >> > > > keeping the JAIN SIP stack as >> > > > >> small >> > > > >> > as possible: >> > > > >> > >> > > > >> > 1) The first is for embedded >> > > > applications where stack size has to >> > > > >> be >> > > > >> > kept to a minimum as memory is at a >> > > > premium. So if just using the >> > > > >> >> > > > >> > Basic message suffices then this will >> > > > compile and run with a small >> > > > >> >> > > > >> > number of classes present from the >> > > > stack. Don't forget, >> > > > >> obfuscation >> > > > >> > will help in extracting only the >> > > > Messages, Headers and even >> > > > >> methods >> > > > >> > required from a jar file but it won't >> > > > do everything. >> > > > >> > >> > > > >> > 2) The second is that users may be put >> > > > off or confused by the >> > > > >> sheer >> > > > >> > size and complexity of the JAIN >> > > > stack. So if only using the >> > > > >> > BasicMessage gets them on the first >> > > > rung of the ladder then it is >> > > > >> a >> > > > >> > good starting point and allows them to >> > > > build up to bigger and >> > > > >> better >> > > > >> > things. >> > > > >> > >> > > > >> > 3) We also have to consider who is >> > > > going to implement the JAIN SIP >> > > > >> >> > > > >> > stack. If it is indeed overly >> > > > complicated then no-one or a single >> > > > >> > vendor may end up implmenting the >> > > > stack and thus its definition >> > > > >> and >> > > > >> > all the hard work that has gone into >> > > > it is useless. >> > > > >> > >> > > > >> > On Mon, 16 Oct 2000, Chris Harris >> > > > wrote: >> > > > >> > > Itamar, >> > > > >> > > >> > > > >> > > The idea of levelling the API based >> > > > on what messages, headers >> > > > >> and response codes >> > > > >> > > are understood is certainly an >> > > > interesting one - minimal, basic, >> > > > >> redirection, >> > > > >> > > firewall-friendly, negotiation, >> > > > authentication and "full". >> > > > >> > > >> > > > >> > > jain.protocol.ip.sip >> > > > >> > > jain.protocol.ip.sip.header >> > > > >> > > jain.protocol.ip.sip.message >> > > > >> > > >> > > > >> > > could then become... >> > > > >> > > >> > > > >> > > jain.protocol.ip.sip - listener, >> > > > provider, stack, general >> > > > >> classes used at all >> > > > >> > > levels >> > > > >> > > jain.protocol.ip.sip.header - >> > > > contains base Header class (and >> > > > >> requestHeader, >> > > > >> > > ResponseHeader, EntityHeader, >> > > > GeneralHeader) >> > > > >> > > jain.protocol.ip.sip.message - >> > > > contains base Message class >> > > > >> > > >> > > > >> > > jain.protocol.ip.sip.minimal - >> > > > general classes used only at this >> > > > >> level and above >> > > > >> > > >> > > > >> > > jain.protocol.ip.sip.minimal.header >> > > > - headers used only at this >> > > > >> level and above >> > > > >> > > jain.protocol.ip.sip.minimal.message >> > > > - messages only used at >> > > > >> this level and >> > > > >> > > above >> > > > >> > > >> > > > >> > > jain.protocol.ip.sip.basic - general >> > > > classes used only at this >> > > > >> level and above >> > > > >> > > jain.protocol.ip.sip.basic.header - >> > > > headers used only at this >> > > > >> level and above >> > > > >> > > jain.protocol.ip.sip.basic.message - >> > > > messages used only at this >> > > > >> level and above >> > > > >> > > ... >> > > > >> > > .... >> > > > >> > > jjain.protocol.ip.sip."full" - >> > > > general classes only used at this >> > > > >> level >> > > > >> > > jain.protocol.ip.sip."full".header - >> > > > headers used only at this >> > > > >> level >> > > > >> > > jain.protocol.ip.sip."full".message >> > > > - messages used only at this >> > > > >> level >> > > > >> > > >> > > > >> > > The API user could then pick the >> > > > packages they need - say they >> > > > >> initially only >> > > > >> > > want the minimal features, but then >> > > > realise they need to use >> > > > >> their application >> > > > >> > > behind a firewall - then they can >> > > > simply add the >> > > > >> firewall-friendly package. The >> > > > >> > > RFC says "In general, each >> > > > capability listed builds on the ones >> > > > >> above it" but it >> > > > >> > > is not hard to see that >> > > > firewall-friendly and authentication may >> > > > >> be desired >> > > > >> > > without redirection for example. >> > > > >> > > >> > > > >> > > Is this what you hand in mind >> > > > Itamar? >> > > > >> > >> > > > >> > -- >> > > > >> > Gethin Liddell >> > > > >> > Ubiquity Software Corporation >> > > > >> > >> > > > >> > http://www.ubiquity.net >> > > > >> > mailto:gethin@ubiquity.net >> > > > >> > >> > > > >> > >> > > > _______________________________________________ >> > > > >> > > > >> > SIP mailing list >> > > > >> > SIP@lists.bell-labs.com >> > > > >> > >> > > > http://lists.bell-labs.com/mailman/listinfo/sip >> > > > >> > > > >> >> > > > >> -- >> > > > >> M.Ranganathan >> > > > >> NIST Advanced Networking Technologies >> > > > Group, >> > > > >> 100 Bureau Drive, Stop 8920, >> > > > Gaithersburg, MD 20899. >> > > > >> Tel: 301 975 3664 Fax: 301 590 0932 >> > > > >> >> > > > >> Hfæj)b? >> > > > b²Ô^>X¬¶ÆÞ-YZnÇ(sm§ÿåSËlmée*¦ìr?¿?¨¥?©ÿ-+-SwèþÈ© >> > > > >> > > > > >> > > > >> > > > -- >> > > > M.Ranganathan >> > > > NIST Advanced Networking Technologies >> > > > Group, >> > > > 100 Bureau Drive, Stop 8920, Gaithersburg, >> > > > MD 20899. >> > > > Tel: 301 975 3664 Fax: 301 590 0932 >> > > > >> > > > Hfæj)b? >> > > > b²Ô^>X¬¶ÆÞ-YZnÇ(sm§ÿåSËlmée*¦ìr?¿?¨¥?©ÿ-+-SwèþÈ© >> > > > -- > M.Ranganathan > NIST Advanced Networking Technologies Group, > 100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899. > Tel: 301 975 3664 Fax: 301 590 0932 > > --------------4A552F0BBEE506B060A43CA1 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit I like your suggestion - if an application has to keep track of transactions, lets make it as easy as possible for it. Alternatively we could define an API that sits on top of the current API. Then an application can use whichever level is more appropriate.

"M. Ranganathan" wrote:

Chris  Itamar and others,

Here's a suggestion (shoot down if it makes no sense):

Would a  "reasonable middle ground" be to provide a set of  "util api" that manages transaction state mapping.  It could be an optional  part of the  core API spec or just a suggested addendum (if  people think this is the right way to go....).  I think it does not need to be part of the "stack". I  guess what I am  pushing for keeping the stack stateless, minimal  in implementation complexity and minimal in definition with everything else being moved into the service layer and/or helper  classes for common things services may want to do (like mapping transaction state etc.) A minimal implementation does not have to include the helper classes....

Regards,

Ranga.
 

Itamar Gilad wrote:

Chris, I agree that few SIP applications would like to bother with transaction mapping.  This is clearly the responsibility of the stack as is transaction management in general.  However in a previous thread you explained that the issue of managing call and transaction state is outside the scope of this API specification, which led me to believe that the goal is to define message-related functionality. I think that injecting transaction keys into the mix is crossing the lines you defined.Regards,  Itamar
-----Original Message-----
From: Chris Harris [mailto:charris@dynamicsoft.com]
Sent: Wed, October 18, 2000 7:44 PM
To: Itamar Gilad
Cc: 'Bobby Sardana'; discussion@sipforum.org; mranga@nist.gov; sip@lists.bell-labs.com; jainsip@Sun.COM
Subject: Re: [SIPFORUM] Re: [SIP] JAIN SIP Specification
Itamar,

It is for the very reason that identifying a transaction from a message is not a trivial matter that I wanted to put the transaction handling inside the JainSipProvider. I don't think the spec should just deal with just the message layer. How many people are going to write JAIN SIP applications if they have to implement their own transaction keys? I'd imagine very few.

Regards,
Chris

Itamar Gilad wrote:

Hi again Chris,I'd like to re-emphasize what Bobby says below.  The JAIN SIP specification presented here seems to deal just with the "message layer" i.e. parsing, encoding, message and message part containers.  I'd like to join those who commend the fine and comprehensive work done.  However, this layer has nothing to do with transactions and their state.  It would be a mistake to rely on it to retain 'transaction-ids' and associate messages to them (please correct me if I'm misinterpreting your meaning). Note that identifying a transaction from a message is not a trivial matter and continuously more message fields are added to the "transaction key" in order to deal with spiraling, merging etc. A more straight-forward approach would be to put this functionality in the "transaction layer" where transaction objects live and make a clean separation between the two layers.Regards Itamar
-----Original Message-----
From: Bobby Sardana [mailto:bobby.sardana@mobilerain.com]
Sent: Wed, October 18, 2000 6:39 PM
To: discussion@sipforum.org
Cc: mranga@nist.gov; sip@lists.bell-labs.com; jainsip@sun.com
Subject: Re: [SIPFORUM] Re: [SIP] JAIN SIP Specification
 
Greetings Chris:

Just to add a pointer to this thread:

Maintaining trasaction state is an application level functionality and *shouldn't* be implemented in the base stack. For applications like state oriented proxy server, the JAIN SIP can provide enough hooks for event delivery but the state has to be maintained by the proxy server.

Pleas keep up the good work. It is really appreciated.

Regards,

Bobby.Sardana@mobilerain.com

Chris Harris wrote:

"M. Ranganathan" wrote:
Hi Chris,

Thanks for replying so promptly (I am sure you are flooded with email ).

I get one or two :)
 
As you pointed out, I suppose we cannot do away with making Messages
into classes because of the tie-in with java events (unfortunately) but
I still like the notion of being able to specify  interfaces where ever
possible.
I see where you're coming from alright, and I suppose changing header classes into interfaces, could fit in with Gethin's proposal nicely?
 
 I dont quite follow  the motivation behind the following design
decision (excerpted from your reply):

Maybe I've misunderstood what you're saying - but a JAIN SIP
implementation is only stateless when it comes to call state. The
JainSipProvider implementation must maintain transaction state - it
simply exposes a reference to a transaction via the transaction id for
the convenience of the JainSipListener. The service does not have total
control over transacton state - the stack implementation does.

It appears that I have indded mis-understood the architecture.  Why
should the above be so? Can one not rely on the JainSipListener to keep
transaction state also, thereby making the stack simply a way of
recognising messages and triggering  event handlers on the basis of
message type. This would (IMHO) be a cleaner model yet.    That way,  we
can do away with transaction identifiers being passed back and forth and
keep all of this information in the handler.  ( You may have to extend
the architecture somewhat to deal with timeouts and failures so that the
handler knows about transaction failure.) In any case, if this is not a
viable idea, I would be grateful if you can explain why not (or point me
to the portion of the spec that explains why not) so I can get a better
understanding.

It would be cleaner model, and personally I am in total agreement with you - but it means the application is forced to maintain transaction state, match up headers - which has been said places too much of a burden on applications. How about finding a way to let the application choose whether or not it wants to keep transaction state?
 

Regards,

Ranga.

Chris Harris wrote:

> Hi Ranga,
>
> Response below...
>
> Chris
>
> "M. Ranganathan" wrote:
>
>> JAIN-SIP is a groovy idea. Hats off to the whole concept and many
>> thanks to Chris and
>> the JAIN-SIP team for putting together a spec and more flower power
>> to them :-) .  In
>> particular I like the notion of treating UAS,  Redirect and Proxy
>> servers as merely
>> special cases of the general notion of Services and  the idea of
>> unifying these
>> notions with an event mechanism and  event handlers.  Second, I like
>> the idea of
>> separation between a  stateless  event -oriented "stack" and a bunch
>> of event
>> handlers that are triggered by the stack with all state (including
>> transaction
>> state) being separated from the event stack via the JAIN-SIP mapping
>> layer if you
>> will.  ( Correct me if I  wax poetic but have the wrong
>> understanding....)
>
>>
>>
>> I hope I  will not be viewed as being too critical,  but I would
>> like to go  one step
>> further than what Gethin is suggesting.   I am all for using
>> interfaces as much as
>> possible and leaving class hierarchy definitions to implemeters.
>> Defining class
>> hierarchies almost lays out an implementation and involves
>> considerable rework for
>> those who have a working java-based stack, but have not used the
>> same classes. OK it
>> is just a matter of labor to map things to the JAIN-SIP class
>> hierarchy but it  IS a
>> dis-incentive.
>>
>> 1. Lets use interfaces for all messages rather than actually define
>> class
>> hierarchies  ( yes Chris has pointed out the historical precedent
>> behind actually
>> defining class hierarchies for messages. IMHO,  there has to be a
>> more compelling
>> reason than that.)
>
> I suppose all classes could be turned into interfaces, except for the
> Message classes which must extend java.util.EventObject to fit into
> the JAIN framework.
>
>>
>>
>> 2. The tie-in with the JAVA event mechanism has necessitated the
>> explicit definition
>> of class hierarchies in certain places.  Why not use callbacks
>> instead and do away
>> with this dependency as well?  (Basically the same thing as events
>> but does not tie
>> into the JAVA event mechanism and its associated limitations.)
>
> Unfortunately the JAIN framework expilicitly relies on the Java Event
> model, and I don't think callbacks would be accepted within the JAIN
> community.
>
>>
>>
>> Nice work and keep it rolling!  Thanks.
>
> Couldn't do it without you guys - thank you!
>
>>
>>
>> Ranga.
>>
>> Gethin Liddell wrote:
>>
>> > All,
>> >
>> > This idea of abstraction of the JAIN API is certainly a valid and
>> > interesting idea.  However, i'm a bit concerened that the proposed
>>
>> > solution of many different packages, will only seek to complicate
>> and
>> > maybe enlarge the API.
>> >
>> > I too see no reason why there is an EntityHeader etc... and i also
>> do
>> > not see any requirement for an InviteMessage, AckMessage etc...
>> >
>> > How about if the format of the API remains as is:
>> >
>> > jain.protocol.ip.sip
>> > jain.protocol.ip.sip.header
>> > jain.protocol.ip.sip.message
>> >
>> > except that the messages available in the message package
>> consisted of
>> > BasicRequest/Response, MinimalRequest/Response etc... where each
>> > message is extened in turn (e.g. Minimal extends Basic, Moderate
>> > extends Minimal etc...), of course as Chris points out it is not
>> hard
>> > to see that a combination would be required that is not provided.
>> So
>> > in the interest of flexibility, it could be possible for the user
>> to
>> > plug-in to the message class what extra headers it requires.  The
>> only
>> > issue then is that the user will have to use a "public Header
>> > getHeader(String headerName)" and then cast the header to their
>> desired
>> > header type. Either that or create their own Message class
>> > (extending the current ones) that simply does the casting
>> automatically
>> > for them.  Then after compiling, run an obfuscator on the code and
>> it
>> > will automatically extract and only extract the Message, Headers
>> and
>> > even methods that are used.
>> >
>> > This then will also cut down on the number of methods in the
>> Provider
>> > as there will be no need for the sendAck(AckMessage),
>> > sendInvite(InviteMessage) etc.. as they would be replaced by the
>> > single method sendRequest(RequestMessage).
>> >
>> > I personally see three arguments for keeping the JAIN SIP stack as
>> small
>> > as possible:
>> >
>> > 1) The first is for embedded applications where stack size has to
>> be
>> > kept to a minimum as memory is at a premium.  So if just using the
>>
>> > Basic message suffices then this will compile and run with a small
>>
>> > number of classes present from the stack.  Don't forget,
>> obfuscation
>> > will help in extracting only the Messages, Headers and even
>> methods
>> > required from a jar file but it won't do everything.
>> >
>> > 2) The second is that users may be put off or confused by the
>> sheer
>> > size and complexity of the JAIN stack.  So if only using the
>> > BasicMessage gets them on the first rung of the ladder then it is
>> a
>> > good starting point and allows them to build up to bigger and
>> better
>> > things.
>> >
>> > 3) We also have to consider who is going to implement the JAIN SIP
>>
>> > stack. If it is indeed overly complicated then no-one or a single
>> > vendor may end up implmenting the stack and thus its definition
>> and
>> > all the hard work that has gone into it is useless.
>> >
>> > On Mon, 16 Oct 2000, Chris Harris wrote:
>> > > Itamar,
>> > >
>> > > The idea of levelling the API based on what messages, headers
>> and response codes
>> > > are understood is certainly an interesting one - minimal, basic,
>> redirection,
>> > > firewall-friendly, negotiation, authentication and "full".
>> > >
>> > > jain.protocol.ip.sip
>> > > jain.protocol.ip.sip.header
>> > > jain.protocol.ip.sip.message
>> > >
>> > > could then become...
>> > >
>> > > jain.protocol.ip.sip - listener, provider, stack, general
>> classes used at all
>> > > levels
>> > > jain.protocol.ip.sip.header - contains base Header class (and
>> requestHeader,
>> > > ResponseHeader, EntityHeader, GeneralHeader)
>> > > jain.protocol.ip.sip.message - contains base Message class
>> > >
>> > > jain.protocol.ip.sip.minimal - general classes used only at this
>> level and above
>> > >
>> > > jain.protocol.ip.sip.minimal.header - headers used only at this
>> level and above
>> > > jain.protocol.ip.sip.minimal.message - messages only used at
>> this level and
>> > > above
>> > >
>> > > jain.protocol.ip.sip.basic - general classes used only at this
>> level and above
>> > > jain.protocol.ip.sip.basic.header - headers used only at this
>> level and above
>> > > jain.protocol.ip.sip.basic.message - messages used only at this
>> level and above
>> > > ...
>> > > ....
>> > > jjain.protocol.ip.sip."full" - general classes only used at this
>> level
>> > > jain.protocol.ip.sip."full".header - headers used only at this
>> level
>> > > jain.protocol.ip.sip."full".message - messages used only at this
>> level
>> > >
>> > > The API user could then pick the packages they need - say they
>> initially only
>> > > want the minimal features, but then realise they need to use
>> their application
>> > > behind a firewall - then they can simply add the
>> firewall-friendly package. The
>> > > RFC says "In general, each capability listed builds on the ones
>> above it" but it
>> > > is not hard to see that firewall-friendly and authentication may
>> be desired
>> > > without redirection for example.
>> > >
>> > > Is this what you hand in mind Itamar?
>> >
>> > --
>> > Gethin Liddell
>> > Ubiquity Software Corporation
>> >
>> > http://www.ubiquity.net
>> > mailto:gethin@ubiquity.net
>> >
>> > _______________________________________________
>> > SIP mailing list
>> > SIP@lists.bell-labs.com
>> > http://lists.bell-labs.com/mailman/listinfo/sip
>>
>> --
>> M.Ranganathan
>> NIST Advanced Networking Technologies Group,
>> 100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899.
>> Tel: 301 975 3664 Fax: 301 590 0932
>>
>> Hfæj)b? b²Ô^>X¬¶ÆÞ-YZnÇ(sm§ÿåSËlmée*¦ìr?¿?¨¥?©ÿ-+-SwèþÈ©
>

--
M.Ranganathan
NIST Advanced Networking Technologies Group,
100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899.
Tel: 301 975 3664 Fax: 301 590 0932

Hfæj)b? b²Ô^>X¬¶ÆÞ-YZnÇ(sm§ÿåSËlmée*¦ìr?¿?¨¥?©ÿ-+-SwèþÈ©

-- 
M.Ranganathan
NIST Advanced Networking Technologies Group,
100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899. 
Tel: 301 975 3664 Fax: 301 590 0932
 
--------------4A552F0BBEE506B060A43CA1-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 18 14:35:43 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA12573 for ; Wed, 18 Oct 2000 14:35:40 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1097C44393; Wed, 18 Oct 2000 13:34:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from guardian1.tlv.radvision.com (unknown [212.143.185.30]) by lists.bell-labs.com (Postfix) with ESMTP id C4CDD44336 for ; Wed, 18 Oct 2000 13:33:15 -0400 (EDT) Received: from nt-mail.tlv.radvision.com ([172.20.2.100]) by guardian1.tlv.radvision.com (Post.Office MTA v3.5.3 release 223 ID# 0-0U10L2S100V35) with ESMTP id com; Wed, 18 Oct 2000 21:31:58 +0200 Received: by NT-MAIL with Internet Mail Service (5.5.2650.21) id ; Wed, 18 Oct 2000 20:33:19 +0200 Message-ID: From: Itamar Gilad To: "'Chris Harris'" , discussion@sipforum.org Cc: Itamar Gilad , "'Bobby Sardana'" , mranga@nist.gov, sip@lists.bell-labs.com, jainsip@Sun.COM Subject: RE: [SIPFORUM] Re: [SIP] JAIN SIP Specification MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C03931.E3091D60" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 18 Oct 2000 20:33:19 +0200 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_01C03931.E3091D60 Content-Type: text/plain; charset="iso-8859-1" No, that's not it. The application uses a stack to do all of this. The stack should export a message-related API like the one defined in the JAIN SIP specification you presented. The stack should also export interfaces for Call control and Transaction control. It seems more logical for the application to use a transaction object which handles messaging and notifies it whenever a message belonging to this transaction is received rather then having a message object that tells it which transaction it belongs too. Stateless proxies for example would use only the message layer and they don't care at all about transactions. I'm Sorry to be so picky, but I just think that this makes for a cleaner design both in the application and in the stack. Our experience with our SIP stack proves that this model works fine. Itamar -----Original Message----- From: Chris Harris [mailto:charris@dynamicsoft.com] Sent: Wed, October 18, 2000 8:18 PM To: discussion@sipforum.org Cc: Itamar Gilad; 'Bobby Sardana'; mranga@nist.gov; sip@lists.bell-labs.com; jainsip@Sun.COM Subject: Re: [SIPFORUM] Re: [SIP] JAIN SIP Specification OK - so if an application just sends a message to the Provider, it has to check all response messages to see if they match - this is so messy for an application. What if a response message never arrives - how should the Provider inform the application of a timeout? Call a timeout method and pass the request message back? Itamar Gilad wrote: Chris, I agree that few SIP applications would like to bother with transaction mapping. This is clearly the responsibility of the stack as is transaction management in general. However in a previous thread you explained that the issue of managing call and transaction state is outside the scope of this API specification, which led me to believe that the goal is to define message-related functionality. I think that injecting transaction keys into the mix is crossing the lines you defined. Regards, Itamar -----Original Message----- From: Chris Harris [ mailto:charris@dynamicsoft.com ] Sent: Wed, October 18, 2000 7:44 PM To: Itamar Gilad Cc: 'Bobby Sardana'; discussion@sipforum.org; mranga@nist.gov; sip@lists.bell-labs.com; jainsip@Sun.COM Subject: Re: [SIPFORUM] Re: [SIP] JAIN SIP Specification Itamar, It is for the very reason that identifying a transaction from a message is not a trivial matter that I wanted to put the transaction handling inside the JainSipProvider. I don't think the spec should just deal with just the message layer. How many people are going to write JAIN SIP applications if they have to implement their own transaction keys? I'd imagine very few. Regards, Chris Itamar Gilad wrote: Hi again Chris,I'd like to re-emphasize what Bobby says below. The JAIN SIP specification presented here seems to deal just with the "message layer" i.e. parsing, encoding, message and message part containers. I'd like to join those who commend the fine and comprehensive work done. However, this layer has nothing to do with transactions and their state. It would be a mistake to rely on it to retain 'transaction-ids' and associate messages to them (please correct me if I'm misinterpreting your meaning). Note that identifying a transaction from a message is not a trivial matter and continuously more message fields are added to the "transaction key" in order to deal with spiraling, merging etc. A more straight-forward approach would be to put this functionality in the "transaction layer" where transaction objects live and make a clean separation between the two layers.Regards Itamar -----Original Message----- From: Bobby Sardana [ mailto:bobby.sardana@mobilerain.com ] Sent: Wed, October 18, 2000 6:39 PM To: discussion@sipforum.org Cc: mranga@nist.gov; sip@lists.bell-labs.com; jainsip@sun.com Subject: Re: [SIPFORUM] Re: [SIP] JAIN SIP Specification Greetings Chris: Just to add a pointer to this thread: Maintaining trasaction state is an application level functionality and *shouldn't* be implemented in the base stack. For applications like state oriented proxy server, the JAIN SIP can provide enough hooks for event delivery but the state has to be maintained by the proxy server. Pleas keep up the good work. It is really appreciated. Regards, Bobby.Sardana@mobilerain.com Chris Harris wrote: "M. Ranganathan" wrote: Hi Chris, Thanks for replying so promptly (I am sure you are flooded with email ). I get one or two :) As you pointed out, I suppose we cannot do away with making Messages into classes because of the tie-in with java events (unfortunately) but I still like the notion of being able to specify interfaces where ever possible. I see where you're coming from alright, and I suppose changing header classes into interfaces, could fit in with Gethin's proposal nicely? I dont quite follow the motivation behind the following design decision (excerpted from your reply): Maybe I've misunderstood what you're saying - but a JAIN SIP implementation is only stateless when it comes to call state. The JainSipProvider implementation must maintain transaction state - it simply exposes a reference to a transaction via the transaction id for the convenience of the JainSipListener. The service does not have total control over transacton state - the stack implementation does. It appears that I have indded mis-understood the architecture. Why should the above be so? Can one not rely on the JainSipListener to keep transaction state also, thereby making the stack simply a way of recognising messages and triggering event handlers on the basis of message type. This would (IMHO) be a cleaner model yet. That way, we can do away with transaction identifiers being passed back and forth and keep all of this information in the handler. ( You may have to extend the architecture somewhat to deal with timeouts and failures so that the handler knows about transaction failure.) In any case, if this is not a viable idea, I would be grateful if you can explain why not (or point me to the portion of the spec that explains why not) so I can get a better understanding. It would be cleaner model, and personally I am in total agreement with you - but it means the application is forced to maintain transaction state, match up headers - which has been said places too much of a burden on applications. How about finding a way to let the application choose whether or not it wants to keep transaction state? Regards, Ranga. Chris Harris wrote: > Hi Ranga, > > Response below... > > Chris > > "M. Ranganathan" wrote: > >> JAIN-SIP is a groovy idea. Hats off to the whole concept and many >> thanks to Chris and >> the JAIN-SIP team for putting together a spec and more flower power >> to them :-) . In >> particular I like the notion of treating UAS, Redirect and Proxy >> servers as merely >> special cases of the general notion of Services and the idea of >> unifying these >> notions with an event mechanism and event handlers. Second, I like >> the idea of >> separation between a stateless event -oriented "stack" and a bunch >> of event >> handlers that are triggered by the stack with all state (including >> transaction >> state) being separated from the event stack via the JAIN-SIP mapping >> layer if you >> will. ( Correct me if I wax poetic but have the wrong >> understanding....) > >> >> >> I hope I will not be viewed as being too critical, but I would >> like to go one step >> further than what Gethin is suggesting. I am all for using >> interfaces as much as >> possible and leaving class hierarchy definitions to implemeters. >> Defining class >> hierarchies almost lays out an implementation and involves >> considerable rework for >> those who have a working java-based stack, but have not used the >> same classes. OK it >> is just a matter of labor to map things to the JAIN-SIP class >> hierarchy but it IS a >> dis-incentive. >> >> 1. Lets use interfaces for all messages rather than actually define >> class >> hierarchies ( yes Chris has pointed out the historical precedent >> behind actually >> defining class hierarchies for messages. IMHO, there has to be a >> more compelling >> reason than that.) > > I suppose all classes could be turned into interfaces, except for the > Message classes which must extend java.util.EventObject to fit into > the JAIN framework. > >> >> >> 2. The tie-in with the JAVA event mechanism has necessitated the >> explicit definition >> of class hierarchies in certain places. Why not use callbacks >> instead and do away >> with this dependency as well? (Basically the same thing as events >> but does not tie >> into the JAVA event mechanism and its associated limitations.) > > Unfortunately the JAIN framework expilicitly relies on the Java Event > model, and I don't think callbacks would be accepted within the JAIN > community. > >> >> >> Nice work and keep it rolling! Thanks. > > Couldn't do it without you guys - thank you! > >> >> >> Ranga. >> >> Gethin Liddell wrote: >> >> > All, >> > >> > This idea of abstraction of the JAIN API is certainly a valid and >> > interesting idea. However, i'm a bit concerened that the proposed >> >> > solution of many different packages, will only seek to complicate >> and >> > maybe enlarge the API. >> > >> > I too see no reason why there is an EntityHeader etc... and i also >> do >> > not see any requirement for an InviteMessage, AckMessage etc... >> > >> > How about if the format of the API remains as is: >> > >> > jain.protocol.ip.sip >> > jain.protocol.ip.sip.header >> > jain.protocol.ip.sip.message >> > >> > except that the messages available in the message package >> consisted of >> > BasicRequest/Response, MinimalRequest/Response etc... where each >> > message is extened in turn (e.g. Minimal extends Basic, Moderate >> > extends Minimal etc...), of course as Chris points out it is not >> hard >> > to see that a combination would be required that is not provided. >> So >> > in the interest of flexibility, it could be possible for the user >> to >> > plug-in to the message class what extra headers it requires. The >> only >> > issue then is that the user will have to use a "public Header >> > getHeader(String headerName)" and then cast the header to their >> desired >> > header type. Either that or create their own Message class >> > (extending the current ones) that simply does the casting >> automatically >> > for them. Then after compiling, run an obfuscator on the code and >> it >> > will automatically extract and only extract the Message, Headers >> and >> > even methods that are used. >> > >> > This then will also cut down on the number of methods in the >> Provider >> > as there will be no need for the sendAck(AckMessage), >> > sendInvite(InviteMessage) etc.. as they would be replaced by the >> > single method sendRequest(RequestMessage). >> > >> > I personally see three arguments for keeping the JAIN SIP stack as >> small >> > as possible: >> > >> > 1) The first is for embedded applications where stack size has to >> be >> > kept to a minimum as memory is at a premium. So if just using the >> >> > Basic message suffices then this will compile and run with a small >> >> > number of classes present from the stack. Don't forget, >> obfuscation >> > will help in extracting only the Messages, Headers and even >> methods >> > required from a jar file but it won't do everything. >> > >> > 2) The second is that users may be put off or confused by the >> sheer >> > size and complexity of the JAIN stack. So if only using the >> > BasicMessage gets them on the first rung of the ladder then it is >> a >> > good starting point and allows them to build up to bigger and >> better >> > things. >> > >> > 3) We also have to consider who is going to implement the JAIN SIP >> >> > stack. If it is indeed overly complicated then no-one or a single >> > vendor may end up implmenting the stack and thus its definition >> and >> > all the hard work that has gone into it is useless. >> > >> > On Mon, 16 Oct 2000, Chris Harris wrote: >> > > Itamar, >> > > >> > > The idea of levelling the API based on what messages, headers >> and response codes >> > > are understood is certainly an interesting one - minimal, basic, >> redirection, >> > > firewall-friendly, negotiation, authentication and "full". >> > > >> > > jain.protocol.ip.sip >> > > jain.protocol.ip.sip.header >> > > jain.protocol.ip.sip.message >> > > >> > > could then become... >> > > >> > > jain.protocol.ip.sip - listener, provider, stack, general >> classes used at all >> > > levels >> > > jain.protocol.ip.sip.header - contains base Header class (and >> requestHeader, >> > > ResponseHeader, EntityHeader, GeneralHeader) >> > > jain.protocol.ip.sip.message - contains base Message class >> > > >> > > jain.protocol.ip.sip.minimal - general classes used only at this >> level and above >> > > >> > > jain.protocol.ip.sip.minimal.header - headers used only at this >> level and above >> > > jain.protocol.ip.sip.minimal.message - messages only used at >> this level and >> > > above >> > > >> > > jain.protocol.ip.sip.basic - general classes used only at this >> level and above >> > > jain.protocol.ip.sip.basic.header - headers used only at this >> level and above >> > > jain.protocol.ip.sip.basic.message - messages used only at this >> level and above >> > > ... >> > > .... >> > > jjain.protocol.ip.sip."full" - general classes only used at this >> level >> > > jain.protocol.ip.sip."full".header - headers used only at this >> level >> > > jain.protocol.ip.sip."full".message - messages used only at this >> level >> > > >> > > The API user could then pick the packages they need - say they >> initially only >> > > want the minimal features, but then realise they need to use >> their application >> > > behind a firewall - then they can simply add the >> firewall-friendly package. The >> > > RFC says "In general, each capability listed builds on the ones >> above it" but it >> > > is not hard to see that firewall-friendly and authentication may >> be desired >> > > without redirection for example. >> > > >> > > Is this what you hand in mind Itamar? >> > >> > -- >> > Gethin Liddell >> > Ubiquity Software Corporation >> > >> > http://www.ubiquity.net >> > mailto:gethin@ubiquity.net >> > >> > _______________________________________________ >> > SIP mailing list >> > SIP@lists.bell-labs.com >> > http://lists.bell-labs.com/mailman/listinfo/sip >> >> -- >> M.Ranganathan >> NIST Advanced Networking Technologies Group, >> 100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899. >> Tel: 301 975 3664 Fax: 301 590 0932 >> >> Hfæj)b? b²Ô^>X¬¶ÆÞ-YZnÇ(sm§ÿåSËlmée*¦ìr?¿?¨¥?©ÿ-+-SwèþÈ© > -- M.Ranganathan NIST Advanced Networking Technologies Group, 100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899. Tel: 301 975 3664 Fax: 301 590 0932 Hfæj)b? b²Ô^>X¬¶ÆÞ-YZnÇ(sm§ÿåSËlmée*¦ìr?¿?¨¥?©ÿ-+-SwèþÈ© ------_=_NextPart_001_01C03931.E3091D60 Content-Type: text/html; charset="iso-8859-1"
No, that's not it.  The application uses a stack to do all of this.  The stack should export a message-related API like the one defined in the JAIN SIP specification you presented.  The stack should also export interfaces for Call control and Transaction control.  It seems more logical for the application to use a transaction object which handles messaging and notifies it whenever a message belonging to this transaction is received rather then having a message object that tells it which transaction it belongs too.  Stateless proxies for example would use only the message layer and they don't care at all about transactions. 
I'm Sorry to be so picky, but I just think that this makes for a cleaner design both in the application and in the stack.  Our experience with our SIP stack proves that this model works fine.
 
Itamar
 
-----Original Message-----
From: Chris Harris [mailto:charris@dynamicsoft.com]
Sent: Wed, October 18, 2000 8:18 PM
To: discussion@sipforum.org
Cc: Itamar Gilad; 'Bobby Sardana'; mranga@nist.gov; sip@lists.bell-labs.com; jainsip@Sun.COM
Subject: Re: [SIPFORUM] Re: [SIP] JAIN SIP Specification

OK - so if an application just sends a message to the Provider, it has to check all response messages to see if they match - this is so messy for an application. What if a response message never arrives - how should the Provider inform the application of a timeout? Call a timeout method and pass the request message back?

Itamar Gilad wrote:

 Chris, I agree that few SIP applications would like to bother with transaction mapping.  This is clearly the responsibility of the stack as is transaction management in general. However in a previous thread you explained that the issue of managing call and transaction state is outside the scope of this API specification, which led me to believe that the goal is to define message-related functionality. I think that injecting transaction keys into the mix is crossing the lines you defined. Regards,  Itamar
-----Original Message-----
From: Chris Harris [mailto:charris@dynamicsoft.com]
Sent: Wed, October 18, 2000 7:44 PM
To: Itamar Gilad
Cc: 'Bobby Sardana'; discussion@sipforum.org; mranga@nist.gov; sip@lists.bell-labs.com; jainsip@Sun.COM
Subject: Re: [SIPFORUM] Re: [SIP] JAIN SIP Specification
 
Itamar,

It is for the very reason that identifying a transaction from a message is not a trivial matter that I wanted to put the transaction handling inside the JainSipProvider. I don't think the spec should just deal with just the message layer. How many people are going to write JAIN SIP applications if they have to implement their own transaction keys? I'd imagine very few.

Regards,
Chris

Itamar Gilad wrote:

Hi again Chris,I'd like to re-emphasize what Bobby says below.  The JAIN SIP specification presented here seems to deal just with the "message layer" i.e. parsing, encoding, message and message part containers.  I'd like to join those who commend the fine and comprehensive work done.  However, this layer has nothing to do with transactions and their state.  It would be a mistake to rely on it to retain 'transaction-ids' and associate messages to them (please correct me if I'm misinterpreting your meaning). Note that identifying a transaction from a message is not a trivial matter and continuously more message fields are added to the "transaction key" in order to deal with spiraling, merging etc. A more straight-forward approach would be to put this functionality in the "transaction layer" where transaction objects live and make a clean separation between the two layers.Regards Itamar
-----Original Message-----
From: Bobby Sardana [mailto:bobby.sardana@mobilerain.com]
Sent: Wed, October 18, 2000 6:39 PM
To: discussion@sipforum.org
Cc: mranga@nist.gov; sip@lists.bell-labs.com; jainsip@sun.com
Subject: Re: [SIPFORUM] Re: [SIP] JAIN SIP Specification
 
Greetings Chris:

Just to add a pointer to this thread:

Maintaining trasaction state is an application level functionality and *shouldn't* be implemented in the base stack. For applications like state oriented proxy server, the JAIN SIP can provide enough hooks for event delivery but the state has to be maintained by the proxy server.

Pleas keep up the good work. It is really appreciated.

Regards,

Bobby.Sardana@mobilerain.com

Chris Harris wrote:

"M. Ranganathan" wrote:
Hi Chris,

Thanks for replying so promptly (I am sure you are flooded with email ).

I get one or two :)

As you pointed out, I suppose we cannot do away with making Messages
into classes because of the tie-in with java events (unfortunately) but
I still like the notion of being able to specify  interfaces where ever
possible.
I see where you're coming from alright, and I suppose changing header classes into interfaces, could fit in with Gethin's proposal nicely?

 I dont quite follow  the motivation behind the following design
decision (excerpted from your reply):

Maybe I've misunderstood what you're saying - but a JAIN SIP
implementation is only stateless when it comes to call state. The
JainSipProvider implementation must maintain transaction state - it
simply exposes a reference to a transaction via the transaction id for
the convenience of the JainSipListener. The service does not have total
control over transacton state - the stack implementation does.

It appears that I have indded mis-understood the architecture.  Why
should the above be so? Can one not rely on the JainSipListener to keep
transaction state also, thereby making the stack simply a way of
recognising messages and triggering  event handlers on the basis of
message type. This would (IMHO) be a cleaner model yet.    That way,  we
can do away with transaction identifiers being passed back and forth and
keep all of this information in the handler.  ( You may have to extend
the architecture somewhat to deal with timeouts and failures so that the
handler knows about transaction failure.) In any case, if this is not a
viable idea, I would be grateful if you can explain why not (or point me
to the portion of the spec that explains why not) so I can get a better
understanding.

It would be cleaner model, and personally I am in total agreement with you - but it means the application is forced to maintain transaction state, match up headers - which has been said places too much of a burden on applications. How about finding a way to let the application choose whether or not it wants to keep transaction state?
 

Regards,

Ranga.

Chris Harris wrote:

> Hi Ranga,
>
> Response below...
>
> Chris
>
> "M. Ranganathan" wrote:
>
>> JAIN-SIP is a groovy idea. Hats off to the whole concept and many
>> thanks to Chris and
>> the JAIN-SIP team for putting together a spec and more flower power
>> to them :-) .  In
>> particular I like the notion of treating UAS,  Redirect and Proxy
>> servers as merely
>> special cases of the general notion of Services and  the idea of
>> unifying these
>> notions with an event mechanism and  event handlers.  Second, I like
>> the idea of
>> separation between a  stateless  event -oriented "stack" and a bunch
>> of event
>> handlers that are triggered by the stack with all state (including
>> transaction
>> state) being separated from the event stack via the JAIN-SIP mapping
>> layer if you
>> will.  ( Correct me if I  wax poetic but have the wrong
>> understanding....)
>
>>
>>
>> I hope I  will not be viewed as being too critical,  but I would
>> like to go  one step
>> further than what Gethin is suggesting.   I am all for using
>> interfaces as much as
>> possible and leaving class hierarchy definitions to implemeters.
>> Defining class
>> hierarchies almost lays out an implementation and involves
>> considerable rework for
>> those who have a working java-based stack, but have not used the
>> same classes. OK it
>> is just a matter of labor to map things to the JAIN-SIP class
>> hierarchy but it  IS a
>> dis-incentive.
>>
>> 1. Lets use interfaces for all messages rather than actually define
>> class
>> hierarchies  ( yes Chris has pointed out the historical precedent
>> behind actually
>> defining class hierarchies for messages. IMHO,  there has to be a
>> more compelling
>> reason than that.)
>
> I suppose all classes could be turned into interfaces, except for the
> Message classes which must extend java.util.EventObject to fit into
> the JAIN framework.
>
>>
>>
>> 2. The tie-in with the JAVA event mechanism has necessitated the
>> explicit definition
>> of class hierarchies in certain places.  Why not use callbacks
>> instead and do away
>> with this dependency as well?  (Basically the same thing as events
>> but does not tie
>> into the JAVA event mechanism and its associated limitations.)
>
> Unfortunately the JAIN framework expilicitly relies on the Java Event
> model, and I don't think callbacks would be accepted within the JAIN
> community.
>
>>
>>
>> Nice work and keep it rolling!  Thanks.
>
> Couldn't do it without you guys - thank you!
>
>>
>>
>> Ranga.
>>
>> Gethin Liddell wrote:
>>
>> > All,
>> >
>> > This idea of abstraction of the JAIN API is certainly a valid and
>> > interesting idea.  However, i'm a bit concerened that the proposed
>>
>> > solution of many different packages, will only seek to complicate
>> and
>> > maybe enlarge the API.
>> >
>> > I too see no reason why there is an EntityHeader etc... and i also
>> do
>> > not see any requirement for an InviteMessage, AckMessage etc...
>> >
>> > How about if the format of the API remains as is:
>> >
>> > jain.protocol.ip.sip
>> > jain.protocol.ip.sip.header
>> > jain.protocol.ip.sip.message
>> >
>> > except that the messages available in the message package
>> consisted of
>> > BasicRequest/Response, MinimalRequest/Response etc... where each
>> > message is extened in turn (e.g. Minimal extends Basic, Moderate
>> > extends Minimal etc...), of course as Chris points out it is not
>> hard
>> > to see that a combination would be required that is not provided.
>> So
>> > in the interest of flexibility, it could be possible for the user
>> to
>> > plug-in to the message class what extra headers it requires.  The
>> only
>> > issue then is that the user will have to use a "public Header
>> > getHeader(String headerName)" and then cast the header to their
>> desired
>> > header type. Either that or create their own Message class
>> > (extending the current ones) that simply does the casting
>> automatically
>> > for them.  Then after compiling, run an obfuscator on the code and
>> it
>> > will automatically extract and only extract the Message, Headers
>> and
>> > even methods that are used.
>> >
>> > This then will also cut down on the number of methods in the
>> Provider
>> > as there will be no need for the sendAck(AckMessage),
>> > sendInvite(InviteMessage) etc.. as they would be replaced by the
>> > single method sendRequest(RequestMessage).
>> >
>> > I personally see three arguments for keeping the JAIN SIP stack as
>> small
>> > as possible:
>> >
>> > 1) The first is for embedded applications where stack size has to
>> be
>> > kept to a minimum as memory is at a premium.  So if just using the
>>
>> > Basic message suffices then this will compile and run with a small
>>
>> > number of classes present from the stack.  Don't forget,
>> obfuscation
>> > will help in extracting only the Messages, Headers and even
>> methods
>> > required from a jar file but it won't do everything.
>> >
>> > 2) The second is that users may be put off or confused by the
>> sheer
>> > size and complexity of the JAIN stack.  So if only using the
>> > BasicMessage gets them on the first rung of the ladder then it is
>> a
>> > good starting point and allows them to build up to bigger and
>> better
>> > things.
>> >
>> > 3) We also have to consider who is going to implement the JAIN SIP
>>
>> > stack. If it is indeed overly complicated then no-one or a single
>> > vendor may end up implmenting the stack and thus its definition
>> and
>> > all the hard work that has gone into it is useless.
>> >
>> > On Mon, 16 Oct 2000, Chris Harris wrote:
>> > > Itamar,
>> > >
>> > > The idea of levelling the API based on what messages, headers
>> and response codes
>> > > are understood is certainly an interesting one - minimal, basic,
>> redirection,
>> > > firewall-friendly, negotiation, authentication and "full".
>> > >
>> > > jain.protocol.ip.sip
>> > > jain.protocol.ip.sip.header
>> > > jain.protocol.ip.sip.message
>> > >
>> > > could then become...
>> > >
>> > > jain.protocol.ip.sip - listener, provider, stack, general
>> classes used at all
>> > > levels
>> > > jain.protocol.ip.sip.header - contains base Header class (and
>> requestHeader,
>> > > ResponseHeader, EntityHeader, GeneralHeader)
>> > > jain.protocol.ip.sip.message - contains base Message class
>> > >
>> > > jain.protocol.ip.sip.minimal - general classes used only at this
>> level and above
>> > >
>> > > jain.protocol.ip.sip.minimal.header - headers used only at this
>> level and above
>> > > jain.protocol.ip.sip.minimal.message - messages only used at
>> this level and
>> > > above
>> > >
>> > > jain.protocol.ip.sip.basic - general classes used only at this
>> level and above
>> > > jain.protocol.ip.sip.basic.header - headers used only at this
>> level and above
>> > > jain.protocol.ip.sip.basic.message - messages used only at this
>> level and above
>> > > ...
>> > > ....
>> > > jjain.protocol.ip.sip."full" - general classes only used at this
>> level
>> > > jain.protocol.ip.sip."full".header - headers used only at this
>> level
>> > > jain.protocol.ip.sip."full".message - messages used only at this
>> level
>> > >
>> > > The API user could then pick the packages they need - say they
>> initially only
>> > > want the minimal features, but then realise they need to use
>> their application
>> > > behind a firewall - then they can simply add the
>> firewall-friendly package. The
>> > > RFC says "In general, each capability listed builds on the ones
>> above it" but it
>> > > is not hard to see that firewall-friendly and authentication may
>> be desired
>> > > without redirection for example.
>> > >
>> > > Is this what you hand in mind Itamar?
>> >
>> > --
>> > Gethin Liddell
>> > Ubiquity Software Corporation
>> >
>> > http://www.ubiquity.net
>> > mailto:gethin@ubiquity.net
>> >
>> > _______________________________________________
>> > SIP mailing list
>> > SIP@lists.bell-labs.com
>> > http://lists.bell-labs.com/mailman/listinfo/sip
>>
>> --
>> M.Ranganathan
>> NIST Advanced Networking Technologies Group,
>> 100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899.
>> Tel: 301 975 3664 Fax: 301 590 0932
>>
>> Hfæj)b? b²Ô^>X¬¶ÆÞ-YZnÇ(sm§ÿåSËlmée*¦ìr?¿?¨¥?©ÿ-+-SwèþÈ©
>

--
M.Ranganathan
NIST Advanced Networking Technologies Group,
100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899.
Tel: 301 975 3664 Fax: 301 590 0932

Hfæj)b? b²Ô^>X¬¶ÆÞ-YZnÇ(sm§ÿåSËlmée*¦ìr?¿?¨¥?©ÿ-+-SwèþÈ©

------_=_NextPart_001_01C03931.E3091D60-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 18 14:50:06 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA14621 for ; Wed, 18 Oct 2000 14:50:04 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B475E44338; Wed, 18 Oct 2000 13:50:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from guardian1.tlv.radvision.com (unknown [212.143.185.30]) by lists.bell-labs.com (Postfix) with ESMTP id E948244336 for ; Wed, 18 Oct 2000 13:49:55 -0400 (EDT) Received: from nt-mail.tlv.radvision.com ([172.20.2.100]) by guardian1.tlv.radvision.com (Post.Office MTA v3.5.3 release 223 ID# 0-0U10L2S100V35) with ESMTP id com; Wed, 18 Oct 2000 21:48:39 +0200 Received: by NT-MAIL with Internet Mail Service (5.5.2650.21) id ; Wed, 18 Oct 2000 20:50:00 +0200 Message-ID: From: Itamar Gilad To: "'Chris Harris'" , mranga@nist.gov Cc: sip@lists.bell-labs.com, "'discussion@sipforum.org'" , jainsip@sun.com Subject: RE: [SIPFORUM] Re: [SIP] JAIN SIP Specification MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C03934.37874B30" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 18 Oct 2000 20:49:59 +0200 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_01C03934.37874B30 Content-Type: text/plain; charset="iso-8859-1" If that means moving transaction-related functions to a different API -- sounds good to me. Itamar -----Original Message----- From: Chris Harris [mailto:charris@dynamicsoft.com] Sent: Wed, October 18, 2000 8:20 PM To: mranga@nist.gov Cc: sip@lists.bell-labs.com; 'discussion@sipforum.org'; jainsip@sun.com Subject: Re: [SIPFORUM] Re: [SIP] JAIN SIP Specification I like your suggestion - if an application has to keep track of transactions, lets make it as easy as possible for it. Alternatively we could define an API that sits on top of the current API. Then an application can use whichever level is more appropriate. "M. Ranganathan" wrote: Chris Itamar and others, Here's a suggestion (shoot down if it makes no sense): Would a "reasonable middle ground" be to provide a set of "util api" that manages transaction state mapping. It could be an optional part of the core API spec or just a suggested addendum (if people think this is the right way to go....). I think it does not need to be part of the "stack". I guess what I am pushing for keeping the stack stateless, minimal in implementation complexity and minimal in definition with everything else being moved into the service layer and/or helper classes for common things services may want to do (like mapping transaction state etc.) A minimal implementation does not have to include the helper classes.... Regards, Ranga. Itamar Gilad wrote: Chris, I agree that few SIP applications would like to bother with transaction mapping. This is clearly the responsibility of the stack as is transaction management in general. However in a previous thread you explained that the issue of managing call and transaction state is outside the scope of this API specification, which led me to believe that the goal is to define message-related functionality. I think that injecting transaction keys into the mix is crossing the lines you defined.Regards, Itamar -----Original Message----- From: Chris Harris [ mailto:charris@dynamicsoft.com ] Sent: Wed, October 18, 2000 7:44 PM To: Itamar Gilad Cc: 'Bobby Sardana'; discussion@sipforum.org; mranga@nist.gov; sip@lists.bell-labs.com; jainsip@Sun.COM Subject: Re: [SIPFORUM] Re: [SIP] JAIN SIP Specification Itamar, It is for the very reason that identifying a transaction from a message is not a trivial matter that I wanted to put the transaction handling inside the JainSipProvider. I don't think the spec should just deal with just the message layer. How many people are going to write JAIN SIP applications if they have to implement their own transaction keys? I'd imagine very few. Regards, Chris Itamar Gilad wrote: Hi again Chris,I'd like to re-emphasize what Bobby says below. The JAIN SIP specification presented here seems to deal just with the "message layer" i.e. parsing, encoding, message and message part containers. I'd like to join those who commend the fine and comprehensive work done. However, this layer has nothing to do with transactions and their state. It would be a mistake to rely on it to retain 'transaction-ids' and associate messages to them (please correct me if I'm misinterpreting your meaning). Note that identifying a transaction from a message is not a trivial matter and continuously more message fields are added to the "transaction key" in order to deal with spiraling, merging etc. A more straight-forward approach would be to put this functionality in the "transaction layer" where transaction objects live and make a clean separation between the two layers.Regards Itamar -----Original Message----- From: Bobby Sardana [ mailto:bobby.sardana@mobilerain.com ] Sent: Wed, October 18, 2000 6:39 PM To: discussion@sipforum.org Cc: mranga@nist.gov; sip@lists.bell-labs.com; jainsip@sun.com Subject: Re: [SIPFORUM] Re: [SIP] JAIN SIP Specification Greetings Chris: Just to add a pointer to this thread: Maintaining trasaction state is an application level functionality and *shouldn't* be implemented in the base stack. For applications like state oriented proxy server, the JAIN SIP can provide enough hooks for event delivery but the state has to be maintained by the proxy server. Pleas keep up the good work. It is really appreciated. Regards, Bobby.Sardana@mobilerain.com Chris Harris wrote: "M. Ranganathan" wrote: Hi Chris, Thanks for replying so promptly (I am sure you are flooded with email ). I get one or two :) As you pointed out, I suppose we cannot do away with making Messages into classes because of the tie-in with java events (unfortunately) but I still like the notion of being able to specify interfaces where ever possible. I see where you're coming from alright, and I suppose changing header classes into interfaces, could fit in with Gethin's proposal nicely? I dont quite follow the motivation behind the following design decision (excerpted from your reply): Maybe I've misunderstood what you're saying - but a JAIN SIP implementation is only stateless when it comes to call state. The JainSipProvider implementation must maintain transaction state - it simply exposes a reference to a transaction via the transaction id for the convenience of the JainSipListener. The service does not have total control over transacton state - the stack implementation does. It appears that I have indded mis-understood the architecture. Why should the above be so? Can one not rely on the JainSipListener to keep transaction state also, thereby making the stack simply a way of recognising messages and triggering event handlers on the basis of message type. This would (IMHO) be a cleaner model yet. That way, we can do away with transaction identifiers being passed back and forth and keep all of this information in the handler. ( You may have to extend the architecture somewhat to deal with timeouts and failures so that the handler knows about transaction failure.) In any case, if this is not a viable idea, I would be grateful if you can explain why not (or point me to the portion of the spec that explains why not) so I can get a better understanding. It would be cleaner model, and personally I am in total agreement with you - but it means the application is forced to maintain transaction state, match up headers - which has been said places too much of a burden on applications. How about finding a way to let the application choose whether or not it wants to keep transaction state? Regards, Ranga. Chris Harris wrote: > Hi Ranga, > > Response below... > > Chris > > "M. Ranganathan" wrote: > >> JAIN-SIP is a groovy idea. Hats off to the whole concept and many >> thanks to Chris and >> the JAIN-SIP team for putting together a spec and more flower power >> to them :-) . In >> particular I like the notion of treating UAS, Redirect and Proxy >> servers as merely >> special cases of the general notion of Services and the idea of >> unifying these >> notions with an event mechanism and event handlers. Second, I like >> the idea of >> separation between a stateless event -oriented "stack" and a bunch >> of event >> handlers that are triggered by the stack with all state (including >> transaction >> state) being separated from the event stack via the JAIN-SIP mapping >> layer if you >> will. ( Correct me if I wax poetic but have the wrong >> understanding....) > >> >> >> I hope I will not be viewed as being too critical, but I would >> like to go one step >> further than what Gethin is suggesting. I am all for using >> interfaces as much as >> possible and leaving class hierarchy definitions to implemeters. >> Defining class >> hierarchies almost lays out an implementation and involves >> considerable rework for >> those who have a working java-based stack, but have not used the >> same classes. OK it >> is just a matter of labor to map things to the JAIN-SIP class >> hierarchy but it IS a >> dis-incentive. >> >> 1. Lets use interfaces for all messages rather than actually define >> class >> hierarchies ( yes Chris has pointed out the historical precedent >> behind actually >> defining class hierarchies for messages. IMHO, there has to be a >> more compelling >> reason than that.) > > I suppose all classes could be turned into interfaces, except for the > Message classes which must extend java.util.EventObject to fit into > the JAIN framework. > >> >> >> 2. The tie-in with the JAVA event mechanism has necessitated the >> explicit definition >> of class hierarchies in certain places. Why not use callbacks >> instead and do away >> with this dependency as well? (Basically the same thing as events >> but does not tie >> into the JAVA event mechanism and its associated limitations.) > > Unfortunately the JAIN framework expilicitly relies on the Java Event > model, and I don't think callbacks would be accepted within the JAIN > community. > >> >> >> Nice work and keep it rolling! Thanks. > > Couldn't do it without you guys - thank you! > >> >> >> Ranga. >> >> Gethin Liddell wrote: >> >> > All, >> > >> > This idea of abstraction of the JAIN API is certainly a valid and >> > interesting idea. However, i'm a bit concerened that the proposed >> >> > solution of many different packages, will only seek to complicate >> and >> > maybe enlarge the API. >> > >> > I too see no reason why there is an EntityHeader etc... and i also >> do >> > not see any requirement for an InviteMessage, AckMessage etc... >> > >> > How about if the format of the API remains as is: >> > >> > jain.protocol.ip.sip >> > jain.protocol.ip.sip.header >> > jain.protocol.ip.sip.message >> > >> > except that the messages available in the message package >> consisted of >> > BasicRequest/Response, MinimalRequest/Response etc... where each >> > message is extened in turn (e.g. Minimal extends Basic, Moderate >> > extends Minimal etc...), of course as Chris points out it is not >> hard >> > to see that a combination would be required that is not provided. >> So >> > in the interest of flexibility, it could be possible for the user >> to >> > plug-in to the message class what extra headers it requires. The >> only >> > issue then is that the user will have to use a "public Header >> > getHeader(String headerName)" and then cast the header to their >> desired >> > header type. Either that or create their own Message class >> > (extending the current ones) that simply does the casting >> automatically >> > for them. Then after compiling, run an obfuscator on the code and >> it >> > will automatically extract and only extract the Message, Headers >> and >> > even methods that are used. >> > >> > This then will also cut down on the number of methods in the >> Provider >> > as there will be no need for the sendAck(AckMessage), >> > sendInvite(InviteMessage) etc.. as they would be replaced by the >> > single method sendRequest(RequestMessage). >> > >> > I personally see three arguments for keeping the JAIN SIP stack as >> small >> > as possible: >> > >> > 1) The first is for embedded applications where stack size has to >> be >> > kept to a minimum as memory is at a premium. So if just using the >> >> > Basic message suffices then this will compile and run with a small >> >> > number of classes present from the stack. Don't forget, >> obfuscation >> > will help in extracting only the Messages, Headers and even >> methods >> > required from a jar file but it won't do everything. >> > >> > 2) The second is that users may be put off or confused by the >> sheer >> > size and complexity of the JAIN stack. So if only using the >> > BasicMessage gets them on the first rung of the ladder then it is >> a >> > good starting point and allows them to build up to bigger and >> better >> > things. >> > >> > 3) We also have to consider who is going to implement the JAIN SIP >> >> > stack. If it is indeed overly complicated then no-one or a single >> > vendor may end up implmenting the stack and thus its definition >> and >> > all the hard work that has gone into it is useless. >> > >> > On Mon, 16 Oct 2000, Chris Harris wrote: >> > > Itamar, >> > > >> > > The idea of levelling the API based on what messages, headers >> and response codes >> > > are understood is certainly an interesting one - minimal, basic, >> redirection, >> > > firewall-friendly, negotiation, authentication and "full". >> > > >> > > jain.protocol.ip.sip >> > > jain.protocol.ip.sip.header >> > > jain.protocol.ip.sip.message >> > > >> > > could then become... >> > > >> > > jain.protocol.ip.sip - listener, provider, stack, general >> classes used at all >> > > levels >> > > jain.protocol.ip.sip.header - contains base Header class (and >> requestHeader, >> > > ResponseHeader, EntityHeader, GeneralHeader) >> > > jain.protocol.ip.sip.message - contains base Message class >> > > >> > > jain.protocol.ip.sip.minimal - general classes used only at this >> level and above >> > > >> > > jain.protocol.ip.sip.minimal.header - headers used only at this >> level and above >> > > jain.protocol.ip.sip.minimal.message - messages only used at >> this level and >> > > above >> > > >> > > jain.protocol.ip.sip.basic - general classes used only at this >> level and above >> > > jain.protocol.ip.sip.basic.header - headers used only at this >> level and above >> > > jain.protocol.ip.sip.basic.message - messages used only at this >> level and above >> > > ... >> > > .... >> > > jjain.protocol.ip.sip."full" - general classes only used at this >> level >> > > jain.protocol.ip.sip."full".header - headers used only at this >> level >> > > jain.protocol.ip.sip."full".message - messages used only at this >> level >> > > >> > > The API user could then pick the packages they need - say they >> initially only >> > > want the minimal features, but then realise they need to use >> their application >> > > behind a firewall - then they can simply add the >> firewall-friendly package. The >> > > RFC says "In general, each capability listed builds on the ones >> above it" but it >> > > is not hard to see that firewall-friendly and authentication may >> be desired >> > > without redirection for example. >> > > >> > > Is this what you hand in mind Itamar? >> > >> > -- >> > Gethin Liddell >> > Ubiquity Software Corporation >> > >> > http://www.ubiquity.net >> > mailto:gethin@ubiquity.net >> > >> > _______________________________________________ >> > SIP mailing list >> > SIP@lists.bell-labs.com >> > http://lists.bell-labs.com/mailman/listinfo/sip >> >> -- >> M.Ranganathan >> NIST Advanced Networking Technologies Group, >> 100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899. >> Tel: 301 975 3664 Fax: 301 590 0932 >> >> Hfæj)b? b²Ô^>X¬¶ÆÞ-YZnÇ(sm§ÿåSËlmée*¦ìr?¿?¨¥?©ÿ-+-SwèþÈ© > -- M.Ranganathan NIST Advanced Networking Technologies Group, 100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899. Tel: 301 975 3664 Fax: 301 590 0932 Hfæj)b? b²Ô^>X¬¶ÆÞ-YZnÇ(sm§ÿåSËlmée*¦ìr?¿?¨¥?©ÿ-+-SwèþÈ© -- M.Ranganathan NIST Advanced Networking Technologies Group, 100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899. Tel: 301 975 3664 Fax: 301 590 0932 ------_=_NextPart_001_01C03934.37874B30 Content-Type: text/html; charset="iso-8859-1"
If that means moving transaction-related functions to a different API -- sounds good to me.
 
Itamar
-----Original Message-----
From: Chris Harris [mailto:charris@dynamicsoft.com]
Sent: Wed, October 18, 2000 8:20 PM
To: mranga@nist.gov
Cc: sip@lists.bell-labs.com; 'discussion@sipforum.org'; jainsip@sun.com
Subject: Re: [SIPFORUM] Re: [SIP] JAIN SIP Specification

I like your suggestion - if an application has to keep track of transactions, lets make it as easy as possible for it. Alternatively we could define an API that sits on top of the current API. Then an application can use whichever level is more appropriate.

"M. Ranganathan" wrote:

Chris  Itamar and others,

Here's a suggestion (shoot down if it makes no sense):

Would a  "reasonable middle ground" be to provide a set of  "util api" that manages transaction state mapping.  It could be an optional  part of the  core API spec or just a suggested addendum (if  people think this is the right way to go....).  I think it does not need to be part of the "stack". I  guess what I am  pushing for keeping the stack stateless, minimal  in implementation complexity and minimal in definition with everything else being moved into the service layer and/or helper  classes for common things services may want to do (like mapping transaction state etc.) A minimal implementation does not have to include the helper classes....

Regards,

Ranga.
 

Itamar Gilad wrote:

Chris, I agree that few SIP applications would like to bother with transaction mapping.  This is clearly the responsibility of the stack as is transaction management in general.  However in a previous thread you explained that the issue of managing call and transaction state is outside the scope of this API specification, which led me to believe that the goal is to define message-related functionality. I think that injecting transaction keys into the mix is crossing the lines you defined.Regards,  Itamar
-----Original Message-----
From: Chris Harris [mailto:charris@dynamicsoft.com]
Sent: Wed, October 18, 2000 7:44 PM
To: Itamar Gilad
Cc: 'Bobby Sardana'; discussion@sipforum.org; mranga@nist.gov; sip@lists.bell-labs.com; jainsip@Sun.COM
Subject: Re: [SIPFORUM] Re: [SIP] JAIN SIP Specification
Itamar,

It is for the very reason that identifying a transaction from a message is not a trivial matter that I wanted to put the transaction handling inside the JainSipProvider. I don't think the spec should just deal with just the message layer. How many people are going to write JAIN SIP applications if they have to implement their own transaction keys? I'd imagine very few.

Regards,
Chris

Itamar Gilad wrote:

Hi again Chris,I'd like to re-emphasize what Bobby says below.  The JAIN SIP specification presented here seems to deal just with the "message layer" i.e. parsing, encoding, message and message part containers.  I'd like to join those who commend the fine and comprehensive work done.  However, this layer has nothing to do with transactions and their state.  It would be a mistake to rely on it to retain 'transaction-ids' and associate messages to them (please correct me if I'm misinterpreting your meaning). Note that identifying a transaction from a message is not a trivial matter and continuously more message fields are added to the "transaction key" in order to deal with spiraling, merging etc. A more straight-forward approach would be to put this functionality in the "transaction layer" where transaction objects live and make a clean separation between the two layers.Regards Itamar
-----Original Message-----
From: Bobby Sardana [mailto:bobby.sardana@mobilerain.com]
Sent: Wed, October 18, 2000 6:39 PM
To: discussion@sipforum.org
Cc: mranga@nist.gov; sip@lists.bell-labs.com; jainsip@sun.com
Subject: Re: [SIPFORUM] Re: [SIP] JAIN SIP Specification
 
Greetings Chris:

Just to add a pointer to this thread:

Maintaining trasaction state is an application level functionality and *shouldn't* be implemented in the base stack. For applications like state oriented proxy server, the JAIN SIP can provide enough hooks for event delivery but the state has to be maintained by the proxy server.

Pleas keep up the good work. It is really appreciated.

Regards,

Bobby.Sardana@mobilerain.com

Chris Harris wrote:

"M. Ranganathan" wrote:
Hi Chris,

Thanks for replying so promptly (I am sure you are flooded with email ).

I get one or two :)

As you pointed out, I suppose we cannot do away with making Messages
into classes because of the tie-in with java events (unfortunately) but
I still like the notion of being able to specify  interfaces where ever
possible.
I see where you're coming from alright, and I suppose changing header classes into interfaces, could fit in with Gethin's proposal nicely?

 I dont quite follow  the motivation behind the following design
decision (excerpted from your reply):

Maybe I've misunderstood what you're saying - but a JAIN SIP
implementation is only stateless when it comes to call state. The
JainSipProvider implementation must maintain transaction state - it
simply exposes a reference to a transaction via the transaction id for
the convenience of the JainSipListener. The service does not have total
control over transacton state - the stack implementation does.

It appears that I have indded mis-understood the architecture.  Why
should the above be so? Can one not rely on the JainSipListener to keep
transaction state also, thereby making the stack simply a way of
recognising messages and triggering  event handlers on the basis of
message type. This would (IMHO) be a cleaner model yet.    That way,  we
can do away with transaction identifiers being passed back and forth and
keep all of this information in the handler.  ( You may have to extend
the architecture somewhat to deal with timeouts and failures so that the
handler knows about transaction failure.) In any case, if this is not a
viable idea, I would be grateful if you can explain why not (or point me
to the portion of the spec that explains why not) so I can get a better
understanding.

It would be cleaner model, and personally I am in total agreement with you - but it means the application is forced to maintain transaction state, match up headers - which has been said places too much of a burden on applications. How about finding a way to let the application choose whether or not it wants to keep transaction state?
 

Regards,

Ranga.

Chris Harris wrote:

> Hi Ranga,
>
> Response below...
>
> Chris
>
> "M. Ranganathan" wrote:
>
>> JAIN-SIP is a groovy idea. Hats off to the whole concept and many
>> thanks to Chris and
>> the JAIN-SIP team for putting together a spec and more flower power
>> to them :-) .  In
>> particular I like the notion of treating UAS,  Redirect and Proxy
>> servers as merely
>> special cases of the general notion of Services and  the idea of
>> unifying these
>> notions with an event mechanism and  event handlers.  Second, I like
>> the idea of
>> separation between a  stateless  event -oriented "stack" and a bunch
>> of event
>> handlers that are triggered by the stack with all state (including
>> transaction
>> state) being separated from the event stack via the JAIN-SIP mapping
>> layer if you
>> will.  ( Correct me if I  wax poetic but have the wrong
>> understanding....)
>
>>
>>
>> I hope I  will not be viewed as being too critical,  but I would
>> like to go  one step
>> further than what Gethin is suggesting.   I am all for using
>> interfaces as much as
>> possible and leaving class hierarchy definitions to implemeters.
>> Defining class
>> hierarchies almost lays out an implementation and involves
>> considerable rework for
>> those who have a working java-based stack, but have not used the
>> same classes. OK it
>> is just a matter of labor to map things to the JAIN-SIP class
>> hierarchy but it  IS a
>> dis-incentive.
>>
>> 1. Lets use interfaces for all messages rather than actually define
>> class
>> hierarchies  ( yes Chris has pointed out the historical precedent
>> behind actually
>> defining class hierarchies for messages. IMHO,  there has to be a
>> more compelling
>> reason than that.)
>
> I suppose all classes could be turned into interfaces, except for the
> Message classes which must extend java.util.EventObject to fit into
> the JAIN framework.
>
>>
>>
>> 2. The tie-in with the JAVA event mechanism has necessitated the
>> explicit definition
>> of class hierarchies in certain places.  Why not use callbacks
>> instead and do away
>> with this dependency as well?  (Basically the same thing as events
>> but does not tie
>> into the JAVA event mechanism and its associated limitations.)
>
> Unfortunately the JAIN framework expilicitly relies on the Java Event
> model, and I don't think callbacks would be accepted within the JAIN
> community.
>
>>
>>
>> Nice work and keep it rolling!  Thanks.
>
> Couldn't do it without you guys - thank you!
>
>>
>>
>> Ranga.
>>
>> Gethin Liddell wrote:
>>
>> > All,
>> >
>> > This idea of abstraction of the JAIN API is certainly a valid and
>> > interesting idea.  However, i'm a bit concerened that the proposed
>>
>> > solution of many different packages, will only seek to complicate
>> and
>> > maybe enlarge the API.
>> >
>> > I too see no reason why there is an EntityHeader etc... and i also
>> do
>> > not see any requirement for an InviteMessage, AckMessage etc...
>> >
>> > How about if the format of the API remains as is:
>> >
>> > jain.protocol.ip.sip
>> > jain.protocol.ip.sip.header
>> > jain.protocol.ip.sip.message
>> >
>> > except that the messages available in the message package
>> consisted of
>> > BasicRequest/Response, MinimalRequest/Response etc... where each
>> > message is extened in turn (e.g. Minimal extends Basic, Moderate
>> > extends Minimal etc...), of course as Chris points out it is not
>> hard
>> > to see that a combination would be required that is not provided.
>> So
>> > in the interest of flexibility, it could be possible for the user
>> to
>> > plug-in to the message class what extra headers it requires.  The
>> only
>> > issue then is that the user will have to use a "public Header
>> > getHeader(String headerName)" and then cast the header to their
>> desired
>> > header type. Either that or create their own Message class
>> > (extending the current ones) that simply does the casting
>> automatically
>> > for them.  Then after compiling, run an obfuscator on the code and
>> it
>> > will automatically extract and only extract the Message, Headers
>> and
>> > even methods that are used.
>> >
>> > This then will also cut down on the number of methods in the
>> Provider
>> > as there will be no need for the sendAck(AckMessage),
>> > sendInvite(InviteMessage) etc.. as they would be replaced by the
>> > single method sendRequest(RequestMessage).
>> >
>> > I personally see three arguments for keeping the JAIN SIP stack as
>> small
>> > as possible:
>> >
>> > 1) The first is for embedded applications where stack size has to
>> be
>> > kept to a minimum as memory is at a premium.  So if just using the
>>
>> > Basic message suffices then this will compile and run with a small
>>
>> > number of classes present from the stack.  Don't forget,
>> obfuscation
>> > will help in extracting only the Messages, Headers and even
>> methods
>> > required from a jar file but it won't do everything.
>> >
>> > 2) The second is that users may be put off or confused by the
>> sheer
>> > size and complexity of the JAIN stack.  So if only using the
>> > BasicMessage gets them on the first rung of the ladder then it is
>> a
>> > good starting point and allows them to build up to bigger and
>> better
>> > things.
>> >
>> > 3) We also have to consider who is going to implement the JAIN SIP
>>
>> > stack. If it is indeed overly complicated then no-one or a single
>> > vendor may end up implmenting the stack and thus its definition
>> and
>> > all the hard work that has gone into it is useless.
>> >
>> > On Mon, 16 Oct 2000, Chris Harris wrote:
>> > > Itamar,
>> > >
>> > > The idea of levelling the API based on what messages, headers
>> and response codes
>> > > are understood is certainly an interesting one - minimal, basic,
>> redirection,
>> > > firewall-friendly, negotiation, authentication and "full".
>> > >
>> > > jain.protocol.ip.sip
>> > > jain.protocol.ip.sip.header
>> > > jain.protocol.ip.sip.message
>> > >
>> > > could then become...
>> > >
>> > > jain.protocol.ip.sip - listener, provider, stack, general
>> classes used at all
>> > > levels
>> > > jain.protocol.ip.sip.header - contains base Header class (and
>> requestHeader,
>> > > ResponseHeader, EntityHeader, GeneralHeader)
>> > > jain.protocol.ip.sip.message - contains base Message class
>> > >
>> > > jain.protocol.ip.sip.minimal - general classes used only at this
>> level and above
>> > >
>> > > jain.protocol.ip.sip.minimal.header - headers used only at this
>> level and above
>> > > jain.protocol.ip.sip.minimal.message - messages only used at
>> this level and
>> > > above
>> > >
>> > > jain.protocol.ip.sip.basic - general classes used only at this
>> level and above
>> > > jain.protocol.ip.sip.basic.header - headers used only at this
>> level and above
>> > > jain.protocol.ip.sip.basic.message - messages used only at this
>> level and above
>> > > ...
>> > > ....
>> > > jjain.protocol.ip.sip."full" - general classes only used at this
>> level
>> > > jain.protocol.ip.sip."full".header - headers used only at this
>> level
>> > > jain.protocol.ip.sip."full".message - messages used only at this
>> level
>> > >
>> > > The API user could then pick the packages they need - say they
>> initially only
>> > > want the minimal features, but then realise they need to use
>> their application
>> > > behind a firewall - then they can simply add the
>> firewall-friendly package. The
>> > > RFC says "In general, each capability listed builds on the ones
>> above it" but it
>> > > is not hard to see that firewall-friendly and authentication may
>> be desired
>> > > without redirection for example.
>> > >
>> > > Is this what you hand in mind Itamar?
>> >
>> > --
>> > Gethin Liddell
>> > Ubiquity Software Corporation
>> >
>> > http://www.ubiquity.net
>> > mailto:gethin@ubiquity.net
>> >
>> > _______________________________________________
>> > SIP mailing list
>> > SIP@lists.bell-labs.com
>> > http://lists.bell-labs.com/mailman/listinfo/sip
>>
>> --
>> M.Ranganathan
>> NIST Advanced Networking Technologies Group,
>> 100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899.
>> Tel: 301 975 3664 Fax: 301 590 0932
>>
>> Hfæj)b? b²Ô^>X¬¶ÆÞ-YZnÇ(sm§ÿåSËlmée*¦ìr?¿?¨¥?©ÿ-+-SwèþÈ©
>

--
M.Ranganathan
NIST Advanced Networking Technologies Group,
100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899.
Tel: 301 975 3664 Fax: 301 590 0932

Hfæj)b? b²Ô^>X¬¶ÆÞ-YZnÇ(sm§ÿåSËlmée*¦ìr?¿?¨¥?©ÿ-+-SwèþÈ©

-- 
M.Ranganathan
NIST Advanced Networking Technologies Group,
100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899. 
Tel: 301 975 3664 Fax: 301 590 0932
 
------_=_NextPart_001_01C03934.37874B30-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 18 15:41:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA21949 for ; Wed, 18 Oct 2000 15:41:03 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 240A04436D; Wed, 18 Oct 2000 14:41:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from broadsoft.com (broadsoft.com [161.58.239.68]) by lists.bell-labs.com (Postfix) with ESMTP id AAC5844366 for ; Wed, 18 Oct 2000 14:40:53 -0400 (EDT) Received: from tate ([216.181.56.35]) by broadsoft.com (8.8.8) id PAA88036; Wed, 18 Oct 2000 15:40:48 -0400 (EDT) Message-ID: <11e401c0393b$823a0cb0$3202a8c0@broadsoft.com> From: "Brett Tate" To: "Jonathan Rosenberg" , References: Subject: Reviving a session (formerly Re: [SIP] Session-timer with INFO) 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: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 18 Oct 2000 15:42:10 -0400 Content-Transfer-Encoding: 7bit > Brett also asks if the UAC can ask to not have the session revived if the > UAS isn't active. The question really is, who gets to make that decision? Is > it realy the UAC who should ultimately decide whether a session restart is > appropriate? Since its really the UAS that needs to do it, it seems like it > should be its responsibility to decide. > Thanks for the response. I agree that the UAS could ultimately decide, but a parameter/header to indicate the desire to revive or not revive the session would be extremely useful when making the decision. This parameter/header would be useful for all re-INVITEs. Without the parameter/header, the possibility exists that the entity originally called might unintentionally revive a session to the original caller. Thus assuming calling party pays, the wrong party may be billed for it. A 3pcc/B2BUA may be the entity sending re-INVITEs to the call-legs on both sides. Without the parameter/header, the 3pcc/B2BUA might unintentionally re-establish a released call between 2 subscribers. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 18 15:47:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA22649 for ; Wed, 18 Oct 2000 15:47:03 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A57C044393; Wed, 18 Oct 2000 14:47:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ns1.comversens.com (ns1.comversens.com [63.64.185.10]) by lists.bell-labs.com (Postfix) with ESMTP id EB3EA44390 for ; Wed, 18 Oct 2000 14:46:12 -0400 (EDT) Received: from mail-bridge.btrd.bostontechnology.com (host.comversens.com [63.64.185.2]) by ns1.comversens.com (8.9.1b+Sun/8.9.1) with ESMTP id PAA06012 for ; Wed, 18 Oct 2000 15:46:56 -0400 (EDT) Received: by mail-bridge.btrd.bostontechnology.com with Internet Mail Service (5.5.2652.78) id ; Wed, 18 Oct 2000 15:44:21 -0400 Message-ID: <35A7D40B978CD311AF05002048404D3401F2BA43@wm2.btrd.bostontechnology.com> From: "Oughton, Andre" To: "'sip@lists.bell-labs.com'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] un-subscribe Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 18 Oct 2000 15:43:36 -0400 un-subscribe _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 18 18:30:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA11852 for ; Wed, 18 Oct 2000 18:30:04 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9E1C044337; Wed, 18 Oct 2000 17:30:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id CBEE044336 for ; Wed, 18 Oct 2000 17:29:38 -0400 (EDT) Received: from CINQUECENTO ([63.110.3.156]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with SMTP id SAA02461; Wed, 18 Oct 2000 18:31:37 -0400 (EDT) From: "Robert Sparks" To: "Christer Holmberg" , Subject: RE: [SIP] Contiguos CSeq number Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal In-Reply-To: <39EBE9FD.460BB9D9@lmf.ericsson.se> Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 18 Oct 2000 17:26:50 -0500 Content-Transfer-Encoding: 7bit All a receiving UA can count on is strictly increasing CSeqs. It must not care about gaps. Consider UA A trying to send requests to UA B through a Proxy that challenges every request. UA B will only see every other CSeq value. Emitting contiguous numbers helps ensure there is a large CSeq space (since they cannot wrap) and helps with debugging :). RjS > -----Original Message----- > From: sip-admin@lists.bell-labs.com > [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Christer Holmberg > Sent: Tuesday, October 17, 2000 12:56 AM > To: sip@lists.bell-labs.com > Subject: [SIP] Contiguos CSeq number > > > > Hi, > > I have a question about the CSeq number value. > > > Consider the following case: > > A UAC sends a request to a UAS using CSeq=1. > > The UAC then sends another request to the same UAS using CSeq=2. > However, for some reason the UAS never gets the request. It may, for > example, be terminated by an intermediate proxy, sending a response to > it, or it may be cancelled before it reaches the UAS. > > After that, the UAC sends a third request, using CSeq=3, to the UAS. > > So, the UAS will receive two requests, the first and the third, but not > the second. > > Chapter 6.20 in the RFCbis says that the CSeq number must be contiguous. > However, in this case the UAS will never receive the second request. > Should it "wait" for it (it will never arrive...) or what is the purpose > of the line in the RFCbis? > > Regards, > > Christer Holmberg > Ericsson Finland _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Oct 19 01:51:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA15816 for ; Thu, 19 Oct 2000 01:51:02 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id BC85544337; Thu, 19 Oct 2000 00:51:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 80CDB44336 for ; Thu, 19 Oct 2000 00:50:11 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA04155; Thu, 19 Oct 2000 01:52:15 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <4WS2X4C7>; Thu, 19 Oct 2000 01:46:16 -0400 Message-ID: From: Jonathan Rosenberg To: "Schmidlin, David" , "'sip@lists.bell-labs.com'" Subject: RE: [SIP] Overviews of How to test SIP. MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 19 Oct 2000 01:46:13 -0400 Try: http://www.cs.columbia.edu/~hgs/sip/bakeoff/ -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com > -----Original Message----- > From: Schmidlin, David [mailto:david.schmidlin@intel.com] > Sent: Wednesday, October 18, 2000 1:27 PM > To: 'sip@lists.bell-labs.com' > Subject: [SIP] Overviews of How to test SIP. > > > Does any one know of good doc's that describe > methods on how to test SIP? > > Thanks, > Dave > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Oct 19 02:32:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA27993 for ; Thu, 19 Oct 2000 02:32:03 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9377444337; Thu, 19 Oct 2000 01:32:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from alvin.loniis.spb.su (gw1.loniis.spb.su [195.201.37.253]) by lists.bell-labs.com (Postfix) with ESMTP id 43A9944336 for ; Thu, 19 Oct 2000 01:31:01 -0400 (EDT) Received: from rts.nio1.loniis (rts.loniis.ru [195.201.37.111]) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id e9J6UnK24437 for ; Thu, 19 Oct 2000 10:30:49 +0400 (MSD) Received: from Vova (vova.rts.nio1.loniis [192.168.100.180]) by rts.nio1.loniis (Postfix) with SMTP id 14FE8F3 for ; Thu, 19 Oct 2000 10:35:25 +0400 (MSD) Message-ID: <012601c03996$2f6e2880$b464a8c0@rts.nio1.loniis> From: "Samorezov Vladimir" To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0123_01C039B7.B63503E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Subject: [SIP] (no subject) Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 19 Oct 2000 10:31:16 +0400 This is a multi-part message in MIME format. ------=_NextPart_000_0123_01C039B7.B63503E0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable Hello, All! Could you say me where can I find information about existent SIP = networks? Realization, architecture, of general, how do it work? Or is = it dream and it doesn't exist now! =20 Thanks, Samorezov Vladimir. ------=_NextPart_000_0123_01C039B7.B63503E0 Content-Type: text/html; charset="koi8-r" Content-Transfer-Encoding: quoted-printable
Hello, All!
Could you say me where can I = find=20 information about existent SIP networks? Realization, architecture, = of=20 general, how do it work? Or is it dream and it doesn't = exist=20 now!  
Thanks, Samorezov=20 Vladimir.
------=_NextPart_000_0123_01C039B7.B63503E0-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Oct 19 04:48:00 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA14988 for ; Thu, 19 Oct 2000 04:48:00 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7F90744337; Thu, 19 Oct 2000 03:48:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from drago1.ubiquity.net (unknown [194.202.146.92]) by lists.bell-labs.com (Postfix) with SMTP id 42E2644336 for ; Thu, 19 Oct 2000 03:47:31 -0400 (EDT) Received: from gecko.ubiquity.co.uk by drago1.ubiquity.net via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 19 Oct 2000 08:48:00 UT Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id JAA19316; Thu, 19 Oct 2000 09:45:30 +0100 (BST) Message-ID: <39EEB4AA.E0A0682F@ubiquity.net> From: Neil Deason Organization: Ubiquity Software Corporation Limited X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Samorezov Vladimir Cc: sip@lists.bell-labs.com Subject: Re: [SIP] (no subject) References: <012601c03996$2f6e2880$b464a8c0@rts.nio1.loniis> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 19 Oct 2000 09:45:30 +0100 Content-Transfer-Encoding: 7bit See: http://www.cs.columbia.edu/~hgs/sip/ This includes information about Public SIP Servers, such as the one at www.sipcenter.com, that you can use today. Cheers, Neil -- Ubiquity Software Corporation, UK http://www.ubiquity.net > Samorezov Vladimir wrote: > > Hello, All! > Could you say me where can I find information about existent SIP networks? Realization, architecture, of general, how do it work? Or is it dream and it doesn't exist now! > Thanks, Samorezov Vladimir. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Oct 19 05:02:00 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA16474 for ; Thu, 19 Oct 2000 05:02:00 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 968E644337; Thu, 19 Oct 2000 04:02:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from drago1.ubiquity.net (unknown [194.202.146.92]) by lists.bell-labs.com (Postfix) with SMTP id 61D5444336 for ; Thu, 19 Oct 2000 04:01:15 -0400 (EDT) Received: from gecko.ubiquity.co.uk by drago1.ubiquity.net via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 19 Oct 2000 09:01:44 UT Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id JAA23175; Thu, 19 Oct 2000 09:59:37 +0100 (BST) Message-ID: <39EEB7F9.7BEFC45C@ubiquity.net> From: Neil Deason Organization: Ubiquity Software Corporation Limited X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] Error in draft-ietf-sip-call-flows-01.txt Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 19 Oct 2000 09:59:37 +0100 Content-Transfer-Encoding: 7bit One of the changes made in draft 01 was to correct all registrations to have same Call-ID over an authentication challenge. In sections 2.1.1 and 2.2.1 I think. However the CSeqs were not incremented in the second REGISTER requests carrying the authentication credentials sent by the Clients. This means the authentication would always fail as the second REGISTER is actually isomorphic to the first and would receive the same 401 Unauthorized response. Corrected call flows for 2.1.1 and 2.2.1 are reproduced below. Cheers, Neil -- Ubiquity Software Corporation, UK http://www.ubiquity.net -- 2.1.1 SIP Client New Registration F1 REGISTER B -> SIP Server REGISTER sip:ss2.wcom.com SIP/2.0 Via: SIP/2.0/UDP there.com:5060 From: LittleGuy To: LittleGuy Call-ID: 123456789@here.com CSeq: 1 REGISTER Contact: LittleGuy Contact: sip:+1-972-555-2222@gw1.wcom.com;user=phone Contact: tel:+1-972-555-2222 Content-Length: 0 F2 401 Unauthorized SIP Server -> User B SIP/2.0 401 Unauthorized Via: SIP/2.0/UDP there.com:5060 From: LittleGuy To: LittleGuy Call-ID: 123456789@here.com CSeq: 1 REGISTER WWW-Authenticate: Digest realm="MCI WorldCom SIP", domain="wcom.com", nonce="ea9c8e88df84f1cec4341ae6cbe5a359", opaque="", stale="FALSE", algorithm="MD5" Content-Length: 0 F3 REGISTER B -> SIP Server REGISTER sip:ss2.wcom.com SIP/2.0 Via: SIP/2.0/UDP there.com:5060 From: LittleGuy To: LittleGuy Call-ID: 123456789@here.com CSeq: 2 REGISTER Contact: LittleGuy Contact: sip:+1-972-555-2222@gw1.wcom.com;user=phone Contact: tel:+1-972-555-2222 Authorization:Digest username="UserB", realm="MCI WorldCom SIP", nonce="ea9c8e88df84f1cec4341ae6cbe5a359", opaque="", uri="sip:ss2.wcom.com", response="dfe56131d1958046689cd83306477ecc" Content-Length: 0 F4 200 OK SIP Server -> B SIP/2.0 200 OK Via: SIP/2.0/UDP there.com:5060 From: LittleGuy To: LittleGuy Call-ID: 123456789@here.com CSeq: 2 REGISTER Contact: LittleGuy Contact: sip:+1-972-555-2222@gw1.wcom.com;user=phone Contact: tel:+1-972-555-2222 Content-Length: 0 2.2.1 Unsuccessful SIP registration F1 REGISTER B -> SIP Server REGISTER sip:ss2.wcom.com SIP/2.0 Via: SIP/2.0/UDP there.com:5060 From: LittleGuy To: LittleGuy Call-ID: 123456789@here.com CSeq: 1 REGISTER Contact: LittleGuy Contact: sip:+1-972-555-2222@gw1.wcom.com;user=phone Contact: tel:+1-972-555-2222 Content-Length: 0 F2 Unauthorized SIP Server -> User B SIP/2.0 401 Unauthorized Via: SIP/2.0/UDP there.com:5060 From: LittleGuy To: LittleGuy Call-ID: 123456789@here.com CSeq: 1 REGISTER WWW-Authenticate: Digest realm="MCI WorldCom SIP", domain="wcom.com", nonce="f1cec4341ae6ca9c8e88df84be55a359", opaque="", stale="FALSE", algorithm="MD5" Content-Length: 0 F3 REGISTER B -> SIP Server REGISTER sip:ss2.wcom.com SIP/2.0 Via: SIP/2.0/UDP there.com:5060 From: LittleGuy To: LittleGuy Call-ID: 123456789@here.com CSeq: 2 REGISTER Contact: LittleGuy Contact: sip:+1-972-555-2222@gw1.wcom.com;user=phone Contact: tel:+1-972-555-2222 Authorization:Digest username="UserB", realm="MCI WorldCom SIP", nonce="f1cec4341ae6ca9c8e88df84be55a359", opaque="", uri="sip:ss2.wcom.com", response="61f8470ceb87d7ebf508220214ed438b" Content-Length: 0 /* The response above encodes the incorrect password _IForgotIt_ */ F4 401 Unauthorized SIP Server -> User B SIP/2.0 401 Unauthorized Via: SIP/2.0/UDP there.com:5060 From: LittleGuy To: LittleGuy Call-ID: 123456789@here.com CSeq: 2 REGISTER WWW-Authenticate: Digest realm="MCI WorldCom SIP", domain="wcom.com", nonce="84f1c1ae6cbe5ua9c8e88dfa3ecm3459", opaque="", stale="FALSE", algorithm="MD5" Content-Length: 0 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Oct 19 05:34:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA19849 for ; Thu, 19 Oct 2000 05:34:00 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E153144337; Thu, 19 Oct 2000 04:34:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from gollum.axion.bt.co.uk (gollum.axion.bt.co.uk [132.146.17.41]) by lists.bell-labs.com (Postfix) with ESMTP id 4B6D944336 for ; Thu, 19 Oct 2000 04:33:05 -0400 (EDT) Received: from chqlubnt02.lon.bt.com by gollum (local) with ESMTP; Thu, 19 Oct 2000 10:29:20 +0100 Received: by chqlubnt02.lon.bt.com with Internet Mail Service (5.5.2652.35) id <4MC6ALA2>; Thu, 19 Oct 2000 10:27:55 +0100 Message-ID: From: clive.dellard@bt.com To: jdrosen@dynamicsoft.com Cc: byerly@cisco.com, stlevy@cisco.com, jryang@cisco.com, christer.holmberg@lmf.ericsson.se, sip@lists.bell-labs.com Subject: RE: [SIP] From header to ISUP CgPN mapping MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: text/plain Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 19 Oct 2000 10:27:53 +0100 Jonathan, I understand your reluctance to add changes, however, IMHO I do not see that it is bogus for a call originating in an IP network to be able to provide a calling address appropriate for the terminating network. So if the call remains in the IP environment a SIP address is provided but if the call terminates in the PSTN an E.164 number is delivered as the calling address. I would welcome suggestions on how to resolve this issue. Regards, Clive > -----Original Message----- > From: Jonathan Rosenberg [SMTP:jdrosen@dynamicsoft.com] > Sent: Wednesday, October 18, 2000 8:18 AM > To: Christer Holmberg; sip@lists.bell-labs.com > Cc: Bryan Byerly; stlevy@cisco.com; jryang@cisco.com > Subject: RE: [SIP] From header to ISUP CgPN mapping > > > > > > > -----Original Message----- > > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > > Sent: Tuesday, October 17, 2000 5:00 PM > > To: sip@lists.bell-labs.com > > Cc: Bryan Byerly; stlevy@cisco.com; jryang@cisco.com > > Subject: Re: [SIP] From header to ISUP CgPN mapping > > > > > > > > Hi, > > > > >ok. Thanks for clearing that up. > > > > > >A follow-up question: > > >How does/does Also-From header differ from the Remote-Party-Id header > > >(draft-dcsgroup-sip-privacy-02.txt)? > > > > Well, it could perhaps be possible to use that header, but the whole > > concept of that draft is a little different than just adding an > > telephone number alias to the caller, and by supporting it I guess you > > would have to do more implementation than necessary for this specfic > > need. Also, depending on what is put in Remote-Party-Id header, it is > > not even sure it would solve the problem. > > I agree. Remote-Party-ID is supposed to be an address that the network has > "verified" to be the actual address of the originator. It is even stripped > if verification cannot take place. THis seems a bit at odds with the > desired > function here. > > That said, I still do not understand this need for YAI (yet another > identifier). This previous motivation involving the termination in the > PSTN > or IP network is totally bogus. At this point, I am very, very, very > reluctant to add new stuff without serious justification. > > -Jonathan R. > > --- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Oct 19 06:11:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA23764 for ; Thu, 19 Oct 2000 06:11:03 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B5F2E44342; Thu, 19 Oct 2000 05:11:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 1FAA544337 for ; Thu, 19 Oct 2000 05:10:42 -0400 (EDT) Received: from dynamicsoft.com ([212.120.151.74]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id GAA04594; Thu, 19 Oct 2000 06:12:40 -0400 (EDT) Message-ID: <39EEC8A9.A7D6BB66@dynamicsoft.com> From: Chris Harris Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Cc: discussion@sipforum.org, jainsip@Sun.COM Subject: Re: [SIPFORUM] Re: [SIP] JAIN SIP Specification References: Content-Type: multipart/alternative; boundary="------------722B6227511445D449FA3502" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 19 Oct 2000 11:10:49 +0100 --------------722B6227511445D449FA3502 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi Itamar, I can't really think of any applications other than a stateless proxy that don't care about transactions. And since stateless proxies are really just SIP routers and need maximum performance, I can't really see anyone implementing them with JAIN SIP. I think any application that does anything interesting needs to know about transactions, so the the JAIN SIP API should include some means of identifying transactions or transaction control. But this has to fit in with the Listener/Provider event model, so we can't hand a Listener a transaction object that they can work with directly - we need to give an application access to transactions through the Provider. I thought a transaction id would be the simplest way to achieve this. Do you have any suggestions for improving transaction control for the event model? Chris Itamar Gilad wrote: > No, that's not it. The application uses a stack to do all of this. > The stack should export a message-related API like the one defined in > the JAIN SIP specification you presented. The stack should also > export interfaces for Call control and Transaction control. It seems > more logical for the application to use a transaction object which > handles messaging and notifies it whenever a message belonging to this > transaction is received rather then having a message object that tells > it which transaction it belongs too. Stateless proxies for example > would use only the message layer and they don't care at all about > transactions. I'm Sorry to be so picky, but I just think that this > makes for a cleaner design both in the application and in the stack. > Our experience with our SIP stack proves that this model works > fine.Itamar > > -----Original Message----- > From: Chris Harris [mailto:charris@dynamicsoft.com] > Sent: Wed, October 18, 2000 8:18 PM > To: discussion@sipforum.org > Cc: Itamar Gilad; 'Bobby Sardana'; mranga@nist.gov; > sip@lists.bell-labs.com; jainsip@Sun.COM > Subject: Re: [SIPFORUM] Re: [SIP] JAIN SIP Specification > > OK - so if an application just sends a message to the > Provider, it has to check all response messages to see if > they match - this is so messy for an application. What if a > response message never arrives - how should the Provider > inform the application of a timeout? Call a timeout method > and pass the request message back? > > Itamar Gilad wrote: > > > Chris, I agree that few SIP applications would like to > > bother with transaction mapping. This is clearly the > > responsibility of the stack as is transaction management > > in general. However in a previous thread you explained > > that the issue of managing call and transaction state is > > outside the scope of this API specification, which led me > > to believe that the goal is to define message-related > > functionality. I think that injecting transaction keys > > into the mix is crossing the lines you defined. Regards, > > Itamar > > > > -----Original Message----- > > From: Chris Harris > > [mailto:charris@dynamicsoft.com] > > Sent: Wed, October 18, 2000 7:44 PM > > To: Itamar Gilad > > Cc: 'Bobby Sardana'; discussion@sipforum.org; > > mranga@nist.gov; sip@lists.bell-labs.com; > > jainsip@Sun.COM > > Subject: Re: [SIPFORUM] Re: [SIP] JAIN SIP > > Specification > > Itamar, > > > > It is for the very reason that identifying a > > transaction from a message is not a trivial > > matter that I wanted to put the transaction > > handling inside the JainSipProvider. I don't > > think the spec should just deal with just the > > message layer. How many people are going to > > write JAIN SIP applications if they have to > > implement their own transaction keys? I'd > > imagine very few. > > > > Regards, > > Chris > > > > Itamar Gilad wrote: > > > > > Hi again Chris,I'd like to re-emphasize what > > > Bobby says below. The JAIN SIP specification > > > presented here seems to deal just with the > > > "message layer" i.e. parsing, encoding, message > > > and message part containers. I'd like to join > > > those who commend the fine and comprehensive > > > work done. However, this layer has nothing to > > > do with transactions and their state. It would > > > be a mistake to rely on it to retain > > > 'transaction-ids' and associate messages to > > > them (please correct me if I'm misinterpreting > > > your meaning). Note that identifying a > > > transaction from a message is not a trivial > > > matter and continuously more message fields are > > > added to the "transaction key" in order to deal > > > with spiraling, merging etc. A more > > > straight-forward approach would be to put this > > > functionality in the "transaction layer" where > > > transaction objects live and make a clean > > > separation between the two layers.Regards > > > Itamar > > > -----Original Message----- > > > From: Bobby Sardana > > > [mailto:bobby.sardana@mobilerain.com] > > > Sent: Wed, October 18, 2000 6:39 PM > > > To: discussion@sipforum.org > > > Cc: mranga@nist.gov; sip@lists.bell-labs.com; > > > jainsip@sun.com > > > Subject: Re: [SIPFORUM] Re: [SIP] JAIN SIP > > > Specification > > > > > > > > > Greetings Chris: > > > > > > Just to add a pointer to this thread: > > > > > > Maintaining trasaction state is an > > > application level functionality and > > > *shouldn't* be implemented in the > > > base stack. For applications like > > > state oriented proxy server, the JAIN > > > SIP can provide enough hooks for > > > event delivery but the state has to > > > be maintained by the proxy server. > > > > > > Pleas keep up the good work. It is > > > really appreciated. > > > > > > Regards, > > > > > > Bobby.Sardana@mobilerain.com > > > > > > Chris Harris wrote: > > > > > > > "M. Ranganathan" wrote: > > > > > > > > > Hi Chris, > > > > > > > > > > Thanks for replying so promptly > > > > > (I am sure you are flooded with > > > > > email ). > > > > > > > > I get one or two :) > > > > > > > > > > > > > > As you pointed out, I suppose we > > > > > cannot do away with making > > > > > Messages > > > > > into classes because of the > > > > > tie-in with java events > > > > > (unfortunately) but > > > > > I still like the notion of being > > > > > able to specify interfaces where > > > > > ever > > > > > possible. > > > > > > > > I see where you're coming from > > > > alright, and I suppose changing > > > > header classes into interfaces, > > > > could fit in with Gethin's proposal > > > > nicely? > > > > > > > > > > > > > > I dont quite follow the > > > > > motivation behind the following > > > > > design > > > > > decision (excerpted from your > > > > > reply): > > > > > > > > > > Maybe I've misunderstood what > > > > > you're saying - but a JAIN SIP > > > > > implementation is only stateless > > > > > when it comes to call state. The > > > > > JainSipProvider implementation > > > > > must maintain transaction state - > > > > > it > > > > > simply exposes a reference to a > > > > > transaction via the transaction > > > > > id for > > > > > the convenience of the > > > > > JainSipListener. The service does > > > > > not have total > > > > > control over transacton state - > > > > > the stack implementation does. > > > > > > > > > > It appears that I have indded > > > > > mis-understood the architecture. > > > > > Why > > > > > should the above be so? Can one > > > > > not rely on the JainSipListener > > > > > to keep > > > > > transaction state also, thereby > > > > > making the stack simply a way of > > > > > recognising messages and > > > > > triggering event handlers on the > > > > > basis of > > > > > message type. This would (IMHO) > > > > > be a cleaner model yet. That > > > > > way, we > > > > > can do away with transaction > > > > > identifiers being passed back and > > > > > forth and > > > > > keep all of this information in > > > > > the handler. ( You may have to > > > > > extend > > > > > the architecture somewhat to deal > > > > > with timeouts and failures so > > > > > that the > > > > > handler knows about transaction > > > > > failure.) In any case, if this is > > > > > not a > > > > > viable idea, I would be grateful > > > > > if you can explain why not (or > > > > > point me > > > > > to the portion of the spec that > > > > > explains why not) so I can get a > > > > > better > > > > > understanding. > > > > > > > > It would be cleaner model, and > > > > personally I am in total agreement > > > > with you - but it means the > > > > application is forced to maintain > > > > transaction state, match up headers > > > > - which has been said places too > > > > much of a burden on applications. > > > > How about finding a way to let the > > > > application choose whether or not > > > > it wants to keep transaction state? > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > Ranga. > > > > > > > > > > Chris Harris wrote: > > > > > > > > > > > Hi Ranga, > > > > > > > > > > > > Response below... > > > > > > > > > > > > Chris > > > > > > > > > > > > "M. Ranganathan" wrote: > > > > > > > > > > > >> JAIN-SIP is a groovy idea. > > > > > Hats off to the whole concept and > > > > > many > > > > > >> thanks to Chris and > > > > > >> the JAIN-SIP team for putting > > > > > together a spec and more flower > > > > > power > > > > > >> to them :-) . In > > > > > >> particular I like the notion > > > > > of treating UAS, Redirect and > > > > > Proxy > > > > > >> servers as merely > > > > > >> special cases of the general > > > > > notion of Services and the idea > > > > > of > > > > > >> unifying these > > > > > >> notions with an event > > > > > mechanism and event handlers. > > > > > Second, I like > > > > > >> the idea of > > > > > >> separation between a > > > > > stateless event -oriented > > > > > "stack" and a bunch > > > > > >> of event > > > > > >> handlers that are triggered by > > > > > the stack with all state > > > > > (including > > > > > >> transaction > > > > > >> state) being separated from > > > > > the event stack via the JAIN-SIP > > > > > mapping > > > > > >> layer if you > > > > > >> will. ( Correct me if I wax > > > > > poetic but have the wrong > > > > > >> understanding....) > > > > > > > > > > > >> > > > > > >> > > > > > >> I hope I will not be viewed > > > > > as being too critical, but I > > > > > would > > > > > >> like to go one step > > > > > >> further than what Gethin is > > > > > suggesting. I am all for using > > > > > >> interfaces as much as > > > > > >> possible and leaving class > > > > > hierarchy definitions to > > > > > implemeters. > > > > > >> Defining class > > > > > >> hierarchies almost lays out an > > > > > implementation and involves > > > > > >> considerable rework for > > > > > >> those who have a working > > > > > java-based stack, but have not > > > > > used the > > > > > >> same classes. OK it > > > > > >> is just a matter of labor to > > > > > map things to the JAIN-SIP class > > > > > >> hierarchy but it IS a > > > > > >> dis-incentive. > > > > > >> > > > > > >> 1. Lets use interfaces for all > > > > > messages rather than actually > > > > > define > > > > > >> class > > > > > >> hierarchies ( yes Chris has > > > > > pointed out the historical > > > > > precedent > > > > > >> behind actually > > > > > >> defining class hierarchies for > > > > > messages. IMHO, there has to be > > > > > a > > > > > >> more compelling > > > > > >> reason than that.) > > > > > > > > > > > > I suppose all classes could be > > > > > turned into interfaces, except > > > > > for the > > > > > > Message classes which must > > > > > extend java.util.EventObject to > > > > > fit into > > > > > > the JAIN framework. > > > > > > > > > > > >> > > > > > >> > > > > > >> 2. The tie-in with the JAVA > > > > > event mechanism has necessitated > > > > > the > > > > > >> explicit definition > > > > > >> of class hierarchies in > > > > > certain places. Why not use > > > > > callbacks > > > > > >> instead and do away > > > > > >> with this dependency as well? > > > > > (Basically the same thing as > > > > > events > > > > > >> but does not tie > > > > > >> into the JAVA event mechanism > > > > > and its associated limitations.) > > > > > > > > > > > > Unfortunately the JAIN > > > > > framework expilicitly relies on > > > > > the Java Event > > > > > > model, and I don't think > > > > > callbacks would be accepted > > > > > within the JAIN > > > > > > community. > > > > > > > > > > > >> > > > > > >> > > > > > >> Nice work and keep it > > > > > rolling! Thanks. > > > > > > > > > > > > Couldn't do it without you guys > > > > > - thank you! > > > > > > > > > > > >> > > > > > >> > > > > > >> Ranga. > > > > > >> > > > > > >> Gethin Liddell wrote: > > > > > >> > > > > > >> > All, > > > > > >> > > > > > > >> > This idea of abstraction of > > > > > the JAIN API is certainly a valid > > > > > and > > > > > >> > interesting idea. However, > > > > > i'm a bit concerened that the > > > > > proposed > > > > > >> > > > > > >> > solution of many different > > > > > packages, will only seek to > > > > > complicate > > > > > >> and > > > > > >> > maybe enlarge the API. > > > > > >> > > > > > > >> > I too see no reason why > > > > > there is an EntityHeader etc... > > > > > and i also > > > > > >> do > > > > > >> > not see any requirement for > > > > > an InviteMessage, AckMessage > > > > > etc... > > > > > >> > > > > > > >> > How about if the format of > > > > > the API remains as is: > > > > > >> > > > > > > >> > jain.protocol.ip.sip > > > > > >> > jain.protocol.ip.sip.header > > > > > >> > jain.protocol.ip.sip.message > > > > > > > > > > >> > > > > > > >> > except that the messages > > > > > available in the message package > > > > > >> consisted of > > > > > >> > BasicRequest/Response, > > > > > MinimalRequest/Response etc... > > > > > where each > > > > > >> > message is extened in turn > > > > > (e.g. Minimal extends Basic, > > > > > Moderate > > > > > >> > extends Minimal etc...), of > > > > > course as Chris points out it is > > > > > not > > > > > >> hard > > > > > >> > to see that a combination > > > > > would be required that is not > > > > > provided. > > > > > >> So > > > > > >> > in the interest of > > > > > flexibility, it could be possible > > > > > for the user > > > > > >> to > > > > > >> > plug-in to the message class > > > > > what extra headers it requires. > > > > > The > > > > > >> only > > > > > >> > issue then is that the user > > > > > will have to use a "public Header > > > > > > > > > > >> > getHeader(String > > > > > headerName)" and then cast the > > > > > header to their > > > > > >> desired > > > > > >> > header type. Either that or > > > > > create their own Message class > > > > > >> > (extending the current ones) > > > > > that simply does the casting > > > > > >> automatically > > > > > >> > for them. Then after > > > > > compiling, run an obfuscator on > > > > > the code and > > > > > >> it > > > > > >> > will automatically extract > > > > > and only extract the Message, > > > > > Headers > > > > > >> and > > > > > >> > even methods that are used. > > > > > >> > > > > > > >> > This then will also cut down > > > > > on the number of methods in the > > > > > >> Provider > > > > > >> > as there will be no need for > > > > > the sendAck(AckMessage), > > > > > >> > sendInvite(InviteMessage) > > > > > etc.. as they would be replaced > > > > > by the > > > > > >> > single method > > > > > sendRequest(RequestMessage). > > > > > >> > > > > > > >> > I personally see three > > > > > arguments for keeping the JAIN > > > > > SIP stack as > > > > > >> small > > > > > >> > as possible: > > > > > >> > > > > > > >> > 1) The first is for embedded > > > > > applications where stack size has > > > > > to > > > > > >> be > > > > > >> > kept to a minimum as memory > > > > > is at a premium. So if just > > > > > using the > > > > > >> > > > > > >> > Basic message suffices then > > > > > this will compile and run with a > > > > > small > > > > > >> > > > > > >> > number of classes present > > > > > from the stack. Don't forget, > > > > > >> obfuscation > > > > > >> > will help in extracting only > > > > > the Messages, Headers and even > > > > > >> methods > > > > > >> > required from a jar file but > > > > > it won't do everything. > > > > > >> > > > > > > >> > 2) The second is that users > > > > > may be put off or confused by the > > > > > > > > > > >> sheer > > > > > >> > size and complexity of the > > > > > JAIN stack. So if only using the > > > > > > > > > > >> > BasicMessage gets them on > > > > > the first rung of the ladder then > > > > > it is > > > > > >> a > > > > > >> > good starting point and > > > > > allows them to build up to bigger > > > > > and > > > > > >> better > > > > > >> > things. > > > > > >> > > > > > > >> > 3) We also have to consider > > > > > who is going to implement the > > > > > JAIN SIP > > > > > >> > > > > > >> > stack. If it is indeed > > > > > overly complicated then no-one or > > > > > a single > > > > > >> > vendor may end up > > > > > implmenting the stack and thus > > > > > its definition > > > > > >> and > > > > > >> > all the hard work that has > > > > > gone into it is useless. > > > > > >> > > > > > > >> > On Mon, 16 Oct 2000, Chris > > > > > Harris wrote: > > > > > >> > > Itamar, > > > > > >> > > > > > > > >> > > The idea of levelling the > > > > > API based on what messages, > > > > > headers > > > > > >> and response codes > > > > > >> > > are understood is > > > > > certainly an interesting one - > > > > > minimal, basic, > > > > > >> redirection, > > > > > >> > > firewall-friendly, > > > > > negotiation, authentication and > > > > > "full". > > > > > >> > > > > > > > >> > > jain.protocol.ip.sip > > > > > >> > > > > > > > jain.protocol.ip.sip.header > > > > > >> > > > > > > > jain.protocol.ip.sip.message > > > > > >> > > > > > > > >> > > could then become... > > > > > >> > > > > > > > >> > > jain.protocol.ip.sip - > > > > > listener, provider, stack, > > > > > general > > > > > >> classes used at all > > > > > >> > > levels > > > > > >> > > > > > > > jain.protocol.ip.sip.header - > > > > > contains base Header class (and > > > > > >> requestHeader, > > > > > >> > > ResponseHeader, > > > > > EntityHeader, GeneralHeader) > > > > > >> > > > > > > > jain.protocol.ip.sip.message - > > > > > contains base Message class > > > > > >> > > > > > > > >> > > > > > > > jain.protocol.ip.sip.minimal - > > > > > general classes used only at this > > > > > > > > > > >> level and above > > > > > >> > > > > > > > >> > > > > > > > jain.protocol.ip.sip.minimal.header > > > > > - headers used only at this > > > > > >> level and above > > > > > >> > > > > > > > jain.protocol.ip.sip.minimal.message > > > > > - messages only used at > > > > > >> this level and > > > > > >> > > above > > > > > >> > > > > > > > >> > > jain.protocol.ip.sip.basic > > > > > - general classes used only at > > > > > this > > > > > >> level and above > > > > > >> > > > > > > > jain.protocol.ip.sip.basic.header > > > > > - headers used only at this > > > > > >> level and above > > > > > >> > > > > > > > jain.protocol.ip.sip.basic.message > > > > > - messages used only at this > > > > > >> level and above > > > > > >> > > ... > > > > > >> > > .... > > > > > >> > > > > > > > jjain.protocol.ip.sip."full" - > > > > > general classes only used at this > > > > > > > > > > >> level > > > > > >> > > > > > > > jain.protocol.ip.sip."full".header > > > > > - headers used only at this > > > > > >> level > > > > > >> > > > > > > > jain.protocol.ip.sip."full".message > > > > > - messages used only at this > > > > > >> level > > > > > >> > > > > > > > >> > > The API user could then > > > > > pick the packages they need - say > > > > > they > > > > > >> initially only > > > > > >> > > want the minimal features, > > > > > but then realise they need to use > > > > > > > > > > >> their application > > > > > >> > > behind a firewall - then > > > > > they can simply add the > > > > > >> firewall-friendly package. The > > > > > > > > > > >> > > RFC says "In general, each > > > > > capability listed builds on the > > > > > ones > > > > > >> above it" but it > > > > > >> > > is not hard to see that > > > > > firewall-friendly and > > > > > authentication may > > > > > >> be desired > > > > > >> > > without redirection for > > > > > example. > > > > > >> > > > > > > > >> > > Is this what you hand in > > > > > mind Itamar? > > > > > >> > > > > > > >> > -- > > > > > >> > Gethin Liddell > > > > > >> > Ubiquity Software > > > > > Corporation > > > > > >> > > > > > > >> > http://www.ubiquity.net > > > > > >> > mailto:gethin@ubiquity.net > > > > > >> > > > > > > >> > > > > > > _______________________________________________ > > > > > > > > > > >> > SIP mailing list > > > > > >> > SIP@lists.bell-labs.com > > > > > >> > > > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > > > >> > > > > > >> -- > > > > > >> M.Ranganathan > > > > > >> NIST Advanced Networking > > > > > Technologies Group, > > > > > >> 100 Bureau Drive, Stop 8920, > > > > > Gaithersburg, MD 20899. > > > > > >> Tel: 301 975 3664 Fax: 301 590 > > > > > 0932 > > > > > >> > > > > > >> Hfæj)b? > > > > > b²Ô^>X¬¶ÆÞ-YZnÇ(sm§ÿåSËlmée*¦ìr?¿?¨¥?©ÿ-+-SwèþÈ© > > > > > > > > > > > > > > > > > > > > > -- > > > > > M.Ranganathan > > > > > NIST Advanced Networking > > > > > Technologies Group, > > > > > 100 Bureau Drive, Stop 8920, > > > > > Gaithersburg, MD 20899. > > > > > Tel: 301 975 3664 Fax: 301 590 > > > > > 0932 > > > > > > > > > > Hfæj)b? > > > > > b²Ô^>X¬¶ÆÞ-YZnÇ(sm§ÿåSËlmée*¦ìr?¿?¨¥?©ÿ-+-SwèþÈ© > > > > --------------722B6227511445D449FA3502 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Itamar,

I can't really think of any applications other than a stateless proxy that don't care about transactions. And since stateless proxies are really just SIP routers and need maximum performance, I can't really see anyone implementing them with JAIN SIP.

I think any application that does anything interesting needs to know about transactions, so the the JAIN SIP API should include some means of identifying transactions or transaction control. But this has to fit in with the Listener/Provider event model, so we can't hand a Listener a transaction object that they can work with directly - we need to give an application access to transactions through the Provider. I thought a transaction id would be the simplest way to achieve this. Do you have any suggestions for improving transaction control for the event model?

Chris

Itamar Gilad wrote:

 No, that's not it.  The application uses a stack to do all of this.  The stack should export a message-related API like the one defined in the JAIN SIP specification you presented.  The stack should also export interfaces for Call control and Transaction control.  It seems more logical for the application to use a transaction object which handles messaging and notifies it whenever a message belonging to this transaction is received rather then having a message object that tells it which transaction it belongs too.  Stateless proxies for example would use only the message layer and they don't care at all about transactions. I'm Sorry to be so picky, but I just think that this makes for a cleaner design both in the application and in the stack.  Our experience with our SIP stack proves that this model works fine.Itamar
-----Original Message-----
From: Chris Harris [mailto:charris@dynamicsoft.com]
Sent: Wed, October 18, 2000 8:18 PM
To: discussion@sipforum.org
Cc: Itamar Gilad; 'Bobby Sardana'; mranga@nist.gov; sip@lists.bell-labs.com; jainsip@Sun.COM
Subject: Re: [SIPFORUM] Re: [SIP] JAIN SIP Specification
 
OK - so if an application just sends a message to the Provider, it has to check all response messages to see if they match - this is so messy for an application. What if a response message never arrives - how should the Provider inform the application of a timeout? Call a timeout method and pass the request message back?

Itamar Gilad wrote:

 Chris, I agree that few SIP applications would like to bother with transaction mapping.  This is clearly the responsibility of the stack as is transaction management in general. However in a previous thread you explained that the issue of managing call and transaction state is outside the scope of this API specification, which led me to believe that the goal is to define message-related functionality. I think that injecting transaction keys into the mix is crossing the lines you defined. Regards,  Itamar
-----Original Message-----
From: Chris Harris [mailto:charris@dynamicsoft.com]
Sent: Wed, October 18, 2000 7:44 PM
To: Itamar Gilad
Cc: 'Bobby Sardana'; discussion@sipforum.org; mranga@nist.gov; sip@lists.bell-labs.com; jainsip@Sun.COM
Subject: Re: [SIPFORUM] Re: [SIP] JAIN SIP Specification
Itamar,

It is for the very reason that identifying a transaction from a message is not a trivial matter that I wanted to put the transaction handling inside the JainSipProvider. I don't think the spec should just deal with just the message layer. How many people are going to write JAIN SIP applications if they have to implement their own transaction keys? I'd imagine very few.

Regards,
Chris

Itamar Gilad wrote:

Hi again Chris,I'd like to re-emphasize what Bobby says below.  The JAIN SIP specification presented here seems to deal just with the "message layer" i.e. parsing, encoding, message and message part containers.  I'd like to join those who commend the fine and comprehensive work done.  However, this layer has nothing to do with transactions and their state.  It would be a mistake to rely on it to retain 'transaction-ids' and associate messages to them (please correct me if I'm misinterpreting your meaning). Note that identifying a transaction from a message is not a trivial matter and continuously more message fields are added to the "transaction key" in order to deal with spiraling, merging etc. A more straight-forward approach would be to put this functionality in the "transaction layer" where transaction objects live and make a clean separation between the two layers.Regards Itamar
-----Original Message-----
From: Bobby Sardana [mailto:bobby.sardana@mobilerain.com]
Sent: Wed, October 18, 2000 6:39 PM
To: discussion@sipforum.org
Cc: mranga@nist.gov; sip@lists.bell-labs.com; jainsip@sun.com
Subject: Re: [SIPFORUM] Re: [SIP] JAIN SIP Specification
 
Greetings Chris:

Just to add a pointer to this thread:

Maintaining trasaction state is an application level functionality and *shouldn't* be implemented in the base stack. For applications like state oriented proxy server, the JAIN SIP can provide enough hooks for event delivery but the state has to be maintained by the proxy server.

Pleas keep up the good work. It is really appreciated.

Regards,

Bobby.Sardana@mobilerain.com

Chris Harris wrote:

"M. Ranganathan" wrote:
Hi Chris,

Thanks for replying so promptly (I am sure you are flooded with email ).

I get one or two :)
 
As you pointed out, I suppose we cannot do away with making Messages
into classes because of the tie-in with java events (unfortunately) but
I still like the notion of being able to specify  interfaces where ever
possible.
I see where you're coming from alright, and I suppose changing header classes into interfaces, could fit in with Gethin's proposal nicely?
 
 I dont quite follow  the motivation behind the following design
decision (excerpted from your reply):

Maybe I've misunderstood what you're saying - but a JAIN SIP
implementation is only stateless when it comes to call state. The
JainSipProvider implementation must maintain transaction state - it
simply exposes a reference to a transaction via the transaction id for
the convenience of the JainSipListener. The service does not have total
control over transacton state - the stack implementation does.

It appears that I have indded mis-understood the architecture.  Why
should the above be so? Can one not rely on the JainSipListener to keep
transaction state also, thereby making the stack simply a way of
recognising messages and triggering  event handlers on the basis of
message type. This would (IMHO) be a cleaner model yet.    That way,  we
can do away with transaction identifiers being passed back and forth and
keep all of this information in the handler.  ( You may have to extend
the architecture somewhat to deal with timeouts and failures so that the
handler knows about transaction failure.) In any case, if this is not a
viable idea, I would be grateful if you can explain why not (or point me
to the portion of the spec that explains why not) so I can get a better
understanding.

It would be cleaner model, and personally I am in total agreement with you - but it means the application is forced to maintain transaction state, match up headers - which has been said places too much of a burden on applications. How about finding a way to let the application choose whether or not it wants to keep transaction state?
 

Regards,

Ranga.

Chris Harris wrote:

> Hi Ranga,
>
> Response below...
>
> Chris
>
> "M. Ranganathan" wrote:
>
>> JAIN-SIP is a groovy idea. Hats off to the whole concept and many
>> thanks to Chris and
>> the JAIN-SIP team for putting together a spec and more flower power
>> to them :-) .  In
>> particular I like the notion of treating UAS,  Redirect and Proxy
>> servers as merely
>> special cases of the general notion of Services and  the idea of
>> unifying these
>> notions with an event mechanism and  event handlers.  Second, I like
>> the idea of
>> separation between a  stateless  event -oriented "stack" and a bunch
>> of event
>> handlers that are triggered by the stack with all state (including
>> transaction
>> state) being separated from the event stack via the JAIN-SIP mapping
>> layer if you
>> will.  ( Correct me if I  wax poetic but have the wrong
>> understanding....)
>
>>
>>
>> I hope I  will not be viewed as being too critical,  but I would
>> like to go  one step
>> further than what Gethin is suggesting.   I am all for using
>> interfaces as much as
>> possible and leaving class hierarchy definitions to implemeters.
>> Defining class
>> hierarchies almost lays out an implementation and involves
>> considerable rework for
>> those who have a working java-based stack, but have not used the
>> same classes. OK it
>> is just a matter of labor to map things to the JAIN-SIP class
>> hierarchy but it  IS a
>> dis-incentive.
>>
>> 1. Lets use interfaces for all messages rather than actually define
>> class
>> hierarchies  ( yes Chris has pointed out the historical precedent
>> behind actually
>> defining class hierarchies for messages. IMHO,  there has to be a
>> more compelling
>> reason than that.)
>
> I suppose all classes could be turned into interfaces, except for the
> Message classes which must extend java.util.EventObject to fit into
> the JAIN framework.
>
>>
>>
>> 2. The tie-in with the JAVA event mechanism has necessitated the
>> explicit definition
>> of class hierarchies in certain places.  Why not use callbacks
>> instead and do away
>> with this dependency as well?  (Basically the same thing as events
>> but does not tie
>> into the JAVA event mechanism and its associated limitations.)
>
> Unfortunately the JAIN framework expilicitly relies on the Java Event
> model, and I don't think callbacks would be accepted within the JAIN
> community.
>
>>
>>
>> Nice work and keep it rolling!  Thanks.
>
> Couldn't do it without you guys - thank you!
>
>>
>>
>> Ranga.
>>
>> Gethin Liddell wrote:
>>
>> > All,
>> >
>> > This idea of abstraction of the JAIN API is certainly a valid and
>> > interesting idea.  However, i'm a bit concerened that the proposed
>>
>> > solution of many different packages, will only seek to complicate
>> and
>> > maybe enlarge the API.
>> >
>> > I too see no reason why there is an EntityHeader etc... and i also
>> do
>> > not see any requirement for an InviteMessage, AckMessage etc...
>> >
>> > How about if the format of the API remains as is:
>> >
>> > jain.protocol.ip.sip
>> > jain.protocol.ip.sip.header
>> > jain.protocol.ip.sip.message
>> >
>> > except that the messages available in the message package
>> consisted of
>> > BasicRequest/Response, MinimalRequest/Response etc... where each
>> > message is extened in turn (e.g. Minimal extends Basic, Moderate
>> > extends Minimal etc...), of course as Chris points out it is not
>> hard
>> > to see that a combination would be required that is not provided.
>> So
>> > in the interest of flexibility, it could be possible for the user
>> to
>> > plug-in to the message class what extra headers it requires.  The
>> only
>> > issue then is that the user will have to use a "public Header
>> > getHeader(String headerName)" and then cast the header to their
>> desired
>> > header type. Either that or create their own Message class
>> > (extending the current ones) that simply does the casting
>> automatically
>> > for them.  Then after compiling, run an obfuscator on the code and
>> it
>> > will automatically extract and only extract the Message, Headers
>> and
>> > even methods that are used.
>> >
>> > This then will also cut down on the number of methods in the
>> Provider
>> > as there will be no need for the sendAck(AckMessage),
>> > sendInvite(InviteMessage) etc.. as they would be replaced by the
>> > single method sendRequest(RequestMessage).
>> >
>> > I personally see three arguments for keeping the JAIN SIP stack as
>> small
>> > as possible:
>> >
>> > 1) The first is for embedded applications where stack size has to
>> be
>> > kept to a minimum as memory is at a premium.  So if just using the
>>
>> > Basic message suffices then this will compile and run with a small
>>
>> > number of classes present from the stack.  Don't forget,
>> obfuscation
>> > will help in extracting only the Messages, Headers and even
>> methods
>> > required from a jar file but it won't do everything.
>> >
>> > 2) The second is that users may be put off or confused by the
>> sheer
>> > size and complexity of the JAIN stack.  So if only using the
>> > BasicMessage gets them on the first rung of the ladder then it is
>> a
>> > good starting point and allows them to build up to bigger and
>> better
>> > things.
>> >
>> > 3) We also have to consider who is going to implement the JAIN SIP
>>
>> > stack. If it is indeed overly complicated then no-one or a single
>> > vendor may end up implmenting the stack and thus its definition
>> and
>> > all the hard work that has gone into it is useless.
>> >
>> > On Mon, 16 Oct 2000, Chris Harris wrote:
>> > > Itamar,
>> > >
>> > > The idea of levelling the API based on what messages, headers
>> and response codes
>> > > are understood is certainly an interesting one - minimal, basic,
>> redirection,
>> > > firewall-friendly, negotiation, authentication and "full".
>> > >
>> > > jain.protocol.ip.sip
>> > > jain.protocol.ip.sip.header
>> > > jain.protocol.ip.sip.message
>> > >
>> > > could then become...
>> > >
>> > > jain.protocol.ip.sip - listener, provider, stack, general
>> classes used at all
>> > > levels
>> > > jain.protocol.ip.sip.header - contains base Header class (and
>> requestHeader,
>> > > ResponseHeader, EntityHeader, GeneralHeader)
>> > > jain.protocol.ip.sip.message - contains base Message class
>> > >
>> > > jain.protocol.ip.sip.minimal - general classes used only at this
>> level and above
>> > >
>> > > jain.protocol.ip.sip.minimal.header - headers used only at this
>> level and above
>> > > jain.protocol.ip.sip.minimal.message - messages only used at
>> this level and
>> > > above
>> > >
>> > > jain.protocol.ip.sip.basic - general classes used only at this
>> level and above
>> > > jain.protocol.ip.sip.basic.header - headers used only at this
>> level and above
>> > > jain.protocol.ip.sip.basic.message - messages used only at this
>> level and above
>> > > ...
>> > > ....
>> > > jjain.protocol.ip.sip."full" - general classes only used at this
>> level
>> > > jain.protocol.ip.sip."full".header - headers used only at this
>> level
>> > > jain.protocol.ip.sip."full".message - messages used only at this
>> level
>> > >
>> > > The API user could then pick the packages they need - say they
>> initially only
>> > > want the minimal features, but then realise they need to use
>> their application
>> > > behind a firewall - then they can simply add the
>> firewall-friendly package. The
>> > > RFC says "In general, each capability listed builds on the ones
>> above it" but it
>> > > is not hard to see that firewall-friendly and authentication may
>> be desired
>> > > without redirection for example.
>> > >
>> > > Is this what you hand in mind Itamar?
>> >
>> > --
>> > Gethin Liddell
>> > Ubiquity Software Corporation
>> >
>> > http://www.ubiquity.net
>> > mailto:gethin@ubiquity.net
>> >
>> > _______________________________________________
>> > SIP mailing list
>> > SIP@lists.bell-labs.com
>> > http://lists.bell-labs.com/mailman/listinfo/sip
>>
>> --
>> M.Ranganathan
>> NIST Advanced Networking Technologies Group,
>> 100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899.
>> Tel: 301 975 3664 Fax: 301 590 0932
>>
>> Hfæj)b? b²Ô^>X¬¶ÆÞ-YZnÇ(sm§ÿåSËlmée*¦ìr?¿?¨¥?©ÿ-+-SwèþÈ©
>

--
M.Ranganathan
NIST Advanced Networking Technologies Group,
100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899.
Tel: 301 975 3664 Fax: 301 590 0932

Hfæj)b? b²Ô^>X¬¶ÆÞ-YZnÇ(sm§ÿåSËlmée*¦ìr?¿?¨¥?©ÿ-+-SwèþÈ©

--------------722B6227511445D449FA3502-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Oct 19 07:26:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA03714 for ; Thu, 19 Oct 2000 07:26:03 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id BF0DF44337; Thu, 19 Oct 2000 06:26:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lists.bell-labs.com (Postfix) with ESMTP id CE5D044336 for ; Thu, 19 Oct 2000 06:25:04 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id e9JBOwt13289; Thu, 19 Oct 2000 13:24:58 +0200 (MEST) Received: from lmf.ericsson.se (E005004B57366.lmf.ericsson.se [131.160.30.12]) by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id OAA18833; Thu, 19 Oct 2000 14:24:57 +0300 (EET DST) Message-ID: <39EEDA06.56AB2302@lmf.ericsson.se> From: Gonzalo Camarillo X-Mailer: Mozilla 4.74 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Anders Kristensen Cc: SIP Subject: Source Routing WAS Re: [SIP] Route learnt out of band References: <39ED986B.A022F0AB@lmf.ericsson.se> <39EDAB64.657547E4@dynamicsoft.com> <39EDB150.9B27646B@lmf.ericsson.se> <39EDB57C.B1E9BCDA@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 19 Oct 2000 14:24:54 +0300 Content-Transfer-Encoding: 7bit Hi, Taking a look at both threads, "outbound call routing" and "Route learnt out of band", I have found similarities and some differences in the problems they are trying to address. Basically we have the same issue: how to perform source routing using SIP. However, folks are speaking about two types of source routing. Using IP terminology, they are "loose source routing" and "strict source routing". In loose source routing the source wants the request to traverse a particular set of nodes. The request can traverse other nodes as well, but at least has to traverse this particular nodes. In strict source routing the source wants the request to follow a particular path. They request must traverse a particular set of nodes, and it cannot go to any other node. The "Outbound call routing" problem, where I want my request to go thru a certain proxy seems to me a loose source routing problem. I want the request to go to this outbound proxy and then I want it to be routed towards its destination. The semantics of the current Route header are not appropiate for this. I find the Route header more appropiate for performing strict source routing. That is, when the UAC knows in advance all the servers (the UAS included) that the request should traverse. I would like to use the current Route header for this purpose. The only new thing would be that the Route header could be used even without having received a Record-Route previously. Comments? Best regards, Gonzalo P.D: Thanks for the pointer, Anders. Anders Kristensen wrote: > > Gonzalo Camarillo wrote: > > > > Hej Anders, > > Hejsa! > > > > > Anders Kristensen wrote: > > > > > > This ability to perform source routing for an initial INVITE came up > > > recently as a desirable feature in a slightly different context. > > > > As I said in my mail, there are many scenarios where this feature could > > be useful. I believe this is a general mechanism with general > > applicability. > > Which context are you referring to? > > http://lists.bell-labs.com/pipermail/sip/2000q3/thread.html thread named > "Outbound call routing". Explicit route used to enable services on home > proxy when making calls from visited domain. > > -- > Anders Kristensen _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Oct 19 07:54:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA08333 for ; Thu, 19 Oct 2000 07:54:03 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B794344337; Thu, 19 Oct 2000 06:54:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from drago1.ubiquity.net (unknown [194.202.146.92]) by lists.bell-labs.com (Postfix) with SMTP id 65BAF44336 for ; Thu, 19 Oct 2000 06:53:10 -0400 (EDT) Received: from gecko.ubiquity.co.uk by drago1.ubiquity.net via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 19 Oct 2000 11:53:39 UT Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id MAA26551; Thu, 19 Oct 2000 12:51:27 +0100 (BST) From: "Jo Hornsby" To: "Gonzalo Camarillo" , "Anders Kristensen" Cc: "SIP" Subject: RE: Source Routing WAS Re: [SIP] Route learnt out of band Message-ID: <004901c039c2$ea34a050$4e34c3c1@ubiquity.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 In-Reply-To: <39EEDA06.56AB2302@lmf.ericsson.se> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 19 Oct 2000 12:51:28 +0100 Content-Transfer-Encoding: 7bit > Taking a look at both threads, "outbound call routing" and "Route learnt > out of band", I have found similarities and some differences in the > problems they are trying to address. > > Basically we have the same issue: how to perform source routing using > SIP. > > However, folks are speaking about two types of source routing. Using IP > terminology, they are "loose source routing" and "strict source > routing". > > In loose source routing the source wants the request to traverse a > particular set of nodes. The request can traverse other nodes as well, > but at least has to traverse this particular nodes. > > In strict source routing the source wants the request to follow a > particular path. They request must traverse a particular set of nodes, > and it cannot go to any other node. > > The "Outbound call routing" problem, where I want my request to go thru > a certain proxy seems to me a loose source routing problem. I want the > request to go to this outbound proxy and then I want it to be routed > towards its destination. > > The semantics of the current Route header are not appropiate for this. > > I find the Route header more appropiate for performing strict source > routing. That is, when the UAC knows in advance all the servers (the UAS > included) that the request should traverse. I'm not sure that this is necessarily true. If you look to bis02, we have: 6.34.3 Request Destination Unless this would cause a loop, any client, including the UAC, SHOULD send the next request for this call leg to the first Request-URI in the Route request header field. A client MAY forward the request to a designated proxy instead, for example, if it lacks DNS resolution capability. If a client uses the first Route entry to route the request, it removes it. Thus there is flexibility here. When is a proxy likely to ignore a Route directive? My initial thoughts are when there are networking issues (it knows it has to go via some ALG-proxy, for instance), or when there are billing issues. But there is nothing wrong with this. Thus I would say that as long as a proxy is happy to receive a request with Route headers in for an unknown call leg, things should work out okay; it will use other proxies as necessary, and any of these will Record-Route if they need to remain in the signalling path. Cheers, - Jo. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Oct 19 08:03:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA09607 for ; Thu, 19 Oct 2000 08:03:04 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0E38044352; Thu, 19 Oct 2000 07:03:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from guardian1.tlv.radvision.com (unknown [212.143.185.30]) by lists.bell-labs.com (Postfix) with ESMTP id A8FB644337 for ; Thu, 19 Oct 2000 07:02:47 -0400 (EDT) Received: from nt-mail.tlv.radvision.com ([172.20.2.100]) by guardian1.tlv.radvision.com (Post.Office MTA v3.5.3 release 223 ID# 0-0U10L2S100V35) with ESMTP id com; Thu, 19 Oct 2000 15:01:33 +0200 Received: by NT-MAIL with Internet Mail Service (5.5.2650.21) id ; Thu, 19 Oct 2000 14:02:53 +0200 Message-ID: From: Itamar Gilad To: "'Chris Harris'" , sip@lists.bell-labs.com Cc: discussion@sipforum.org, jainsip@Sun.COM Subject: RE: [SIPFORUM] Re: [SIP] JAIN SIP Specification MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C039C4.82433630" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 19 Oct 2000 14:02:52 +0200 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_01C039C4.82433630 Content-Type: text/plain; charset="iso-8859-1" Hi Chris, It could be argued that it makes just as much sense for the Provider to identify also the Call-Leg and Call. Still I think I understand what you are after and I agree that this might help applications that for some reason want to know about transaction 'ids', but don't want to work with transaction objects. Regards Itamar -----Original Message----- From: Chris Harris [mailto:charris@dynamicsoft.com] Sent: Thu, October 19, 2000 12:11 PM To: sip@lists.bell-labs.com Cc: discussion@sipforum.org; jainsip@Sun.COM Subject: Re: [SIPFORUM] Re: [SIP] JAIN SIP Specification Hi Itamar, I can't really think of any applications other than a stateless proxy that don't care about transactions. And since stateless proxies are really just SIP routers and need maximum performance, I can't really see anyone implementing them with JAIN SIP. I think any application that does anything interesting needs to know about transactions, so the the JAIN SIP API should include some means of identifying transactions or transaction control. But this has to fit in with the Listener/Provider event model, so we can't hand a Listener a transaction object that they can work with directly - we need to give an application access to transactions through the Provider. I thought a transaction id would be the simplest way to achieve this. Do you have any suggestions for improving transaction control for the event model? Chris Itamar Gilad wrote: No, that's not it. The application uses a stack to do all of this. The stack should export a message-related API like the one defined in the JAIN SIP specification you presented. The stack should also export interfaces for Call control and Transaction control. It seems more logical for the application to use a transaction object which handles messaging and notifies it whenever a message belonging to this transaction is received rather then having a message object that tells it which transaction it belongs too. Stateless proxies for example would use only the message layer and they don't care at all about transactions. I'm Sorry to be so picky, but I just think that this makes for a cleaner design both in the application and in the stack. Our experience with our SIP stack proves that this model works fine.Itamar -----Original Message----- From: Chris Harris [ mailto:charris@dynamicsoft.com ] Sent: Wed, October 18, 2000 8:18 PM To: discussion@sipforum.org Cc: Itamar Gilad; 'Bobby Sardana'; mranga@nist.gov; sip@lists.bell-labs.com; jainsip@Sun.COM Subject: Re: [SIPFORUM] Re: [SIP] JAIN SIP Specification OK - so if an application just sends a message to the Provider, it has to check all response messages to see if they match - this is so messy for an application. What if a response message never arrives - how should the Provider inform the application of a timeout? Call a timeout method and pass the request message back? Itamar Gilad wrote: Chris, I agree that few SIP applications would like to bother with transaction mapping. This is clearly the responsibility of the stack as is transaction management in general. However in a previous thread you explained that the issue of managing call and transaction state is outside the scope of this API specification, which led me to believe that the goal is to define message-related functionality. I think that injecting transaction keys into the mix is crossing the lines you defined. Regards, Itamar -----Original Message----- From: Chris Harris [ mailto:charris@dynamicsoft.com ] Sent: Wed, October 18, 2000 7:44 PM To: Itamar Gilad Cc: 'Bobby Sardana'; discussion@sipforum.org; mranga@nist.gov; sip@lists.bell-labs.com; jainsip@Sun.COM Subject: Re: [SIPFORUM] Re: [SIP] JAIN SIP Specification Itamar, It is for the very reason that identifying a transaction from a message is not a trivial matter that I wanted to put the transaction handling inside the JainSipProvider. I don't think the spec should just deal with just the message layer. How many people are going to write JAIN SIP applications if they have to implement their own transaction keys? I'd imagine very few. Regards, Chris Itamar Gilad wrote: Hi again Chris,I'd like to re-emphasize what Bobby says below. The JAIN SIP specification presented here seems to deal just with the "message layer" i.e. parsing, encoding, message and message part containers. I'd like to join those who commend the fine and comprehensive work done. However, this layer has nothing to do with transactions and their state. It would be a mistake to rely on it to retain 'transaction-ids' and associate messages to them (please correct me if I'm misinterpreting your meaning). Note that identifying a transaction from a message is not a trivial matter and continuously more message fields are added to the "transaction key" in order to deal with spiraling, merging etc. A more straight-forward approach would be to put this functionality in the "transaction layer" where transaction objects live and make a clean separation between the two layers.Regards Itamar -----Original Message----- From: Bobby Sardana [ mailto:bobby.sardana@mobilerain.com ] Sent: Wed, October 18, 2000 6:39 PM To: discussion@sipforum.org Cc: mranga@nist.gov; sip@lists.bell-labs.com; jainsip@sun.com Subject: Re: [SIPFORUM] Re: [SIP] JAIN SIP Specification Greetings Chris: Just to add a pointer to this thread: Maintaining trasaction state is an application level functionality and *shouldn't* be implemented in the base stack. For applications like state oriented proxy server, the JAIN SIP can provide enough hooks for event delivery but the state has to be maintained by the proxy server. Pleas keep up the good work. It is really appreciated. Regards, Bobby.Sardana@mobilerain.com Chris Harris wrote: "M. Ranganathan" wrote: Hi Chris, Thanks for replying so promptly (I am sure you are flooded with email ). I get one or two :) As you pointed out, I suppose we cannot do away with making Messages into classes because of the tie-in with java events (unfortunately) but I still like the notion of being able to specify interfaces where ever possible. I see where you're coming from alright, and I suppose changing header classes into interfaces, could fit in with Gethin's proposal nicely? I dont quite follow the motivation behind the following design decision (excerpted from your reply): Maybe I've misunderstood what you're saying - but a JAIN SIP implementation is only stateless when it comes to call state. The JainSipProvider implementation must maintain transaction state - it simply exposes a reference to a transaction via the transaction id for the convenience of the JainSipListener. The service does not have total control over transacton state - the stack implementation does. It appears that I have indded mis-understood the architecture. Why should the above be so? Can one not rely on the JainSipListener to keep transaction state also, thereby making the stack simply a way of recognising messages and triggering event handlers on the basis of message type. This would (IMHO) be a cleaner model yet. That way, we can do away with transaction identifiers being passed back and forth and keep all of this information in the handler. ( You may have to extend the architecture somewhat to deal with timeouts and failures so that the handler knows about transaction failure.) In any case, if this is not a viable idea, I would be grateful if you can explain why not (or point me to the portion of the spec that explains why not) so I can get a better understanding. It would be cleaner model, and personally I am in total agreement with you - but it means the application is forced to maintain transaction state, match up headers - which has been said places too much of a burden on applications. How about finding a way to let the application choose whether or not it wants to keep transaction state? Regards, Ranga. Chris Harris wrote: > Hi Ranga, > > Response below... > > Chris > > "M. Ranganathan" wrote: > >> JAIN-SIP is a groovy idea. Hats off to the whole concept and many >> thanks to Chris and >> the JAIN-SIP team for putting together a spec and more flower power >> to them :-) . In >> particular I like the notion of treating UAS, Redirect and Proxy >> servers as merely >> special cases of the general notion of Services and the idea of >> unifying these >> notions with an event mechanism and event handlers. Second, I like >> the idea of >> separation between a stateless event -oriented "stack" and a bunch >> of event >> handlers that are triggered by the stack with all state (including >> transaction >> state) being separated from the event stack via the JAIN-SIP mapping >> layer if you >> will. ( Correct me if I wax poetic but have the wrong >> understanding....) > >> >> >> I hope I will not be viewed as being too critical, but I would >> like to go one step >> further than what Gethin is suggesting. I am all for using >> interfaces as much as >> possible and leaving class hierarchy definitions to implemeters. >> Defining class >> hierarchies almost lays out an implementation and involves >> considerable rework for >> those who have a working java-based stack, but have not used the >> same classes. OK it >> is just a matter of labor to map things to the JAIN-SIP class >> hierarchy but it IS a >> dis-incentive. >> >> 1. Lets use interfaces for all messages rather than actually define >> class >> hierarchies ( yes Chris has pointed out the historical precedent >> behind actually >> defining class hierarchies for messages. IMHO, there has to be a >> more compelling >> reason than that.) > > I suppose all classes could be turned into interfaces, except for the > Message classes which must extend java.util.EventObject to fit into > the JAIN framework. > >> >> >> 2. The tie-in with the JAVA event mechanism has necessitated the >> explicit definition >> of class hierarchies in certain places. Why not use callbacks >> instead and do away >> with this dependency as well? (Basically the same thing as events >> but does not tie >> into the JAVA event mechanism and its associated limitations.) > > Unfortunately the JAIN framework expilicitly relies on the Java Event > model, and I don't think callbacks would be accepted within the JAIN > community. > >> >> >> Nice work and keep it rolling! Thanks. > > Couldn't do it without you guys - thank you! > >> >> >> Ranga. >> >> Gethin Liddell wrote: >> >> > All, >> > >> > This idea of abstraction of the JAIN API is certainly a valid and >> > interesting idea. However, i'm a bit concerened that the proposed >> >> > solution of many different packages, will only seek to complicate >> and >> > maybe enlarge the API. >> > >> > I too see no reason why there is an EntityHeader etc... and i also >> do >> > not see any requirement for an InviteMessage, AckMessage etc... >> > >> > How about if the format of the API remains as is: >> > >> > jain.protocol.ip.sip >> > jain.protocol.ip.sip.header >> > jain.protocol.ip.sip.message >> > >> > except that the messages available in the message package >> consisted of >> > BasicRequest/Response, MinimalRequest/Response etc... where each >> > message is extened in turn (e.g. Minimal extends Basic, Moderate >> > extends Minimal etc...), of course as Chris points out it is not >> hard >> > to see that a combination would be required that is not provided. >> So >> > in the interest of flexibility, it could be possible for the user >> to >> > plug-in to the message class what extra headers it requires. The >> only >> > issue then is that the user will have to use a "public Header >> > getHeader(String headerName)" and then cast the header to their >> desired >> > header type. Either that or create their own Message class >> > (extending the current ones) that simply does the casting >> automatically >> > for them. Then after compiling, run an obfuscator on the code and >> it >> > will automatically extract and only extract the Message, Headers >> and >> > even methods that are used. >> > >> > This then will also cut down on the number of methods in the >> Provider >> > as there will be no need for the sendAck(AckMessage), >> > sendInvite(InviteMessage) etc.. as they would be replaced by the >> > single method sendRequest(RequestMessage). >> > >> > I personally see three arguments for keeping the JAIN SIP stack as >> small >> > as possible: >> > >> > 1) The first is for embedded applications where stack size has to >> be >> > kept to a minimum as memory is at a premium. So if just using the >> >> > Basic message suffices then this will compile and run with a small >> >> > number of classes present from the stack. Don't forget, >> obfuscation >> > will help in extracting only the Messages, Headers and even >> methods >> > required from a jar file but it won't do everything. >> > >> > 2) The second is that users may be put off or confused by the >> sheer >> > size and complexity of the JAIN stack. So if only using the >> > BasicMessage gets them on the first rung of the ladder then it is >> a >> > good starting point and allows them to build up to bigger and >> better >> > things. >> > >> > 3) We also have to consider who is going to implement the JAIN SIP >> >> > stack. If it is indeed overly complicated then no-one or a single >> > vendor may end up implmenting the stack and thus its definition >> and >> > all the hard work that has gone into it is useless. >> > >> > On Mon, 16 Oct 2000, Chris Harris wrote: >> > > Itamar, >> > > >> > > The idea of levelling the API based on what messages, headers >> and response codes >> > > are understood is certainly an interesting one - minimal, basic, >> redirection, >> > > firewall-friendly, negotiation, authentication and "full". >> > > >> > > jain.protocol.ip.sip >> > > jain.protocol.ip.sip.header >> > > jain.protocol.ip.sip.message >> > > >> > > could then become... >> > > >> > > jain.protocol.ip.sip - listener, provider, stack, general >> classes used at all >> > > levels >> > > jain.protocol.ip.sip.header - contains base Header class (and >> requestHeader, >> > > ResponseHeader, EntityHeader, GeneralHeader) >> > > jain.protocol.ip.sip.message - contains base Message class >> > > >> > > jain.protocol.ip.sip.minimal - general classes used only at this >> level and above >> > > >> > > jain.protocol.ip.sip.minimal.header - headers used only at this >> level and above >> > > jain.protocol.ip.sip.minimal.message - messages only used at >> this level and >> > > above >> > > >> > > jain.protocol.ip.sip.basic - general classes used only at this >> level and above >> > > jain.protocol.ip.sip.basic.header - headers used only at this >> level and above >> > > jain.protocol.ip.sip.basic.message - messages used only at this >> level and above >> > > ... >> > > .... >> > > jjain.protocol.ip.sip."full" - general classes only used at this >> level >> > > jain.protocol.ip.sip."full".header - headers used only at this >> level >> > > jain.protocol.ip.sip."full".message - messages used only at this >> level >> > > >> > > The API user could then pick the packages they need - say they >> initially only >> > > want the minimal features, but then realise they need to use >> their application >> > > behind a firewall - then they can simply add the >> firewall-friendly package. The >> > > RFC says "In general, each capability listed builds on the ones >> above it" but it >> > > is not hard to see that firewall-friendly and authentication may >> be desired >> > > without redirection for example. >> > > >> > > Is this what you hand in mind Itamar? >> > >> > -- >> > Gethin Liddell >> > Ubiquity Software Corporation >> > >> > http://www.ubiquity.net >> > mailto:gethin@ubiquity.net >> > >> > _______________________________________________ >> > SIP mailing list >> > SIP@lists.bell-labs.com >> > http://lists.bell-labs.com/mailman/listinfo/sip >> >> -- >> M.Ranganathan >> NIST Advanced Networking Technologies Group, >> 100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899. >> Tel: 301 975 3664 Fax: 301 590 0932 >> >> Hfæj)b? b²Ô^>X¬¶ÆÞ-YZnÇ(sm§ÿåSËlmée*¦ìr?¿?¨¥?©ÿ-+-SwèþÈ© > -- M.Ranganathan NIST Advanced Networking Technologies Group, 100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899. Tel: 301 975 3664 Fax: 301 590 0932 Hfæj)b? b²Ô^>X¬¶ÆÞ-YZnÇ(sm§ÿåSËlmée*¦ìr?¿?¨¥?©ÿ-+-SwèþÈ© ------_=_NextPart_001_01C039C4.82433630 Content-Type: text/html; charset="iso-8859-1"
Hi Chris,
 
It could be argued that it makes just as much sense for the Provider to identify also the Call-Leg and Call. Still I think I understand what you are after and I agree that this might help applications that for some reason want to know about transaction 'ids', but don't want to work with transaction objects. 
 
Regards 
  Itamar 
-----Original Message-----
From: Chris Harris [mailto:charris@dynamicsoft.com]
Sent: Thu, October 19, 2000 12:11 PM
To: sip@lists.bell-labs.com
Cc: discussion@sipforum.org; jainsip@Sun.COM
Subject: Re: [SIPFORUM] Re: [SIP] JAIN SIP Specification

Hi Itamar,

I can't really think of any applications other than a stateless proxy that don't care about transactions. And since stateless proxies are really just SIP routers and need maximum performance, I can't really see anyone implementing them with JAIN SIP.

I think any application that does anything interesting needs to know about transactions, so the the JAIN SIP API should include some means of identifying transactions or transaction control. But this has to fit in with the Listener/Provider event model, so we can't hand a Listener a transaction object that they can work with directly - we need to give an application access to transactions through the Provider. I thought a transaction id would be the simplest way to achieve this. Do you have any suggestions for improving transaction control for the event model?

Chris

Itamar Gilad wrote:

 No, that's not it.  The application uses a stack to do all of this.  The stack should export a message-related API like the one defined in the JAIN SIP specification you presented.  The stack should also export interfaces for Call control and Transaction control.  It seems more logical for the application to use a transaction object which handles messaging and notifies it whenever a message belonging to this transaction is received rather then having a message object that tells it which transaction it belongs too.  Stateless proxies for example would use only the message layer and they don't care at all about transactions. I'm Sorry to be so picky, but I just think that this makes for a cleaner design both in the application and in the stack.  Our experience with our SIP stack proves that this model works fine.Itamar
-----Original Message-----
From: Chris Harris [mailto:charris@dynamicsoft.com]
Sent: Wed, October 18, 2000 8:18 PM
To: discussion@sipforum.org
Cc: Itamar Gilad; 'Bobby Sardana'; mranga@nist.gov; sip@lists.bell-labs.com; jainsip@Sun.COM
Subject: Re: [SIPFORUM] Re: [SIP] JAIN SIP Specification
 
OK - so if an application just sends a message to the Provider, it has to check all response messages to see if they match - this is so messy for an application. What if a response message never arrives - how should the Provider inform the application of a timeout? Call a timeout method and pass the request message back?

Itamar Gilad wrote:

 Chris, I agree that few SIP applications would like to bother with transaction mapping.  This is clearly the responsibility of the stack as is transaction management in general. However in a previous thread you explained that the issue of managing call and transaction state is outside the scope of this API specification, which led me to believe that the goal is to define message-related functionality. I think that injecting transaction keys into the mix is crossing the lines you defined. Regards,  Itamar
-----Original Message-----
From: Chris Harris [mailto:charris@dynamicsoft.com]
Sent: Wed, October 18, 2000 7:44 PM
To: Itamar Gilad
Cc: 'Bobby Sardana'; discussion@sipforum.org; mranga@nist.gov; sip@lists.bell-labs.com; jainsip@Sun.COM
Subject: Re: [SIPFORUM] Re: [SIP] JAIN SIP Specification
Itamar,

It is for the very reason that identifying a transaction from a message is not a trivial matter that I wanted to put the transaction handling inside the JainSipProvider. I don't think the spec should just deal with just the message layer. How many people are going to write JAIN SIP applications if they have to implement their own transaction keys? I'd imagine very few.

Regards,
Chris

Itamar Gilad wrote:

Hi again Chris,I'd like to re-emphasize what Bobby says below.  The JAIN SIP specification presented here seems to deal just with the "message layer" i.e. parsing, encoding, message and message part containers.  I'd like to join those who commend the fine and comprehensive work done.  However, this layer has nothing to do with transactions and their state.  It would be a mistake to rely on it to retain 'transaction-ids' and associate messages to them (please correct me if I'm misinterpreting your meaning). Note that identifying a transaction from a message is not a trivial matter and continuously more message fields are added to the "transaction key" in order to deal with spiraling, merging etc. A more straight-forward approach would be to put this functionality in the "transaction layer" where transaction objects live and make a clean separation between the two layers.Regards Itamar
-----Original Message-----
From: Bobby Sardana [mailto:bobby.sardana@mobilerain.com]
Sent: Wed, October 18, 2000 6:39 PM
To: discussion@sipforum.org
Cc: mranga@nist.gov; sip@lists.bell-labs.com; jainsip@sun.com
Subject: Re: [SIPFORUM] Re: [SIP] JAIN SIP Specification
 
Greetings Chris:

Just to add a pointer to this thread:

Maintaining trasaction state is an application level functionality and *shouldn't* be implemented in the base stack. For applications like state oriented proxy server, the JAIN SIP can provide enough hooks for event delivery but the state has to be maintained by the proxy server.

Pleas keep up the good work. It is really appreciated.

Regards,

Bobby.Sardana@mobilerain.com

Chris Harris wrote:

"M. Ranganathan" wrote:
Hi Chris,

Thanks for replying so promptly (I am sure you are flooded with email ).

I get one or two :)

As you pointed out, I suppose we cannot do away with making Messages
into classes because of the tie-in with java events (unfortunately) but
I still like the notion of being able to specify  interfaces where ever
possible.
I see where you're coming from alright, and I suppose changing header classes into interfaces, could fit in with Gethin's proposal nicely?

 I dont quite follow  the motivation behind the following design
decision (excerpted from your reply):

Maybe I've misunderstood what you're saying - but a JAIN SIP
implementation is only stateless when it comes to call state. The
JainSipProvider implementation must maintain transaction state - it
simply exposes a reference to a transaction via the transaction id for
the convenience of the JainSipListener. The service does not have total
control over transacton state - the stack implementation does.

It appears that I have indded mis-understood the architecture.  Why
should the above be so? Can one not rely on the JainSipListener to keep
transaction state also, thereby making the stack simply a way of
recognising messages and triggering  event handlers on the basis of
message type. This would (IMHO) be a cleaner model yet.    That way,  we
can do away with transaction identifiers being passed back and forth and
keep all of this information in the handler.  ( You may have to extend
the architecture somewhat to deal with timeouts and failures so that the
handler knows about transaction failure.) In any case, if this is not a
viable idea, I would be grateful if you can explain why not (or point me
to the portion of the spec that explains why not) so I can get a better
understanding.

It would be cleaner model, and personally I am in total agreement with you - but it means the application is forced to maintain transaction state, match up headers - which has been said places too much of a burden on applications. How about finding a way to let the application choose whether or not it wants to keep transaction state?
 

Regards,

Ranga.

Chris Harris wrote:

> Hi Ranga,
>
> Response below...
>
> Chris
>
> "M. Ranganathan" wrote:
>
>> JAIN-SIP is a groovy idea. Hats off to the whole concept and many
>> thanks to Chris and
>> the JAIN-SIP team for putting together a spec and more flower power
>> to them :-) .  In
>> particular I like the notion of treating UAS,  Redirect and Proxy
>> servers as merely
>> special cases of the general notion of Services and  the idea of
>> unifying these
>> notions with an event mechanism and  event handlers.  Second, I like
>> the idea of
>> separation between a  stateless  event -oriented "stack" and a bunch
>> of event
>> handlers that are triggered by the stack with all state (including
>> transaction
>> state) being separated from the event stack via the JAIN-SIP mapping
>> layer if you
>> will.  ( Correct me if I  wax poetic but have the wrong
>> understanding....)
>
>>
>>
>> I hope I  will not be viewed as being too critical,  but I would
>> like to go  one step
>> further than what Gethin is suggesting.   I am all for using
>> interfaces as much as
>> possible and leaving class hierarchy definitions to implemeters.
>> Defining class
>> hierarchies almost lays out an implementation and involves
>> considerable rework for
>> those who have a working java-based stack, but have not used the
>> same classes. OK it
>> is just a matter of labor to map things to the JAIN-SIP class
>> hierarchy but it  IS a
>> dis-incentive.
>>
>> 1. Lets use interfaces for all messages rather than actually define
>> class
>> hierarchies  ( yes Chris has pointed out the historical precedent
>> behind actually
>> defining class hierarchies for messages. IMHO,  there has to be a
>> more compelling
>> reason than that.)
>
> I suppose all classes could be turned into interfaces, except for the
> Message classes which must extend java.util.EventObject to fit into
> the JAIN framework.
>
>>
>>
>> 2. The tie-in with the JAVA event mechanism has necessitated the
>> explicit definition
>> of class hierarchies in certain places.  Why not use callbacks
>> instead and do away
>> with this dependency as well?  (Basically the same thing as events
>> but does not tie
>> into the JAVA event mechanism and its associated limitations.)
>
> Unfortunately the JAIN framework expilicitly relies on the Java Event
> model, and I don't think callbacks would be accepted within the JAIN
> community.
>
>>
>>
>> Nice work and keep it rolling!  Thanks.
>
> Couldn't do it without you guys - thank you!
>
>>
>>
>> Ranga.
>>
>> Gethin Liddell wrote:
>>
>> > All,
>> >
>> > This idea of abstraction of the JAIN API is certainly a valid and
>> > interesting idea.  However, i'm a bit concerened that the proposed
>>
>> > solution of many different packages, will only seek to complicate
>> and
>> > maybe enlarge the API.
>> >
>> > I too see no reason why there is an EntityHeader etc... and i also
>> do
>> > not see any requirement for an InviteMessage, AckMessage etc...
>> >
>> > How about if the format of the API remains as is:
>> >
>> > jain.protocol.ip.sip
>> > jain.protocol.ip.sip.header
>> > jain.protocol.ip.sip.message
>> >
>> > except that the messages available in the message package
>> consisted of
>> > BasicRequest/Response, MinimalRequest/Response etc... where each
>> > message is extened in turn (e.g. Minimal extends Basic, Moderate
>> > extends Minimal etc...), of course as Chris points out it is not
>> hard
>> > to see that a combination would be required that is not provided.
>> So
>> > in the interest of flexibility, it could be possible for the user
>> to
>> > plug-in to the message class what extra headers it requires.  The
>> only
>> > issue then is that the user will have to use a "public Header
>> > getHeader(String headerName)" and then cast the header to their
>> desired
>> > header type. Either that or create their own Message class
>> > (extending the current ones) that simply does the casting
>> automatically
>> > for them.  Then after compiling, run an obfuscator on the code and
>> it
>> > will automatically extract and only extract the Message, Headers
>> and
>> > even methods that are used.
>> >
>> > This then will also cut down on the number of methods in the
>> Provider
>> > as there will be no need for the sendAck(AckMessage),
>> > sendInvite(InviteMessage) etc.. as they would be replaced by the
>> > single method sendRequest(RequestMessage).
>> >
>> > I personally see three arguments for keeping the JAIN SIP stack as
>> small
>> > as possible:
>> >
>> > 1) The first is for embedded applications where stack size has to
>> be
>> > kept to a minimum as memory is at a premium.  So if just using the
>>
>> > Basic message suffices then this will compile and run with a small
>>
>> > number of classes present from the stack.  Don't forget,
>> obfuscation
>> > will help in extracting only the Messages, Headers and even
>> methods
>> > required from a jar file but it won't do everything.
>> >
>> > 2) The second is that users may be put off or confused by the
>> sheer
>> > size and complexity of the JAIN stack.  So if only using the
>> > BasicMessage gets them on the first rung of the ladder then it is
>> a
>> > good starting point and allows them to build up to bigger and
>> better
>> > things.
>> >
>> > 3) We also have to consider who is going to implement the JAIN SIP
>>
>> > stack. If it is indeed overly complicated then no-one or a single
>> > vendor may end up implmenting the stack and thus its definition
>> and
>> > all the hard work that has gone into it is useless.
>> >
>> > On Mon, 16 Oct 2000, Chris Harris wrote:
>> > > Itamar,
>> > >
>> > > The idea of levelling the API based on what messages, headers
>> and response codes
>> > > are understood is certainly an interesting one - minimal, basic,
>> redirection,
>> > > firewall-friendly, negotiation, authentication and "full".
>> > >
>> > > jain.protocol.ip.sip
>> > > jain.protocol.ip.sip.header
>> > > jain.protocol.ip.sip.message
>> > >
>> > > could then become...
>> > >
>> > > jain.protocol.ip.sip - listener, provider, stack, general
>> classes used at all
>> > > levels
>> > > jain.protocol.ip.sip.header - contains base Header class (and
>> requestHeader,
>> > > ResponseHeader, EntityHeader, GeneralHeader)
>> > > jain.protocol.ip.sip.message - contains base Message class
>> > >
>> > > jain.protocol.ip.sip.minimal - general classes used only at this
>> level and above
>> > >
>> > > jain.protocol.ip.sip.minimal.header - headers used only at this
>> level and above
>> > > jain.protocol.ip.sip.minimal.message - messages only used at
>> this level and
>> > > above
>> > >
>> > > jain.protocol.ip.sip.basic - general classes used only at this
>> level and above
>> > > jain.protocol.ip.sip.basic.header - headers used only at this
>> level and above
>> > > jain.protocol.ip.sip.basic.message - messages used only at this
>> level and above
>> > > ...
>> > > ....
>> > > jjain.protocol.ip.sip."full" - general classes only used at this
>> level
>> > > jain.protocol.ip.sip."full".header - headers used only at this
>> level
>> > > jain.protocol.ip.sip."full".message - messages used only at this
>> level
>> > >
>> > > The API user could then pick the packages they need - say they
>> initially only
>> > > want the minimal features, but then realise they need to use
>> their application
>> > > behind a firewall - then they can simply add the
>> firewall-friendly package. The
>> > > RFC says "In general, each capability listed builds on the ones
>> above it" but it
>> > > is not hard to see that firewall-friendly and authentication may
>> be desired
>> > > without redirection for example.
>> > >
>> > > Is this what you hand in mind Itamar?
>> >
>> > --
>> > Gethin Liddell
>> > Ubiquity Software Corporation
>> >
>> > http://www.ubiquity.net
>> > mailto:gethin@ubiquity.net
>> >
>> > _______________________________________________
>> > SIP mailing list
>> > SIP@lists.bell-labs.com
>> > http://lists.bell-labs.com/mailman/listinfo/sip
>>
>> --
>> M.Ranganathan
>> NIST Advanced Networking Technologies Group,
>> 100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899.
>> Tel: 301 975 3664 Fax: 301 590 0932
>>
>> Hfæj)b? b²Ô^>X¬¶ÆÞ-YZnÇ(sm§ÿåSËlmée*¦ìr?¿?¨¥?©ÿ-+-SwèþÈ©
>

--
M.Ranganathan
NIST Advanced Networking Technologies Group,
100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899.
Tel: 301 975 3664 Fax: 301 590 0932

Hfæj)b? b²Ô^>X¬¶ÆÞ-YZnÇ(sm§ÿåSËlmée*¦ìr?¿?¨¥?©ÿ-+-SwèþÈ©

------_=_NextPart_001_01C039C4.82433630-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Oct 19 08:33:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA14985 for ; Thu, 19 Oct 2000 08:33:03 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 78AA844337; Thu, 19 Oct 2000 07:33:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 2EAAF44336 for ; Thu, 19 Oct 2000 07:32:10 -0400 (EDT) Received: from dynamicsoft.com (ip145.honxr2.ras.tele.dk [195.249.119.145]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id IAA05083; Thu, 19 Oct 2000 08:33:57 -0400 (EDT) Message-ID: <39EEE91C.F76B7BEA@dynamicsoft.com> From: Anders Kristensen Organization: dynamicsoft X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 To: Jo Hornsby Cc: Gonzalo Camarillo , SIP Subject: Re: Source Routing WAS Re: [SIP] Route learnt out of band References: <004901c039c2$ea34a050$4e34c3c1@ubiquity.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 19 Oct 2000 14:29:16 +0200 Content-Transfer-Encoding: 7bit Jo Hornsby wrote: > > > Taking a look at both threads, "outbound call routing" and "Route learnt > > out of band", I have found similarities and some differences in the > > problems they are trying to address. > > > > Basically we have the same issue: how to perform source routing using > > SIP. > > > > However, folks are speaking about two types of source routing. Using IP > > terminology, they are "loose source routing" and "strict source > > routing". > > > > In loose source routing the source wants the request to traverse a > > particular set of nodes. The request can traverse other nodes as well, > > but at least has to traverse this particular nodes. > > > > In strict source routing the source wants the request to follow a > > particular path. They request must traverse a particular set of nodes, > > and it cannot go to any other node. > > > > The "Outbound call routing" problem, where I want my request to go thru > > a certain proxy seems to me a loose source routing problem. I want the > > request to go to this outbound proxy and then I want it to be routed > > towards its destination. > > > > The semantics of the current Route header are not appropiate for this. > > > > I find the Route header more appropiate for performing strict source > > routing. That is, when the UAC knows in advance all the servers (the UAS > > included) that the request should traverse. > > I'm not sure that this is necessarily true. If you look to bis02, > we have: > 6.34.3 Request Destination > Unless this would cause a loop, any client, including > the UAC, SHOULD send the next request for this call leg > to the first Request-URI in the Route request header field. > A client MAY forward the request to a designated proxy > instead, for example, if it lacks DNS resolution capability. > If a client uses the first Route entry to route the request, > it removes it. > > Thus there is flexibility here. > > When is a proxy likely to ignore a Route directive? My initial > thoughts are when there are networking issues (it knows it has > to go via some ALG-proxy, for instance), or when there are > billing issues. But there is nothing wrong with this. > > Thus I would say that as long as a proxy is happy to receive a > request with Route headers in for an unknown call leg, things > should work out okay; it will use other proxies as necessary, > and any of these will Record-Route if they need to remain in > the signalling path. The problem I was mentioning earlier is that things break down when a proxi is NOT happy to proxy requests for unknown legs with Route headers without being able to add itself to the Record-Route and stay on the signaling path. OK, so it can always try and recourd-route, the question is whether other proxies and the UAs play along, i.e. other proxies also adds themselves to the RR even when they're already on the Route and also whether UAs updates their routes. Neither is assured by the current draft, I think (haven't checked). The distinction between loose and strict source routing seems to me useful in understanding the problem, but most of the time a UAC can't know for sure whether what it's doing is loose or strict. -- Anders Kristensen _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Oct 19 09:07:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA22437 for ; Thu, 19 Oct 2000 09:07:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id CB89F44337; Thu, 19 Oct 2000 08:07:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 15CC844336 for ; Thu, 19 Oct 2000 08:06:37 -0400 (EDT) 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 JAA10122; Thu, 19 Oct 2000 09:06:17 -0400 (EDT) Message-ID: <39EEF1CA.14CD12BB@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: clive.dellard@bt.com Cc: jdrosen@dynamicsoft.com, byerly@cisco.com, stlevy@cisco.com, jryang@cisco.com, christer.holmberg@lmf.ericsson.se, sip@lists.bell-labs.com Subject: Re: [SIP] From header to ISUP CgPN mapping References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 19 Oct 2000 09:06:18 -0400 Content-Transfer-Encoding: 7bit clive.dellard@bt.com wrote: > > Jonathan, > I understand your reluctance to add changes, however, IMHO I > do not see that it is bogus for a call originating in an IP network to be > able to provide a calling address appropriate for the terminating network. > So if the call remains in the IP environment a SIP address is provided but > if the call terminates in the PSTN an E.164 number is delivered as the > calling address. > I would welcome suggestions on how to resolve this issue. If this is to be meaningful, it has to be verifiable. Just having users stick in random telephone numbers that then pop up on caller ID boxes is not likely to be useful. Also, if the outbound gateway is my home provider (as is likely, due to billing relationships), I will have already registered with a local registrar, including with a tel: URL. This already provides this information, if desired, to the gateway. Thus, it is far from clear that a simple header is particularly helpful. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Oct 19 09:13:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA23704 for ; Thu, 19 Oct 2000 09:13:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0325144352; Thu, 19 Oct 2000 08:13:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from drago1.ubiquity.net (unknown [194.202.146.92]) by lists.bell-labs.com (Postfix) with SMTP id 0A60E44337 for ; Thu, 19 Oct 2000 08:12:49 -0400 (EDT) Received: from gecko.ubiquity.co.uk by drago1.ubiquity.net via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 19 Oct 2000 13:13:17 UT Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id OAA23407; Thu, 19 Oct 2000 14:11:07 +0100 (BST) From: "Jo Hornsby" To: "Anders Kristensen" Cc: "Gonzalo Camarillo" , "SIP" Subject: RE: Source Routing WAS Re: [SIP] Route learnt out of band Message-ID: <004c01c039ce$0b1c1590$4e34c3c1@ubiquity.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 In-Reply-To: <39EEE91C.F76B7BEA@dynamicsoft.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 19 Oct 2000 14:11:07 +0100 Content-Transfer-Encoding: 7bit > > I'm not sure that this is necessarily true. If you look to bis02, > > we have: > > 6.34.3 Request Destination > > Unless this would cause a loop, any client, including > > the UAC, SHOULD send the next request for this call leg > > to the first Request-URI in the Route request header field. > > A client MAY forward the request to a designated proxy > > instead, for example, if it lacks DNS resolution capability. > > If a client uses the first Route entry to route the request, > > it removes it. > > > > Thus there is flexibility here. > > > > When is a proxy likely to ignore a Route directive? My initial > > thoughts are when there are networking issues (it knows it has > > to go via some ALG-proxy, for instance), or when there are > > billing issues. But there is nothing wrong with this. > > > > Thus I would say that as long as a proxy is happy to receive a > > request with Route headers in for an unknown call leg, things > > should work out okay; it will use other proxies as necessary, > > and any of these will Record-Route if they need to remain in > > the signalling path. > > The problem I was mentioning earlier is that things break down when a > proxi is NOT happy to proxy requests for unknown legs with Route headers > without being able to add itself to the Record-Route and stay on the > signaling path. OK, so it can always try and recourd-route, the question > is whether other proxies and the UAs play along, i.e. other proxies also > adds themselves to the RR even when they're already on the Route and > also whether UAs updates their routes. Since neither UA has seen a Record-Route yet, I would suggest that they should have no well-defined Route for this Call (Call Leg) yet. The originating UA may well supply an initial Route list, but it should be discarded for subsequent requests, and the "normal" behaviour used. Mostly it comes down to the "if their proxy/UA doesn't support it, don't buyfrom/routewith them" approach. It's unlikely that someone is going to require routing across a disparate set of proxies which have no real relation to each other (I would guess typically one is going to want to route through, say their "home" proxy, and their favourite ASP proxy, for instance). > Neither is assured by the current > draft, I think (haven't checked). UAs should not update their Routes (save noting new Contact addresses); the only thing that proxies continually reinserting Record-Route s buys is recovery after a crash. > The distinction between loose and strict source routing seems to me > useful in understanding the problem, but most of the time a UAC can't > know for sure whether what it's doing is loose or strict. Agreed. The question is: does this really matter if the request visits all the desired proxies in both cases? - Jo. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Oct 19 09:31:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA27137 for ; Thu, 19 Oct 2000 09:31:03 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 841DC44348; Thu, 19 Oct 2000 08:31:06 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id A3BFB44337 for ; Thu, 19 Oct 2000 08:30:22 -0400 (EDT) Received: from dynamicsoft.com ([212.120.151.156]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id JAA05631; Thu, 19 Oct 2000 09:32:04 -0400 (EDT) Message-ID: <39EEF762.A8C8B6FA@dynamicsoft.com> From: Chris Harris Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Itamar Gilad Cc: sip@lists.bell-labs.com, discussion@sipforum.org, jainsip@Sun.COM Subject: Re: [SIPFORUM] Re: [SIP] JAIN SIP Specification References: Content-Type: multipart/alternative; boundary="------------F4D0E689F4F9BA5ABB1536E0" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 19 Oct 2000 14:30:10 +0100 --------------F4D0E689F4F9BA5ABB1536E0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi Itamar, Sure - after all an application can completely ignore the transaction ids given to it by the Provider, and use the send methods that don't take transaction id parameters - the Provider has to cover both types of application. Note that I don't necessarily think an application can't have an object to represent a transaction, just that such an object must operate through the Provider - since the Provider is supposed to be the applications only access to the SIP stack. So you could have a client transaction object containing the request sent returned by the Provider, and have a cancel method on it - that calls the sendCancel method on the Provider etc... But I'm not sure how useful this would be - you are also forcing an application that is not interested in transactions to extract messages from transaction objects. Then again, we could always define two JainSipListener subtypes - JainSipMessageListener and JainSipTransactionListener...this might be a good idea - then we can have an application indicate to the Provider whether it is interested in transactions - if it isn't it just receives Message objects, and if it is it receives Transaction objects (incorporating the associated Messages) The Transaction objects contain a transaction id, and can by ClientTransaction or ServerTransaction, and their methods can call the Provider's methods with the transaction id parameters. Opinions? I think incorporating call-legs and calls into the API is asking too much of an API that deals with messages and transactions - unless we create a JainSipCall(Leg)Listener...but now we're mandating that the inderlying implementation has to keep call state...and above we have to map JCC onto these...that could get very messy! Chris Itamar Gilad wrote: > Hi Chris,It could be argued that it makes just as much sense for the > Provider to identify also the Call-Leg and Call. Still I think I > understand what you are after and I agree that this might help > applications that for some reason want to know about transaction > 'ids', but don't want to work with transaction objects. Regards > Itamar > > -----Original Message----- > From: Chris Harris [mailto:charris@dynamicsoft.com] > Sent: Thu, October 19, 2000 12:11 PM > To: sip@lists.bell-labs.com > Cc: discussion@sipforum.org; jainsip@Sun.COM > Subject: Re: [SIPFORUM] Re: [SIP] JAIN SIP Specification > > Hi Itamar, > > I can't really think of any applications other than a > stateless proxy that don't care about transactions. And > since stateless proxies are really just SIP routers and need > maximum performance, I can't really see anyone implementing > them with JAIN SIP. > > I think any application that does anything interesting needs > to know about transactions, so the the JAIN SIP API should > include some means of identifying transactions or > transaction control. But this has to fit in with the > Listener/Provider event model, so we can't hand a Listener a > transaction object that they can work with directly - we > need to give an application access to transactions through > the Provider. I thought a transaction id would be the > simplest way to achieve this. Do you have any suggestions > for improving transaction control for the event model? > > Chris > > Itamar Gilad wrote: > > > No, that's not it. The application uses a stack to do all > > of this. The stack should export a message-related API > > like the one defined in the JAIN SIP specification you > > presented. The stack should also export interfaces for > > Call control and Transaction control. It seems more > > logical for the application to use a transaction object > > which handles messaging and notifies it whenever a message > > belonging to this transaction is received rather then > > having a message object that tells it which transaction it > > belongs too. Stateless proxies for example would use only > > the message layer and they don't care at all about > > transactions. I'm Sorry to be so picky, but I just think > > that this makes for a cleaner design both in the > > application and in the stack. Our experience with our SIP > > stack proves that this model works fine.Itamar > > > > -----Original Message----- > > From: Chris Harris > > [mailto:charris@dynamicsoft.com] > > Sent: Wed, October 18, 2000 8:18 PM > > To: discussion@sipforum.org > > Cc: Itamar Gilad; 'Bobby Sardana'; > > mranga@nist.gov; sip@lists.bell-labs.com; > > jainsip@Sun.COM > > Subject: Re: [SIPFORUM] Re: [SIP] JAIN SIP > > Specification > > OK - so if an application just sends a message > > to the Provider, it has to check all response > > messages to see if they match - this is so messy > > for an application. What if a response message > > never arrives - how should the Provider inform > > the application of a timeout? Call a timeout > > method and pass the request message back? > > > > Itamar Gilad wrote: > > > > > Chris, I agree that few SIP applications would > > > like to bother with transaction mapping. This > > > is clearly the responsibility of the stack as > > > is transaction management in general. However > > > in a previous thread you explained that the > > > issue of managing call and transaction state is > > > outside the scope of this API specification, > > > which led me to believe that the goal is to > > > define message-related functionality. I think > > > that injecting transaction keys into the mix is > > > crossing the lines you defined. Regards, > > > Itamar > > > > > > -----Original Message----- > > > From: Chris Harris > > > [mailto:charris@dynamicsoft.com] > > > Sent: Wed, October 18, 2000 7:44 PM > > > To: Itamar Gilad > > > Cc: 'Bobby Sardana'; > > > discussion@sipforum.org; > > > mranga@nist.gov; > > > sip@lists.bell-labs.com; > > > jainsip@Sun.COM > > > Subject: Re: [SIPFORUM] Re: [SIP] > > > JAIN SIP Specification > > > Itamar, > > > > > > It is for the very reason that > > > identifying a transaction from a > > > message is not a trivial matter that > > > I wanted to put the transaction > > > handling inside the JainSipProvider. > > > I don't think the spec should just > > > deal with just the message layer. How > > > many people are going to write JAIN > > > SIP applications if they have to > > > implement their own transaction keys? > > > I'd imagine very few. > > > > > > Regards, > > > Chris > > > > > > Itamar Gilad wrote: > > > > > > > Hi again Chris,I'd like to > > > > re-emphasize what Bobby says > > > > below. The JAIN SIP specification > > > > presented here seems to deal just > > > > with the "message layer" i.e. > > > > parsing, encoding, message and > > > > message part containers. I'd like > > > > to join those who commend the fine > > > > and comprehensive work done. > > > > However, this layer has nothing to > > > > do with transactions and their > > > > state. It would be a mistake to > > > > rely on it to retain > > > > 'transaction-ids' and associate > > > > messages to them (please correct me > > > > if I'm misinterpreting your > > > > meaning). Note that identifying a > > > > transaction from a message is not a > > > > trivial matter and continuously > > > > more message fields are added to > > > > the "transaction key" in order to > > > > deal with spiraling, merging etc. A > > > > more straight-forward approach > > > > would be to put this functionality > > > > in the "transaction layer" where > > > > transaction objects live and make a > > > > clean separation between the two > > > > layers.Regards Itamar > > > > -----Original Message----- > > > > From: Bobby Sardana > > > > [mailto:bobby.sardana@mobilerain.com] > > > > > > > > Sent: Wed, October 18, 2000 6:39 PM > > > > > > > > To: discussion@sipforum.org > > > > Cc: mranga@nist.gov; > > > > sip@lists.bell-labs.com; > > > > jainsip@sun.com > > > > Subject: Re: [SIPFORUM] Re: [SIP] > > > > JAIN SIP Specification > > > > > > > > > > > > Greetings Chris: > > > > > > > > Just to add a pointer to > > > > this thread: > > > > > > > > Maintaining trasaction > > > > state is an application > > > > level functionality and > > > > *shouldn't* be > > > > implemented in the base > > > > stack. For applications > > > > like state oriented proxy > > > > server, the JAIN SIP can > > > > provide enough hooks for > > > > event delivery but the > > > > state has to be > > > > maintained by the proxy > > > > server. > > > > > > > > Pleas keep up the good > > > > work. It is really > > > > appreciated. > > > > > > > > Regards, > > > > > > > > Bobby.Sa > > > > dana@mobilerain.com > > > > > > > > Chris Harris wrote: > > > > > > > > > "M. Ranganathan" wrote: > > > > > > > > > >> Hi Chris, > > > > >> > > > > >> Thanks for replying so > > > > >> promptly (I am sure > > > > >> you are flooded with > > > > >> email ). > > > > > > > > > > I get one or two :) > > > > > > > > > >> > > > > >> As you pointed out, I > > > > >> suppose we cannot do > > > > >> away with making > > > > >> Messages > > > > >> into classes because > > > > >> of the tie-in with > > > > >> java events > > > > >> (unfortunately) but > > > > >> I still like the > > > > >> notion of being able > > > > >> to specify interfaces > > > > >> where ever > > > > >> possible. > > > > > > > > > > I see where you're > > > > > coming from alright, > > > > > and I suppose changing > > > > > header classes into > > > > > interfaces, could fit > > > > > in with Gethin's > > > > > proposal nicely? > > > > > > > > > >> > > > > >> I dont quite follow > > > > >> the motivation behind > > > > >> the following design > > > > >> decision (excerpted > > > > >> from your reply): > > > > >> > > > > >> Maybe I've > > > > >> misunderstood what > > > > >> you're saying - but a > > > > >> JAIN SIP > > > > >> implementation is only > > > > >> stateless when it > > > > >> comes to call state. > > > > >> The > > > > >> JainSipProvider > > > > >> implementation must > > > > >> maintain transaction > > > > >> state - it > > > > >> simply exposes a > > > > >> reference to a > > > > >> transaction via the > > > > >> transaction id for > > > > >> the convenience of the > > > > >> JainSipListener. The > > > > >> service does not have > > > > >> total > > > > >> control over > > > > >> transacton state - the > > > > >> stack implementation > > > > >> does. > > > > >> > > > > >> It appears that I have > > > > >> indded mis-understood > > > > >> the architecture. Why > > > > >> > > > > >> should the above be > > > > >> so? Can one not rely > > > > >> on the JainSipListener > > > > >> to keep > > > > >> transaction state > > > > >> also, thereby making > > > > >> the stack simply a way > > > > >> of > > > > >> recognising messages > > > > >> and triggering event > > > > >> handlers on the basis > > > > >> of > > > > >> message type. This > > > > >> would (IMHO) be a > > > > >> cleaner model yet. > > > > >> That way, we > > > > >> can do away with > > > > >> transaction > > > > >> identifiers being > > > > >> passed back and forth > > > > >> and > > > > >> keep all of this > > > > >> information in the > > > > >> handler. ( You may > > > > >> have to extend > > > > >> the architecture > > > > >> somewhat to deal with > > > > >> timeouts and failures > > > > >> so that the > > > > >> handler knows about > > > > >> transaction failure.) > > > > >> In any case, if this > > > > >> is not a > > > > >> viable idea, I would > > > > >> be grateful if you can > > > > >> explain why not (or > > > > >> point me > > > > >> to the portion of the > > > > >> spec that explains why > > > > >> not) so I can get a > > > > >> better > > > > >> understanding. > > > > > > > > > > It would be cleaner > > > > > model, and personally I > > > > > am in total agreement > > > > > with you - but it means > > > > > the application is > > > > > forced to maintain > > > > > transaction state, > > > > > match up headers - > > > > > which has been said > > > > > places too much of a > > > > > burden on applications. > > > > > How about finding a way > > > > > to let the application > > > > > choose whether or not > > > > > it wants to keep > > > > > transaction state? > > > > > > > > > >> > > > > >> > > > > >> Regards, > > > > >> > > > > >> Ranga. > > > > >> > > > > >> Chris Harris wrote: > > > > >> > > > > >> > Hi Ranga, > > > > >> > > > > > >> > Response below... > > > > >> > > > > > >> > Chris > > > > >> > > > > > >> > "M. Ranganathan" > > > > >> wrote: > > > > >> > > > > > >> >> JAIN-SIP is a > > > > >> groovy idea. Hats off > > > > >> to the whole concept > > > > >> and many > > > > >> >> thanks to Chris and > > > > >> > > > > >> >> the JAIN-SIP team > > > > >> for putting together a > > > > >> spec and more flower > > > > >> power > > > > >> >> to them :-) . In > > > > >> >> particular I like > > > > >> the notion of treating > > > > >> UAS, Redirect and > > > > >> Proxy > > > > >> >> servers as merely > > > > >> >> special cases of > > > > >> the general notion of > > > > >> Services and the idea > > > > >> of > > > > >> >> unifying these > > > > >> >> notions with an > > > > >> event mechanism and > > > > >> event handlers. > > > > >> Second, I like > > > > >> >> the idea of > > > > >> >> separation between > > > > >> a stateless event > > > > >> -oriented "stack" and > > > > >> a bunch > > > > >> >> of event > > > > >> >> handlers that are > > > > >> triggered by the stack > > > > >> with all state > > > > >> (including > > > > >> >> transaction > > > > >> >> state) being > > > > >> separated from the > > > > >> event stack via the > > > > >> JAIN-SIP mapping > > > > >> >> layer if you > > > > >> >> will. ( Correct me > > > > >> if I wax poetic but > > > > >> have the wrong > > > > >> >> understanding....) > > > > >> > > > > > >> >> > > > > >> >> > > > > >> >> I hope I will not > > > > >> be viewed as being too > > > > >> critical, but I would > > > > >> > > > > >> >> like to go one > > > > >> step > > > > >> >> further than what > > > > >> Gethin is > > > > >> suggesting. I am all > > > > >> for using > > > > >> >> interfaces as much > > > > >> as > > > > >> >> possible and > > > > >> leaving class > > > > >> hierarchy definitions > > > > >> to implemeters. > > > > >> >> Defining class > > > > >> >> hierarchies almost > > > > >> lays out an > > > > >> implementation and > > > > >> involves > > > > >> >> considerable rework > > > > >> for > > > > >> >> those who have a > > > > >> working java-based > > > > >> stack, but have not > > > > >> used the > > > > >> >> same classes. OK it > > > > >> > > > > >> >> is just a matter of > > > > >> labor to map things to > > > > >> the JAIN-SIP class > > > > >> >> hierarchy but it > > > > >> IS a > > > > >> >> dis-incentive. > > > > >> >> > > > > >> >> 1. Lets use > > > > >> interfaces for all > > > > >> messages rather than > > > > >> actually define > > > > >> >> class > > > > >> >> hierarchies ( yes > > > > >> Chris has pointed out > > > > >> the historical > > > > >> precedent > > > > >> >> behind actually > > > > >> >> defining class > > > > >> hierarchies for > > > > >> messages. IMHO, there > > > > >> has to be a > > > > >> >> more compelling > > > > >> >> reason than that.) > > > > >> > > > > > >> > I suppose all > > > > >> classes could be > > > > >> turned into > > > > >> interfaces, except for > > > > >> the > > > > >> > Message classes > > > > >> which must extend > > > > >> java.util.EventObject > > > > >> to fit into > > > > >> > the JAIN framework. > > > > >> > > > > > >> >> > > > > >> >> > > > > >> >> 2. The tie-in with > > > > >> the JAVA event > > > > >> mechanism has > > > > >> necessitated the > > > > >> >> explicit definition > > > > >> > > > > >> >> of class > > > > >> hierarchies in certain > > > > >> places. Why not use > > > > >> callbacks > > > > >> >> instead and do away > > > > >> > > > > >> >> with this > > > > >> dependency as well? > > > > >> (Basically the same > > > > >> thing as events > > > > >> >> but does not tie > > > > >> >> into the JAVA event > > > > >> mechanism and its > > > > >> associated > > > > >> limitations.) > > > > >> > > > > > >> > Unfortunately the > > > > >> JAIN framework > > > > >> expilicitly relies on > > > > >> the Java Event > > > > >> > model, and I don't > > > > >> think callbacks would > > > > >> be accepted within the > > > > >> JAIN > > > > >> > community. > > > > >> > > > > > >> >> > > > > >> >> > > > > >> >> Nice work and keep > > > > >> it rolling! Thanks. > > > > >> > > > > > >> > Couldn't do it > > > > >> without you guys - > > > > >> thank you! > > > > >> > > > > > >> >> > > > > >> >> > > > > >> >> Ranga. > > > > >> >> > > > > >> >> Gethin Liddell > > > > >> wrote: > > > > >> >> > > > > >> >> > All, > > > > >> >> > > > > > >> >> > This idea of > > > > >> abstraction of the > > > > >> JAIN API is certainly > > > > >> a valid and > > > > >> >> > interesting > > > > >> idea. However, i'm a > > > > >> bit concerened that > > > > >> the proposed > > > > >> >> > > > > >> >> > solution of many > > > > >> different packages, > > > > >> will only seek to > > > > >> complicate > > > > >> >> and > > > > >> >> > maybe enlarge the > > > > >> API. > > > > >> >> > > > > > >> >> > I too see no > > > > >> reason why there is an > > > > >> EntityHeader etc... > > > > >> and i also > > > > >> >> do > > > > >> >> > not see any > > > > >> requirement for an > > > > >> InviteMessage, > > > > >> AckMessage etc... > > > > >> >> > > > > > >> >> > How about if the > > > > >> format of the API > > > > >> remains as is: > > > > >> >> > > > > > >> >> > > > > > >> jain.protocol.ip.sip > > > > >> >> > > > > > >> jain.protocol.ip.sip.header > > > > >> > > > > >> >> > > > > > >> jain.protocol.ip.sip.message > > > > >> > > > > >> >> > > > > > >> >> > except that the > > > > >> messages available in > > > > >> the message package > > > > >> >> consisted of > > > > >> >> > > > > > >> BasicRequest/Response, > > > > >> MinimalRequest/Response > > > > >> etc... where each > > > > >> >> > message is > > > > >> extened in turn (e.g. > > > > >> Minimal extends Basic, > > > > >> Moderate > > > > >> >> > extends Minimal > > > > >> etc...), of course as > > > > >> Chris points out it is > > > > >> not > > > > >> >> hard > > > > >> >> > to see that a > > > > >> combination would be > > > > >> required that is not > > > > >> provided. > > > > >> >> So > > > > >> >> > in the interest > > > > >> of flexibility, it > > > > >> could be possible for > > > > >> the user > > > > >> >> to > > > > >> >> > plug-in to the > > > > >> message class what > > > > >> extra headers it > > > > >> requires. The > > > > >> >> only > > > > >> >> > issue then is > > > > >> that the user will > > > > >> have to use a "public > > > > >> Header > > > > >> >> > getHeader(String > > > > >> headerName)" and then > > > > >> cast the header to > > > > >> their > > > > >> >> desired > > > > >> >> > header type. > > > > >> Either that or create > > > > >> their own Message > > > > >> class > > > > >> >> > (extending the > > > > >> current ones) that > > > > >> simply does the > > > > >> casting > > > > >> >> automatically > > > > >> >> > for them. Then > > > > >> after compiling, run > > > > >> an obfuscator on the > > > > >> code and > > > > >> >> it > > > > >> >> > will > > > > >> automatically extract > > > > >> and only extract the > > > > >> Message, Headers > > > > >> >> and > > > > >> >> > even methods that > > > > >> are used. > > > > >> >> > > > > > >> >> > This then will > > > > >> also cut down on the > > > > >> number of methods in > > > > >> the > > > > >> >> Provider > > > > >> >> > as there will be > > > > >> no need for the > > > > >> sendAck(AckMessage), > > > > >> >> > > > > > >> sendInvite(InviteMessage) > > > > >> etc.. as they would be > > > > >> replaced by the > > > > >> >> > single method > > > > >> sendRequest(RequestMessage). > > > > >> > > > > >> >> > > > > > >> >> > I personally see > > > > >> three arguments for > > > > >> keeping the JAIN SIP > > > > >> stack as > > > > >> >> small > > > > >> >> > as possible: > > > > >> >> > > > > > >> >> > 1) The first is > > > > >> for embedded > > > > >> applications where > > > > >> stack size has to > > > > >> >> be > > > > >> >> > kept to a minimum > > > > >> as memory is at a > > > > >> premium. So if just > > > > >> using the > > > > >> >> > > > > >> >> > Basic message > > > > >> suffices then this > > > > >> will compile and run > > > > >> with a small > > > > >> >> > > > > >> >> > number of classes > > > > >> present from the > > > > >> stack. Don't forget, > > > > >> >> obfuscation > > > > >> >> > will help in > > > > >> extracting only the > > > > >> Messages, Headers and > > > > >> even > > > > >> >> methods > > > > >> >> > required from a > > > > >> jar file but it won't > > > > >> do everything. > > > > >> >> > > > > > >> >> > 2) The second is > > > > >> that users may be put > > > > >> off or confused by the > > > > >> > > > > >> >> sheer > > > > >> >> > size and > > > > >> complexity of the JAIN > > > > >> stack. So if only > > > > >> using the > > > > >> >> > BasicMessage gets > > > > >> them on the first rung > > > > >> of the ladder then it > > > > >> is > > > > >> >> a > > > > >> >> > good starting > > > > >> point and allows them > > > > >> to build up to bigger > > > > >> and > > > > >> >> better > > > > >> >> > things. > > > > >> >> > > > > > >> >> > 3) We also have > > > > >> to consider who is > > > > >> going to implement the > > > > >> JAIN SIP > > > > >> >> > > > > >> >> > stack. If it is > > > > >> indeed overly > > > > >> complicated then > > > > >> no-one or a single > > > > >> >> > vendor may end up > > > > >> implmenting the stack > > > > >> and thus its > > > > >> definition > > > > >> >> and > > > > >> >> > all the hard work > > > > >> that has gone into it > > > > >> is useless. > > > > >> >> > > > > > >> >> > On Mon, 16 Oct > > > > >> 2000, Chris Harris > > > > >> wrote: > > > > >> >> > > Itamar, > > > > >> >> > > > > > > >> >> > > The idea of > > > > >> levelling the API > > > > >> based on what > > > > >> messages, headers > > > > >> >> and response codes > > > > >> >> > > are understood > > > > >> is certainly an > > > > >> interesting one - > > > > >> minimal, basic, > > > > >> >> redirection, > > > > >> >> > > > > > > >> firewall-friendly, > > > > >> negotiation, > > > > >> authentication and > > > > >> "full". > > > > >> >> > > > > > > >> >> > > > > > > >> jain.protocol.ip.sip > > > > >> >> > > > > > > >> jain.protocol.ip.sip.header > > > > >> > > > > >> >> > > > > > > >> jain.protocol.ip.sip.message > > > > >> > > > > >> >> > > > > > > >> >> > > could then > > > > >> become... > > > > >> >> > > > > > > >> >> > > > > > > >> jain.protocol.ip.sip - > > > > >> listener, provider, > > > > >> stack, general > > > > >> >> classes used at all > > > > >> > > > > >> >> > > levels > > > > >> >> > > > > > > >> jain.protocol.ip.sip.header > > > > >> - contains base Header > > > > >> class (and > > > > >> >> requestHeader, > > > > >> >> > > ResponseHeader, > > > > >> EntityHeader, > > > > >> GeneralHeader) > > > > >> >> > > > > > > >> jain.protocol.ip.sip.message > > > > >> - contains base > > > > >> Message class > > > > >> >> > > > > > > >> >> > > > > > > >> jain.protocol.ip.sip.minimal > > > > >> - general classes used > > > > >> only at this > > > > >> >> level and above > > > > >> >> > > > > > > >> >> > > > > > > >> jain.protocol.ip.sip.minimal.header > > > > >> - headers used only at > > > > >> this > > > > >> >> level and above > > > > >> >> > > > > > > >> jain.protocol.ip.sip.minimal.message > > > > >> - messages only used > > > > >> at > > > > >> >> this level and > > > > >> >> > > above > > > > >> >> > > > > > > >> >> > > > > > > >> jain.protocol.ip.sip.basic > > > > >> - general classes used > > > > >> only at this > > > > >> >> level and above > > > > >> >> > > > > > > >> jain.protocol.ip.sip.basic.header > > > > >> - headers used only at > > > > >> this > > > > >> >> level and above > > > > >> >> > > > > > > >> jain.protocol.ip.sip.basic.message > > > > >> - messages used only > > > > >> at this > > > > >> >> level and above > > > > >> >> > > ... > > > > >> >> > > .... > > > > >> >> > > > > > > >> jjain.protocol.ip.sip."full" > > > > >> - general classes only > > > > >> used at this > > > > >> >> level > > > > >> >> > > > > > > >> jain.protocol.ip.sip."full".header > > > > >> - headers used only at > > > > >> this > > > > >> >> level > > > > >> >> > > > > > > >> jain.protocol.ip.sip."full".message > > > > >> - messages used only > > > > >> at this > > > > >> >> level > > > > >> >> > > > > > > >> >> > > The API user > > > > >> could then pick the > > > > >> packages they need - > > > > >> say they > > > > >> >> initially only > > > > >> >> > > want the > > > > >> minimal features, but > > > > >> then realise they need > > > > >> to use > > > > >> >> their application > > > > >> >> > > behind a > > > > >> firewall - then they > > > > >> can simply add the > > > > >> >> firewall-friendly > > > > >> package. The > > > > >> >> > > RFC says "In > > > > >> general, each > > > > >> capability listed > > > > >> builds on the ones > > > > >> >> above it" but it > > > > >> >> > > is not hard to > > > > >> see that > > > > >> firewall-friendly and > > > > >> authentication may > > > > >> >> be desired > > > > >> >> > > without > > > > >> redirection for > > > > >> example. > > > > >> >> > > > > > > >> >> > > Is this what > > > > >> you hand in mind > > > > >> Itamar? > > > > >> >> > > > > > >> >> > -- > > > > >> >> > Gethin Liddell > > > > >> >> > Ubiquity Software > > > > >> Corporation > > > > >> >> > > > > > >> >> > > > > > >> http://www.ubiquity.net > > > > >> > > > > >> >> > > > > > >> mailto:gethin@ubiquity.net > > > > >> > > > > >> >> > > > > > >> >> > > > > > >> _______________________________________________ > > > > >> > > > > >> >> > SIP mailing list > > > > >> >> > > > > > >> SIP@lists.bell-labs.com > > > > >> > > > > >> >> > > > > > >> http://lists.bell-labs.com/mailman/listinfo/sip > > > > >> > > > > >> >> > > > > >> >> -- > > > > >> >> M.Ranganathan > > > > >> >> NIST Advanced > > > > >> Networking > > > > >> Technologies Group, > > > > >> >> 100 Bureau Drive, > > > > >> Stop 8920, > > > > >> Gaithersburg, MD > > > > >> 20899. > > > > >> >> Tel: 301 975 3664 > > > > >> Fax: 301 590 0932 > > > > >> >> > > > > >> >> Hfæj)b? > > > > >> b²Ô^>X¬¶ÆÞ-YZnÇ(sm§ÿåSËlmée*¦ìr?¿?¨¥?©ÿ-+-SwèþÈ© > > > > >> > > > > >> > > > > > >> > > > > >> -- > > > > >> M.Ranganathan > > > > >> NIST Advanced > > > > >> Networking > > > > >> Technologies Group, > > > > >> 100 Bureau Drive, Stop > > > > >> 8920, Gaithersburg, MD > > > > >> 20899. > > > > >> Tel: 301 975 3664 Fax: > > > > >> 301 590 0932 > > > > >> > > > > >> Hfæj)b? > > > > >> b²Ô^>X¬¶ÆÞ-YZnÇ(sm§ÿåSËlmée*¦ìr?¿?¨¥?©ÿ-+-SwèþÈ© > > > > > --------------F4D0E689F4F9BA5ABB1536E0 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Itamar,

Sure - after all an application can completely ignore the transaction ids given to it by the Provider, and use the send methods that don't take transaction id parameters - the Provider has to cover both types of application.

Note that I don't necessarily think an application can't have an object to represent a transaction, just that such an object must operate through the Provider - since the Provider is supposed to be the applications only access to the SIP stack. So you could have a client transaction object containing the request sent returned by the Provider, and have a cancel method on it - that calls the sendCancel method on the Provider etc... But I'm not sure how useful this would be - you are also forcing an application that is not interested in transactions to extract messages from transaction objects.

Then again, we could always define two JainSipListener subtypes - JainSipMessageListener and JainSipTransactionListener...this might be a good idea - then we can have an application indicate to the Provider whether it is interested in transactions - if it isn't it just receives Message objects, and if it is it receives Transaction objects (incorporating the associated Messages) The Transaction objects contain a transaction id, and can by ClientTransaction or ServerTransaction, and their methods can call the Provider's methods with the transaction id parameters. Opinions?

I think incorporating call-legs and calls into the API is asking too much of an API that deals with messages and transactions - unless we create a JainSipCall(Leg)Listener...but now we're mandating that the inderlying implementation has to keep call state...and above we have to map JCC onto these...that could get very messy!

Chris

Itamar Gilad wrote:

 Hi Chris,It could be argued that it makes just as much sense for the Provider to identify also the Call-Leg and Call. Still I think I understand what you are after and I agree that this might help applications that for some reason want to know about transaction 'ids', but don't want to work with transaction objects. Regards   Itamar 
-----Original Message-----
From: Chris Harris [mailto:charris@dynamicsoft.com]
Sent: Thu, October 19, 2000 12:11 PM
To: sip@lists.bell-labs.com
Cc: discussion@sipforum.org; jainsip@Sun.COM
Subject: Re: [SIPFORUM] Re: [SIP] JAIN SIP Specification
 
Hi Itamar,

I can't really think of any applications other than a stateless proxy that don't care about transactions. And since stateless proxies are really just SIP routers and need maximum performance, I can't really see anyone implementing them with JAIN SIP.

I think any application that does anything interesting needs to know about transactions, so the the JAIN SIP API should include some means of identifying transactions or transaction control. But this has to fit in with the Listener/Provider event model, so we can't hand a Listener a transaction object that they can work with directly - we need to give an application access to transactions through the Provider. I thought a transaction id would be the simplest way to achieve this. Do you have any suggestions for improving transaction control for the event model?

Chris

Itamar Gilad wrote:

No, that's not it.  The application uses a stack to do all of this.  The stack should export a message-related API like the one defined in the JAIN SIP specification you presented.  The stack should also export interfaces for Call control and Transaction control.  It seems more logical for the application to use a transaction object which handles messaging and notifies it whenever a message belonging to this transaction is received rather then having a message object that tells it which transaction it belongs too.  Stateless proxies for example would use only the message layer and they don't care at all about transactions. I'm Sorry to be so picky, but I just think that this makes for a cleaner design both in the application and in the stack.  Our experience with our SIP stack proves that this model works fine.Itamar
-----Original Message-----
From: Chris Harris [mailto:charris@dynamicsoft.com]
Sent: Wed, October 18, 2000 8:18 PM
To: discussion@sipforum.org
Cc: Itamar Gilad; 'Bobby Sardana'; mranga@nist.gov; sip@lists.bell-labs.com; jainsip@Sun.COM
Subject: Re: [SIPFORUM] Re: [SIP] JAIN SIP Specification
OK - so if an application just sends a message to the Provider, it has to check all response messages to see if they match - this is so messy for an application. What if a response message never arrives - how should the Provider inform the application of a timeout? Call a timeout method and pass the request message back?

Itamar Gilad wrote:

 Chris, I agree that few SIP applications would like to bother with transaction mapping.  This is clearly the responsibility of the stack as is transaction management in general. However in a previous thread you explained that the issue of managing call and transaction state is outside the scope of this API specification, which led me to believe that the goal is to define message-related functionality. I think that injecting transaction keys into the mix is crossing the lines you defined. Regards,  Itamar
-----Original Message-----
From: Chris Harris [mailto:charris@dynamicsoft.com]
Sent: Wed, October 18, 2000 7:44 PM
To: Itamar Gilad
Cc: 'Bobby Sardana'; discussion@sipforum.org; mranga@nist.gov; sip@lists.bell-labs.com; jainsip@Sun.COM
Subject: Re: [SIPFORUM] Re: [SIP] JAIN SIP Specification
Itamar,

It is for the very reason that identifying a transaction from a message is not a trivial matter that I wanted to put the transaction handling inside the JainSipProvider. I don't think the spec should just deal with just the message layer. How many people are going to write JAIN SIP applications if they have to implement their own transaction keys? I'd imagine very few.

Regards,
Chris

Itamar Gilad wrote:

Hi again Chris,I'd like to re-emphasize what Bobby says below.  The JAIN SIP specification presented here seems to deal just with the "message layer" i.e. parsing, encoding, message and message part containers.  I'd like to join those who commend the fine and comprehensive work done.  However, this layer has nothing to do with transactions and their state.  It would be a mistake to rely on it to retain 'transaction-ids' and associate messages to them (please correct me if I'm misinterpreting your meaning). Note that identifying a transaction from a message is not a trivial matter and continuously more message fields are added to the "transaction key" in order to deal with spiraling, merging etc. A more straight-forward approach would be to put this functionality in the "transaction layer" where transaction objects live and make a clean separation between the two layers.Regards Itamar
-----Original Message-----
From: Bobby Sardana [mailto:bobby.sardana@mobilerain.com]
Sent: Wed, October 18, 2000 6:39 PM
To: discussion@sipforum.org
Cc: mranga@nist.gov; sip@lists.bell-labs.com; jainsip@sun.com
Subject: Re: [SIPFORUM] Re: [SIP] JAIN SIP Specification
 
Greetings Chris:

Just to add a pointer to this thread:

Maintaining trasaction state is an application level functionality and *shouldn't* be implemented in the base stack. For applications like state oriented proxy server, the JAIN SIP can provide enough hooks for event delivery but the state has to be maintained by the proxy server.

Pleas keep up the good work. It is really appreciated.

Regards,

Bobby.Sardana@mobilerain.com

Chris Harris wrote:

"M. Ranganathan" wrote:
Hi Chris,

Thanks for replying so promptly (I am sure you are flooded with email ).

I get one or two :)
 
As you pointed out, I suppose we cannot do away with making Messages
into classes because of the tie-in with java events (unfortunately) but
I still like the notion of being able to specify  interfaces where ever
possible.
I see where you're coming from alright, and I suppose changing header classes into interfaces, could fit in with Gethin's proposal nicely?
 
 I dont quite follow  the motivation behind the following design
decision (excerpted from your reply):

Maybe I've misunderstood what you're saying - but a JAIN SIP
implementation is only stateless when it comes to call state. The
JainSipProvider implementation must maintain transaction state - it
simply exposes a reference to a transaction via the transaction id for
the convenience of the JainSipListener. The service does not have total
control over transacton state - the stack implementation does.

It appears that I have indded mis-understood the architecture.  Why
should the above be so? Can one not rely on the JainSipListener to keep
transaction state also, thereby making the stack simply a way of
recognising messages and triggering  event handlers on the basis of
message type. This would (IMHO) be a cleaner model yet.    That way,  we
can do away with transaction identifiers being passed back and forth and
keep all of this information in the handler.  ( You may have to extend
the architecture somewhat to deal with timeouts and failures so that the
handler knows about transaction failure.) In any case, if this is not a
viable idea, I would be grateful if you can explain why not (or point me
to the portion of the spec that explains why not) so I can get a better
understanding.

It would be cleaner model, and personally I am in total agreement with you - but it means the application is forced to maintain transaction state, match up headers - which has been said places too much of a burden on applications. How about finding a way to let the application choose whether or not it wants to keep transaction state?
 

Regards,

Ranga.

Chris Harris wrote:

> Hi Ranga,
>
> Response below...
>
> Chris
>
> "M. Ranganathan" wrote:
>
>> JAIN-SIP is a groovy idea. Hats off to the whole concept and many
>> thanks to Chris and
>> the JAIN-SIP team for putting together a spec and more flower power
>> to them :-) .  In
>> particular I like the notion of treating UAS,  Redirect and Proxy
>> servers as merely
>> special cases of the general notion of Services and  the idea of
>> unifying these
>> notions with an event mechanism and  event handlers.  Second, I like
>> the idea of
>> separation between a  stateless  event -oriented "stack" and a bunch
>> of event
>> handlers that are triggered by the stack with all state (including
>> transaction
>> state) being separated from the event stack via the JAIN-SIP mapping
>> layer if you
>> will.  ( Correct me if I  wax poetic but have the wrong
>> understanding....)
>
>>
>>
>> I hope I  will not be viewed as being too critical,  but I would
>> like to go  one step
>> further than what Gethin is suggesting.   I am all for using
>> interfaces as much as
>> possible and leaving class hierarchy definitions to implemeters.
>> Defining class
>> hierarchies almost lays out an implementation and involves
>> considerable rework for
>> those who have a working java-based stack, but have not used the
>> same classes. OK it
>> is just a matter of labor to map things to the JAIN-SIP class
>> hierarchy but it  IS a
>> dis-incentive.
>>
>> 1. Lets use interfaces for all messages rather than actually define
>> class
>> hierarchies  ( yes Chris has pointed out the historical precedent
>> behind actually
>> defining class hierarchies for messages. IMHO,  there has to be a
>> more compelling
>> reason than that.)
>
> I suppose all classes could be turned into interfaces, except for the
> Message classes which must extend java.util.EventObject to fit into
> the JAIN framework.
>
>>
>>
>> 2. The tie-in with the JAVA event mechanism has necessitated the
>> explicit definition
>> of class hierarchies in certain places.  Why not use callbacks
>> instead and do away
>> with this dependency as well?  (Basically the same thing as events
>> but does not tie
>> into the JAVA event mechanism and its associated limitations.)
>
> Unfortunately the JAIN framework expilicitly relies on the Java Event
> model, and I don't think callbacks would be accepted within the JAIN
> community.
>
>>
>>
>> Nice work and keep it rolling!  Thanks.
>
> Couldn't do it without you guys - thank you!
>
>>
>>
>> Ranga.
>>
>> Gethin Liddell wrote:
>>
>> > All,
>> >
>> > This idea of abstraction of the JAIN API is certainly a valid and
>> > interesting idea.  However, i'm a bit concerened that the proposed
>>
>> > solution of many different packages, will only seek to complicate
>> and
>> > maybe enlarge the API.
>> >
>> > I too see no reason why there is an EntityHeader etc... and i also
>> do
>> > not see any requirement for an InviteMessage, AckMessage etc...
>> >
>> > How about if the format of the API remains as is:
>> >
>> > jain.protocol.ip.sip
>> > jain.protocol.ip.sip.header
>> > jain.protocol.ip.sip.message
>> >
>> > except that the messages available in the message package
>> consisted of
>> > BasicRequest/Response, MinimalRequest/Response etc... where each
>> > message is extened in turn (e.g. Minimal extends Basic, Moderate
>> > extends Minimal etc...), of course as Chris points out it is not
>> hard
>> > to see that a combination would be required that is not provided.
>> So
>> > in the interest of flexibility, it could be possible for the user
>> to
>> > plug-in to the message class what extra headers it requires.  The
>> only
>> > issue then is that the user will have to use a "public Header
>> > getHeader(String headerName)" and then cast the header to their
>> desired
>> > header type. Either that or create their own Message class
>> > (extending the current ones) that simply does the casting
>> automatically
>> > for them.  Then after compiling, run an obfuscator on the code and
>> it
>> > will automatically extract and only extract the Message, Headers
>> and
>> > even methods that are used.
>> >
>> > This then will also cut down on the number of methods in the
>> Provider
>> > as there will be no need for the sendAck(AckMessage),
>> > sendInvite(InviteMessage) etc.. as they would be replaced by the
>> > single method sendRequest(RequestMessage).
>> >
>> > I personally see three arguments for keeping the JAIN SIP stack as
>> small
>> > as possible:
>> >
>> > 1) The first is for embedded applications where stack size has to
>> be
>> > kept to a minimum as memory is at a premium.  So if just using the
>>
>> > Basic message suffices then this will compile and run with a small
>>
>> > number of classes present from the stack.  Don't forget,
>> obfuscation
>> > will help in extracting only the Messages, Headers and even
>> methods
>> > required from a jar file but it won't do everything.
>> >
>> > 2) The second is that users may be put off or confused by the
>> sheer
>> > size and complexity of the JAIN stack.  So if only using the
>> > BasicMessage gets them on the first rung of the ladder then it is
>> a
>> > good starting point and allows them to build up to bigger and
>> better
>> > things.
>> >
>> > 3) We also have to consider who is going to implement the JAIN SIP
>>
>> > stack. If it is indeed overly complicated then no-one or a single
>> > vendor may end up implmenting the stack and thus its definition
>> and
>> > all the hard work that has gone into it is useless.
>> >
>> > On Mon, 16 Oct 2000, Chris Harris wrote:
>> > > Itamar,
>> > >
>> > > The idea of levelling the API based on what messages, headers
>> and response codes
>> > > are understood is certainly an interesting one - minimal, basic,
>> redirection,
>> > > firewall-friendly, negotiation, authentication and "full".
>> > >
>> > > jain.protocol.ip.sip
>> > > jain.protocol.ip.sip.header
>> > > jain.protocol.ip.sip.message
>> > >
>> > > could then become...
>> > >
>> > > jain.protocol.ip.sip - listener, provider, stack, general
>> classes used at all
>> > > levels
>> > > jain.protocol.ip.sip.header - contains base Header class (and
>> requestHeader,
>> > > ResponseHeader, EntityHeader, GeneralHeader)
>> > > jain.protocol.ip.sip.message - contains base Message class
>> > >
>> > > jain.protocol.ip.sip.minimal - general classes used only at this
>> level and above
>> > >
>> > > jain.protocol.ip.sip.minimal.header - headers used only at this
>> level and above
>> > > jain.protocol.ip.sip.minimal.message - messages only used at
>> this level and
>> > > above
>> > >
>> > > jain.protocol.ip.sip.basic - general classes used only at this
>> level and above
>> > > jain.protocol.ip.sip.basic.header - headers used only at this
>> level and above
>> > > jain.protocol.ip.sip.basic.message - messages used only at this
>> level and above
>> > > ...
>> > > ....
>> > > jjain.protocol.ip.sip."full" - general classes only used at this
>> level
>> > > jain.protocol.ip.sip."full".header - headers used only at this
>> level
>> > > jain.protocol.ip.sip."full".message - messages used only at this
>> level
>> > >
>> > > The API user could then pick the packages they need - say they
>> initially only
>> > > want the minimal features, but then realise they need to use
>> their application
>> > > behind a firewall - then they can simply add the
>> firewall-friendly package. The
>> > > RFC says "In general, each capability listed builds on the ones
>> above it" but it
>> > > is not hard to see that firewall-friendly and authentication may
>> be desired
>> > > without redirection for example.
>> > >
>> > > Is this what you hand in mind Itamar?
>> >
>> > --
>> > Gethin Liddell
>> > Ubiquity Software Corporation
>> >
>> > http://www.ubiquity.net
>> > mailto:gethin@ubiquity.net
>> >
>> > _______________________________________________
>> > SIP mailing list
>> > SIP@lists.bell-labs.com
>> > http://lists.bell-labs.com/mailman/listinfo/sip
>>
>> --
>> M.Ranganathan
>> NIST Advanced Networking Technologies Group,
>> 100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899.
>> Tel: 301 975 3664 Fax: 301 590 0932
>>
>> Hfæj)b? b²Ô^>X¬¶ÆÞ-YZnÇ(sm§ÿåSËlmée*¦ìr?¿?¨¥?©ÿ-+-SwèþÈ©
>

--
M.Ranganathan
NIST Advanced Networking Technologies Group,
100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899.
Tel: 301 975 3664 Fax: 301 590 0932

Hfæj)b? b²Ô^>X¬¶ÆÞ-YZnÇ(sm§ÿåSËlmée*¦ìr?¿?¨¥?©ÿ-+-SwèþÈ©

--------------F4D0E689F4F9BA5ABB1536E0-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Oct 19 09:36:12 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA27727 for ; Thu, 19 Oct 2000 09:36:09 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0562744363; Thu, 19 Oct 2000 08:36:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lists.bell-labs.com (Postfix) with ESMTP id 0EB1E44336 for ; Thu, 19 Oct 2000 08:35:24 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id e9JDZGZ09849; Thu, 19 Oct 2000 15:35:16 +0200 (MEST) Received: from lmf.ericsson.se (E005004B57366.lmf.ericsson.se [131.160.30.12]) by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id QAA29466; Thu, 19 Oct 2000 16:35:15 +0300 (EET DST) Message-ID: <39EEF890.7D7360F9@lmf.ericsson.se> From: Gonzalo Camarillo X-Mailer: Mozilla 4.74 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Jo Hornsby Cc: Anders Kristensen , SIP , sean.olson@ericsson.com Subject: Re: Source Routing WAS Re: [SIP] Route learnt out of band References: <004c01c039ce$0b1c1590$4e34c3c1@ubiquity.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 19 Oct 2000 16:35:12 +0300 Content-Transfer-Encoding: 7bit Hi, I see three possible choices here: 1) The UAC adds a Route header to the INVITE. This Route header is to be used just by this first INVITE. The following transactions will follow the path resulting from the Record-Route header coming in the 200 OK (or in the first provisional response). The UAC knows that the first Route header was built by him, so the Route header in subsequent requests will be ellaborated with the RR information received. A proxy will receive a INVITE with a Route header. This proxy does not have any state for this call-leg. It will add himself to the Record-Route (this is already recommended for robustness in the bis draft) and forward the INVITE based on the Route header. The weak point of this approach is the situation when the proxy is not happy with receiving INVITEs with Route headers without having any state for it. Anyway, for robustness, any existing server will most likely perform the same actions I have just described. When an existing implementation crashes and goes up again, it should handle re-INVITEs with Route headers for call legs whose state got lost when the server crashed. 2) The Route header is added to the Request-URI as Sean suggests in http://lists.bell-labs.com/pipermail/sip/2000q3/002748.html This works if all the proxies in the path understand Request-URIs with headers. If any proxy in the path does not it will remove them and go on routing the call without taking into consideration the Route header in the Request-URI. 3) Adding a new header called something like Source-Route. If a proxy does not understand this new header it will ignore it. If the next proxy does understand, it will route the call based on it. This can generate loops. Thus, a require header would be necessary if such a new header was created. Solution number 1 seems to me to be the best. Solution number 2 might break some implementations that use fix-length arrays for storing the request-URI (request-URIs would become very big). Solution number 3 does not look good. Any concerns with solution number 1? Regards, Gonzalo Jo Hornsby wrote: > > > > I'm not sure that this is necessarily true. If you look to bis02, > > > we have: > > > 6.34.3 Request Destination > > > Unless this would cause a loop, any client, including > > > the UAC, SHOULD send the next request for this call leg > > > to the first Request-URI in the Route request header field. > > > A client MAY forward the request to a designated proxy > > > instead, for example, if it lacks DNS resolution capability. > > > If a client uses the first Route entry to route the request, > > > it removes it. > > > > > > Thus there is flexibility here. > > > > > > When is a proxy likely to ignore a Route directive? My initial > > > thoughts are when there are networking issues (it knows it has > > > to go via some ALG-proxy, for instance), or when there are > > > billing issues. But there is nothing wrong with this. > > > > > > Thus I would say that as long as a proxy is happy to receive a > > > request with Route headers in for an unknown call leg, things > > > should work out okay; it will use other proxies as necessary, > > > and any of these will Record-Route if they need to remain in > > > the signalling path. > > > > The problem I was mentioning earlier is that things break down when a > > proxi is NOT happy to proxy requests for unknown legs with Route headers > > without being able to add itself to the Record-Route and stay on the > > signaling path. OK, so it can always try and recourd-route, the question > > is whether other proxies and the UAs play along, i.e. other proxies also > > adds themselves to the RR even when they're already on the Route and > > also whether UAs updates their routes. > > Since neither UA has seen a Record-Route yet, I would suggest that > they should have no well-defined Route for this Call (Call Leg) > yet. The originating UA may well supply an initial Route list, but > it should be discarded for subsequent requests, and the "normal" > behaviour used. > > Mostly it comes down to the "if their proxy/UA doesn't support it, > don't buyfrom/routewith them" approach. It's unlikely that someone > is going to require routing across a disparate set of proxies which > have no real relation to each other (I would guess typically one is > going to want to route through, say their "home" proxy, and their > favourite ASP proxy, for instance). > > > Neither is assured by the current > > draft, I think (haven't checked). > > UAs should not update their Routes (save noting new Contact > addresses); the only thing that proxies continually reinserting > Record-Route s buys is recovery after a crash. > > > The distinction between loose and strict source routing seems to me > > useful in understanding the problem, but most of the time a UAC can't > > know for sure whether what it's doing is loose or strict. > > Agreed. The question is: does this really matter if the request > visits all the desired proxies in both cases? > > - Jo. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Oct 19 09:40:31 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA28281 for ; Thu, 19 Oct 2000 09:40:31 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9E72A4436D; Thu, 19 Oct 2000 08:40:06 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id E6C204436D for ; Thu, 19 Oct 2000 08:39:58 -0400 (EDT) Received: from dynamicsoft.com (ip112.honxr1.ras.tele.dk [195.249.119.112]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id JAA05812; Thu, 19 Oct 2000 09:41:55 -0400 (EDT) Message-ID: <39EEF90A.D8C639E9@dynamicsoft.com> From: Anders Kristensen Organization: dynamicsoft X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 To: Jo Hornsby Cc: Gonzalo Camarillo , SIP Subject: Re: Source Routing WAS Re: [SIP] Route learnt out of band References: <004c01c039ce$0b1c1590$4e34c3c1@ubiquity.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 19 Oct 2000 15:37:14 +0200 Content-Transfer-Encoding: 7bit Jo Hornsby wrote: > > > > I'm not sure that this is necessarily true. If you look to bis02, > > > we have: > > > 6.34.3 Request Destination > > > Unless this would cause a loop, any client, including > > > the UAC, SHOULD send the next request for this call leg > > > to the first Request-URI in the Route request header field. > > > A client MAY forward the request to a designated proxy > > > instead, for example, if it lacks DNS resolution capability. > > > If a client uses the first Route entry to route the request, > > > it removes it. > > > > > > Thus there is flexibility here. > > > > > > When is a proxy likely to ignore a Route directive? My initial > > > thoughts are when there are networking issues (it knows it has > > > to go via some ALG-proxy, for instance), or when there are > > > billing issues. But there is nothing wrong with this. > > > > > > Thus I would say that as long as a proxy is happy to receive a > > > request with Route headers in for an unknown call leg, things > > > should work out okay; it will use other proxies as necessary, > > > and any of these will Record-Route if they need to remain in > > > the signalling path. > > > > The problem I was mentioning earlier is that things break down when a > > proxi is NOT happy to proxy requests for unknown legs with Route headers > > without being able to add itself to the Record-Route and stay on the > > signaling path. OK, so it can always try and recourd-route, the question > > is whether other proxies and the UAs play along, i.e. other proxies also > > adds themselves to the RR even when they're already on the Route and > > also whether UAs updates their routes. > > Since neither UA has seen a Record-Route yet, I would suggest that > they should have no well-defined Route for this Call (Call Leg) > yet. The originating UA may well supply an initial Route list, but > it should be discarded for subsequent requests, and the "normal" > behaviour used. Yes. Needs to be written into the bis draft, though. > > Mostly it comes down to the "if their proxy/UA doesn't support it, > don't buyfrom/routewith them" approach. It's unlikely that someone > is going to require routing across a disparate set of proxies which > have no real relation to each other (I would guess typically one is > going to want to route through, say their "home" proxy, and their > favourite ASP proxy, for instance). I'm not sure this is true but it doesn't really matter. The behaviour needs to be defined in the spec regardless (if agreed upon). > > > Neither is assured by the current > > draft, I think (haven't checked). > > UAs should not update their Routes (save noting new Contact > addresses); the only thing that proxies continually reinserting > Record-Route s buys is recovery after a crash. Right, so it is in fact a problem. > > > The distinction between loose and strict source routing seems to me > > useful in understanding the problem, but most of the time a UAC can't > > know for sure whether what it's doing is loose or strict. > > Agreed. The question is: does this really matter if the request > visits all the desired proxies in both cases? That's a good point but strictly speaking just because a proxy not on the initial Route happened to be on the path actually taken for the initial request doesn't mean it will necessarily be on the path of subsequent requests unless it gets to be on the route. This is maybe especially true for requests going in the opposite direction. -- Anders Kristensen _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Oct 19 09:52:09 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA29787 for ; Thu, 19 Oct 2000 09:52:08 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 509A644337; Thu, 19 Oct 2000 08:52:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from drago1.ubiquity.net (unknown [194.202.146.92]) by lists.bell-labs.com (Postfix) with SMTP id 2E78B44336 for ; Thu, 19 Oct 2000 08:51:14 -0400 (EDT) Received: from gecko.ubiquity.co.uk by drago1.ubiquity.net via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 19 Oct 2000 13:51:43 UT Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id OAA10483; Thu, 19 Oct 2000 14:49:33 +0100 (BST) From: "Jo Hornsby" To: "Gonzalo Camarillo" Cc: "Anders Kristensen" , "SIP" , Subject: RE: Source Routing WAS Re: [SIP] Route learnt out of band Message-ID: <004f01c039d3$69aad560$4e34c3c1@ubiquity.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 In-Reply-To: <39EEF890.7D7360F9@lmf.ericsson.se> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 19 Oct 2000 14:49:33 +0100 Content-Transfer-Encoding: 7bit > I see three possible choices here: > > 1) The UAC adds a Route header to the INVITE. This Route header is to be > used just by this first INVITE. The following transactions will follow > the path resulting from the Record-Route header coming in the 200 OK (or > in the first provisional response). The UAC knows that the first Route > header was built by him, so the Route header in subsequent requests will > be ellaborated with the RR information received. Indeed. > A proxy will receive a INVITE with a Route header. This proxy does not > have any state for this call-leg. It will add himself to the > Record-Route (this is already recommended for robustness in the bis > draft) and forward the INVITE based on the Route header. I don't know that we even need to be this strict. If a proxy has to send this request to another proxy, or another N proxies, because of billing, for instance, then we're still cool as long as the Nth proxy obeys the Route header (and presuming that the intermediate non-Route-obeying proxies didn't pop Routes anyway). > The weak point of this approach is the situation when the proxy is not > happy with receiving INVITEs with Route headers without having any state > for it. Yeah, this is where everything might fall down. > Anyway, for robustness, any existing server will most likely perform the > same actions I have just described. When an existing implementation > crashes and goes up again, it should handle re-INVITEs with Route > headers for call legs whose state got lost when the server crashed. > > 2) The Route header is added to the Request-URI as Sean suggests in > http://lists.bell-labs.com/pipermail/sip/2000q3/002748.html > > This works if all the proxies in the path understand Request-URIs with > headers. If any proxy in the path does not it will remove them and go on > routing the call without taking into consideration the Route header in > the Request-URI. I do quite like this as an idea, but I'm not sure that in this case. In actual fact, bis02 currently forbids headers being in the Request-URI (but this is a small issue). I think that the general notion of a SIP URL being able to specify source routing is quite powerful. It could be used in web "links" for instance; or in Registrar DBs (think Contact addresses in REGISTERs). > 3) Adding a new header called something like Source-Route. If a proxy > does not understand this new header it will ignore it. If the next proxy > does understand, it will route the call based on it. This can generate > loops. > Thus, a require header would be necessary if such a new header was > created. > > > Solution number 1 seems to me to be the best. > Solution number 2 might break some implementations that use fix-length > arrays for storing the request-URI (request-URIs would become very big). > Solution number 3 does not look good. Agreed. The bonus is that I would imagine that many proxies would be able to fly with Solution 1 today (UAs having user-configurable Routes for an initial INVITE is less likely, I guess). - Jo. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Oct 19 10:08:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA01943 for ; Thu, 19 Oct 2000 10:08:02 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8288F44348; Thu, 19 Oct 2000 09:08:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by lists.bell-labs.com (Postfix) with ESMTP id DA1F944336 for ; Thu, 19 Oct 2000 09:07:19 -0400 (EDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate2.mot.com (motgate2 2.1) with ESMTP id HAA20112 for ; Thu, 19 Oct 2000 07:06:55 -0700 (MST)] Received: [from il35exm01.cig.mot.com (IL35EXM01.cig.mot.com [160.19.16.101]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id HAA24533 for ; Thu, 19 Oct 2000 07:06:54 -0700 (MST)] Received: by IL35EXM01.cig.mot.com with Internet Mail Service (5.5.2651.58) id <429QGMFP>; Thu, 19 Oct 2000 09:05:49 -0500 Message-ID: <0DF9920C9AD8D211AB0C0008C7CF1C9A04ED8543@il27exm02.cig.mot.com> From: Baniel Uri-CUB001 To: jdrosen@dynamicsoft.com, "'Henning Schulzrinne'" Cc: sip@lists.bell-labs.com MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] TCP connection Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 19 Oct 2000 09:05:40 -0500 Hello Apologize for the basic question below... RFC2543bis section 12.3 says: "Proxies that accept TCP connections MUST be stateful when handling the TCP connection. Otherwise, if the proxy were to lose a request, the TCP client would never retransmit it." Any simple sequence that demonstrates the problem which occurs if the proxy were not statefull during the TCP session? Thanks Uri ===================== Uri Baniel Motorola Network solution Sector 1155 W. Dundee Rd Arlington Heights Tel: 847 632 4616 ===================== _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Oct 19 10:12:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA02802 for ; Thu, 19 Oct 2000 10:12:03 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5080F44348; Thu, 19 Oct 2000 09:12:06 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from drago1.ubiquity.net (unknown [194.202.146.92]) by lists.bell-labs.com (Postfix) with SMTP id 8CF6344336 for ; Thu, 19 Oct 2000 09:11:31 -0400 (EDT) Received: from gecko.ubiquity.co.uk by drago1.ubiquity.net via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 19 Oct 2000 14:12:00 UT Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id PAA17701; Thu, 19 Oct 2000 15:09:51 +0100 (BST) From: "Jo Hornsby" To: "Anders Kristensen" Cc: "Gonzalo Camarillo" , "SIP" Subject: RE: Source Routing WAS Re: [SIP] Route learnt out of band Message-ID: <005001c039d6$3ec66d70$4e34c3c1@ubiquity.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 In-Reply-To: <39EEF90A.D8C639E9@dynamicsoft.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 19 Oct 2000 15:09:50 +0100 Content-Transfer-Encoding: 7bit > > Since neither UA has seen a Record-Route yet, I would suggest that > > they should have no well-defined Route for this Call (Call Leg) > > yet. The originating UA may well supply an initial Route list, but > > it should be discarded for subsequent requests, and the "normal" > > behaviour used. > > Yes. Needs to be written into the bis draft, though. > > > > > Mostly it comes down to the "if their proxy/UA doesn't support it, > > don't buyfrom/routewith them" approach. It's unlikely that someone > > is going to require routing across a disparate set of proxies which > > have no real relation to each other (I would guess typically one is > > going to want to route through, say their "home" proxy, and their > > favourite ASP proxy, for instance). > > I'm not sure this is true but it doesn't really matter. The behaviour > needs to be defined in the spec regardless (if agreed upon). Yes. It would be nice if we RECOMMENDED that proxies obeyed Route headers, regardless; if they have to do some sort of additionally funky Challenge as a result -- so be it. > > > Neither is assured by the current > > > draft, I think (haven't checked). > > > > UAs should not update their Routes (save noting new Contact > > addresses); the only thing that proxies continually reinserting > > Record-Route s buys is recovery after a crash. > > Right, so it is in fact a problem. > > > > > > The distinction between loose and strict source routing seems to me > > > useful in understanding the problem, but most of the time a UAC can't > > > know for sure whether what it's doing is loose or strict. > > > > Agreed. The question is: does this really matter if the request > > visits all the desired proxies in both cases? > > That's a good point but strictly speaking just because a proxy not on > the initial Route happened to be on the path actually taken for the > initial request doesn't mean it will necessarily be on the path of > subsequent requests unless it gets to be on the route. This is maybe > especially true for requests going in the opposite direction. I'm lost now. As long as this proxy Record-Route d, why would it not be on the path? Or are you thinking of a case where I would like my "home" proxy, for instance, to stay in the signalling path, but it doesn't Record-Route? If it's the latter, I guess this might be problematic. Playing with Routes post-INVITE/200 does seem more risky. Thus it might be useful to note in the spec that if a proxy is coerced into a Call, it might want to think extra hard before opting out on subsequent Requests. Cheers, - Jo. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Oct 19 10:25:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA05034 for ; Thu, 19 Oct 2000 10:25:02 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 401CB44337; Thu, 19 Oct 2000 09:25:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from drago1.ubiquity.net (unknown [194.202.146.92]) by lists.bell-labs.com (Postfix) with SMTP id B215744336 for ; Thu, 19 Oct 2000 09:24:48 -0400 (EDT) Received: from gecko.ubiquity.co.uk by drago1.ubiquity.net via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 19 Oct 2000 14:25:17 UT Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id PAA21575; Thu, 19 Oct 2000 15:22:46 +0100 (BST) From: "Jo Hornsby" To: "Baniel Uri-CUB001" Cc: Subject: RE: [SIP] TCP connection Message-ID: <005401c039d8$0ce928e0$4e34c3c1@ubiquity.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 In-Reply-To: <0DF9920C9AD8D211AB0C0008C7CF1C9A04ED8543@il27exm02.cig.mot.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 19 Oct 2000 15:22:45 +0100 Content-Transfer-Encoding: 7bit > Apologize for the basic question below... > > RFC2543bis section 12.3 says: > > "Proxies that accept TCP connections MUST be stateful when > handling the TCP connection. > Otherwise, if the proxy were to lose a request, the TCP client > would never retransmit it." > > Any simple sequence that demonstrates the problem which occurs if > the proxy were not statefull during the TCP session? If a stateless proxy initiates a TCP connection, when does it close it? Since a connection being closed before a final response is sent is supposed to be interpreted as a CANCEL (section 10.3), this is a problem. If a stateless proxy accepts a TCP connection, it will only ever proxy one request per transaction since requests are not retransmitted over reliable transports (section 10.4.2). Since the next hop must be over an unreliable transport (see previous paragraph), this request might be lost, in which case it's game over. HTH, - Jo. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Oct 19 10:28:06 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA05407 for ; Thu, 19 Oct 2000 10:28:05 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B499644377; Thu, 19 Oct 2000 09:28:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id A6C3244336 for ; Thu, 19 Oct 2000 09:27:54 -0400 (EDT) Received: from dynamicsoft.com (ip17.honxr1.ras.tele.dk [195.249.119.17]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id KAA06716; Thu, 19 Oct 2000 10:29:47 -0400 (EDT) Message-ID: <39EF0442.F270B90D@dynamicsoft.com> From: Anders Kristensen Organization: dynamicsoft X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 To: Gonzalo Camarillo Cc: Jo Hornsby , SIP , sean.olson@ericsson.com Subject: Re: Source Routing WAS Re: [SIP] Route learnt out of band References: <004c01c039ce$0b1c1590$4e34c3c1@ubiquity.co.uk> <39EEF890.7D7360F9@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 19 Oct 2000 16:25:06 +0200 Content-Transfer-Encoding: 7bit I thought 1) was what we'd been talking about all along. I see no point whatsoever of putting the Route header into the request-URL. My understanding is that the grammar for SIP URLs allow headers and body in URLs simply so that URLs can be passed around out-of-band, e.g. in an HTML page, with extra info, for example a Subject line. When the user clicks the URL, the UAC constructs a request adding headers and body from the selected URL. As of 3) it might be the cleaner approach but I'd rather see Route work in this case also. Anders Gonzalo Camarillo wrote: > > Hi, > > I see three possible choices here: > > 1) The UAC adds a Route header to the INVITE. This Route header is to be > used just by this first INVITE. The following transactions will follow > the path resulting from the Record-Route header coming in the 200 OK (or > in the first provisional response). The UAC knows that the first Route > header was built by him, so the Route header in subsequent requests will > be ellaborated with the RR information received. > > A proxy will receive a INVITE with a Route header. This proxy does not > have any state for this call-leg. It will add himself to the > Record-Route (this is already recommended for robustness in the bis > draft) and forward the INVITE based on the Route header. > > The weak point of this approach is the situation when the proxy is not > happy with receiving INVITEs with Route headers without having any state > for it. > Anyway, for robustness, any existing server will most likely perform the > same actions I have just described. When an existing implementation > crashes and goes up again, it should handle re-INVITEs with Route > headers for call legs whose state got lost when the server crashed. > > 2) The Route header is added to the Request-URI as Sean suggests in > http://lists.bell-labs.com/pipermail/sip/2000q3/002748.html > > This works if all the proxies in the path understand Request-URIs with > headers. If any proxy in the path does not it will remove them and go on > routing the call without taking into consideration the Route header in > the Request-URI. > > 3) Adding a new header called something like Source-Route. If a proxy > does not understand this new header it will ignore it. If the next proxy > does understand, it will route the call based on it. This can generate > loops. > Thus, a require header would be necessary if such a new header was > created. > > Solution number 1 seems to me to be the best. > Solution number 2 might break some implementations that use fix-length > arrays for storing the request-URI (request-URIs would become very big). > Solution number 3 does not look good. > > Any concerns with solution number 1? > > Regards, > > Gonzalo > > Jo Hornsby wrote: > > > > > > I'm not sure that this is necessarily true. If you look to bis02, > > > > we have: > > > > 6.34.3 Request Destination > > > > Unless this would cause a loop, any client, including > > > > the UAC, SHOULD send the next request for this call leg > > > > to the first Request-URI in the Route request header field. > > > > A client MAY forward the request to a designated proxy > > > > instead, for example, if it lacks DNS resolution capability. > > > > If a client uses the first Route entry to route the request, > > > > it removes it. > > > > > > > > Thus there is flexibility here. > > > > > > > > When is a proxy likely to ignore a Route directive? My initial > > > > thoughts are when there are networking issues (it knows it has > > > > to go via some ALG-proxy, for instance), or when there are > > > > billing issues. But there is nothing wrong with this. > > > > > > > > Thus I would say that as long as a proxy is happy to receive a > > > > request with Route headers in for an unknown call leg, things > > > > should work out okay; it will use other proxies as necessary, > > > > and any of these will Record-Route if they need to remain in > > > > the signalling path. > > > > > > The problem I was mentioning earlier is that things break down when a > > > proxi is NOT happy to proxy requests for unknown legs with Route headers > > > without being able to add itself to the Record-Route and stay on the > > > signaling path. OK, so it can always try and recourd-route, the question > > > is whether other proxies and the UAs play along, i.e. other proxies also > > > adds themselves to the RR even when they're already on the Route and > > > also whether UAs updates their routes. > > > > Since neither UA has seen a Record-Route yet, I would suggest that > > they should have no well-defined Route for this Call (Call Leg) > > yet. The originating UA may well supply an initial Route list, but > > it should be discarded for subsequent requests, and the "normal" > > behaviour used. > > > > Mostly it comes down to the "if their proxy/UA doesn't support it, > > don't buyfrom/routewith them" approach. It's unlikely that someone > > is going to require routing across a disparate set of proxies which > > have no real relation to each other (I would guess typically one is > > going to want to route through, say their "home" proxy, and their > > favourite ASP proxy, for instance). > > > > > Neither is assured by the current > > > draft, I think (haven't checked). > > > > UAs should not update their Routes (save noting new Contact > > addresses); the only thing that proxies continually reinserting > > Record-Route s buys is recovery after a crash. > > > > > The distinction between loose and strict source routing seems to me > > > useful in understanding the problem, but most of the time a UAC can't > > > know for sure whether what it's doing is loose or strict. > > > > Agreed. The question is: does this really matter if the request > > visits all the desired proxies in both cases? > > > > - Jo. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Oct 19 10:34:28 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA06173 for ; Thu, 19 Oct 2000 10:34:28 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A9DA54437B; Thu, 19 Oct 2000 09:29:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from marvin.axion.bt.co.uk (marvin.axion.bt.co.uk [132.146.16.82]) by lists.bell-labs.com (Postfix) with ESMTP id 702A044336 for ; Thu, 19 Oct 2000 09:28:45 -0400 (EDT) Received: from chqlubnt02.lon.bt.com by marvin (local) with ESMTP; Thu, 19 Oct 2000 15:06:28 +0100 Received: by chqlubnt02.lon.bt.com with Internet Mail Service (5.5.2652.35) id <4MC6A0XA>; Thu, 19 Oct 2000 15:06:26 +0100 Message-ID: From: clive.dellard@bt.com To: schulzrinne@cs.columbia.edu Cc: jdrosen@dynamicsoft.com, byerly@cisco.com, stlevy@cisco.com, jryang@cisco.com, christer.holmberg@lmf.ericsson.se, sip@lists.bell-labs.com Subject: RE: [SIP] From header to ISUP CgPN mapping MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: text/plain Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 19 Oct 2000 15:06:22 +0100 Thanks Henning, Comments below. Clive > -----Original Message----- > From: Henning Schulzrinne [SMTP:schulzrinne@cs.columbia.edu] > Sent: Thursday, October 19, 2000 2:06 PM > To: clive.dellard@bt.com > Cc: jdrosen@dynamicsoft.com; byerly@cisco.com; stlevy@cisco.com; > jryang@cisco.com; christer.holmberg@lmf.ericsson.se; > sip@lists.bell-labs.com > Subject: Re: [SIP] From header to ISUP CgPN mapping > > clive.dellard@bt.com wrote: > > > > Jonathan, > > I understand your reluctance to add changes, however, > IMHO I > > do not see that it is bogus for a call originating in an IP network to > be > > able to provide a calling address appropriate for the terminating > network. > > So if the call remains in the IP environment a SIP address is provided > but > > if the call terminates in the PSTN an E.164 number is delivered as the > > calling address. > > I would welcome suggestions on how to resolve this issue. > > If this is to be meaningful, it has to be verifiable. Just having users > stick in random telephone numbers that then pop up on caller ID boxes is > not likely to be useful. [Clive Dellard BTexaCT] I totally agree. Also, if the outbound gateway is my home provider (as is likely, due to > billing relationships), I will have already registered with a local > registrar, including with a tel: URL. This already provides this > information, if desired, to the gateway. Thus, it is far from clear that > a simple header is particularly helpful. [Clive Dellard BTexaCT] OK that sounds reasonable, what mechanisms are available to get this information to the gateways? > -- > Henning Schulzrinne http://www.cs.columbia.edu/~hgs > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Oct 19 10:58:07 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA08978 for ; Thu, 19 Oct 2000 10:58:05 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9452244366; Thu, 19 Oct 2000 09:58:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14]) by lists.bell-labs.com (Postfix) with ESMTP id 536ED44336 for ; Thu, 19 Oct 2000 09:57:41 -0400 (EDT) Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprch1.nortel.com; Thu, 19 Oct 2000 09:52:19 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Thu, 19 Oct 2000 09:52:15 -0500 Message-ID: <28560036253BD41191A10000F8BCBD110250C5D3@zcard00g.ca.nortel.com> From: "Tom-PT Taylor" To: "'Jonathan Rosenberg'" , "'hammer michael'" , Doug Harbert , Simon Barber Cc: "'sip'" Subject: RE: [SIP] Re-direct of Media During Ringing MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C039DC.29A93FC0" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 19 Oct 2000 09:52:12 -0500 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_01C039DC.29A93FC0 Content-Type: text/plain; charset="iso-8859-1" Sorry to take so long to reply to this, but it was a nice vacation :-) In my particular situation I am not talking about early media. Instead, it's a matter of where media gets directed when the call is answered. Here's the primary call flow as I envisioned it: UAC->UAS: INVITE(Call-Id=x, CRef=y; SDP) UAS->UAC: 180 Ringing Now the UAC finds it necessary to send new SDP. UAC->UAS: INVITE(Call-Id=x, CRef=y+; new SDP) UAS->UAC: 200 OK to the new INVITE UAC->UAS: ACK Now the called party answers: UAS->UAC: 200 OK to the original INVITE UAC->UAS: ACK There is an obvious race condition where the called party answers before the re-INVITE is processed. No matter what approach we take, the called party's initial greeting will be clipped in consequence, so the real issue is to make sure that the call processing sequence is consistent with the general spirit of SIP while meeting the requirements of the call. With the call flow above, the race condition is no problem for the call processing. From the UAS point of view, we end up with serial INVITEs rather than nested ones. It's slightly more complicated for the UAC -- the order in which it receives the respective final responses changes. One open issue in my mind is whether a second 180 Ringing interim response has to be sent to indicate call state as a result of the second INVITE. The alternative call flow is as follows: UAC->UAS: INVITE(Call-Id=x, CRef=y; SDP) UAS->UAC: 180 Ringing Now the UAC finds it necessary to send new SDP. UAC->UAS: CANCEL UAS->UAC: 200 OK UAC->UAS: INVITE(Call-Id=u, CRef=v; new SDP) UAS->UAC: 180 Ringing Now the called party answers: UAS->UAC: 200 OK to the new INVITE UAC->UAS: ACK Again we have a race between called party answer and the second invitation. This time it leads to trouble. When the second INVITE comes along, the application behind the UAS may perceive that the called party is busy and refuse the call. The calling party sees the call go from alerting to called party busy state, and the called party answers a call with no one there. The risk of this race occurring may be acceptable, but the matter is open to discussion. > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Monday, October 02, 2000 1:18 AM > To: 'hammer michael'; Doug Harbert; Simon Barber > Cc: Jonathan Rosenberg; Taylor, Tom-PT [NORSE:B901:EXCH]; 'sip' > Subject: RE: [SIP] Re-direct of Media During Ringing > > > I agree that the notion of the caller delivering all kinds of > media to the > called party, before the call is "answered", worries me a > lot. Particularly > if you want the called party to modify some aspect of the "early media > session". Security is definitely a problem here. You can > argue that the > called party shouldn't return a 183 with SDP containing a > sendrecv parameter > if it didn't know the caller. But, this imposes an > unreasonable burden on > the called party. > > I think the problem is related to people's coupling of a session with > answering a physical telephone device. To me, the example > with the alarm > clock is clear - a session has most definitely been started. > > Allowing re-invites before a session is established is > complicated. Take the > simple case of a normal phone call. Does the UAS need to > collect all these > invites, and then answer them all once it accepts the call? > If it accepts, > does it send a 200 OK to the first, then reject the rest, 200 > OK to all of > them? WHat happens if one of those transactions doesn't complete? The > primary complexity is really holding on to those reinvites, and then > responding to all when the call is answered. This is quite a pain. > > -Jonathan R. > > --- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > > -----Original Message----- > > From: hammer michael [mailto:mhammer@cisco.com] > > Sent: Friday, September 29, 2000 1:27 PM > > To: Doug Harbert; Simon Barber > > Cc: Jonathan Rosenberg; 'Tom-PT Taylor'; 'sip' > > Subject: Re: [SIP] Re-direct of Media During Ringing > > > > > > Simon, > > > > I would not rely on being able to identify the calling party > > (long live > > anonymity???). As I have noticed on the telephone network, > > telemarketers > > are very good at not identifying themselves ("out of area" on > > my caller id > > box) and can be expected to do the same on the net. > > > > Mike > > > > > > At 05:59 PM 09/28/2000 -0600, Doug Harbert wrote: > > >Simon Barber wrote: > > > > > > > > > Example service: > > > > > > > > > > > > Morning alarm clock, calls me on my SIP phone, > > connecting early inbound > > > > > > media first to a quiet internet radio station (the > phone plays > > > > > this on its > > > > > > speaker, instead of ringing), then if unanswered after 2 > > > > > minutes, re-invite > > > > > > the early media to a thrash metal sample from an > RTSP server. > > > > > When the call > > > > > > is answered connect me to a message telling me what's > > on my to-do list > > > > > > today, and reminding me it's my girlfriend's birthday. > > > > > > > > > > > > > > > > The applications you describe here sound like > sessions. In fact, > > > > > any time one > > > > > party delivers media to another party, there is a session and > > > > > there should be > > > > > explicit agreement between parties to form this > session. Perhaps > > > > > what is needed > > > > > > > > By this notion there should be no re-invite at all - > > changing the media at > > > > all would be counted as a new session, requiring the user > > explicitly accept > > > > the new session. I do not accept this at all. > > > > > >No, re-INVITE during an established session is ok. The above > > example indicates > > >a re-INVITE before the session has been established. > > Possibly a better method > > >would be to CANCEL the current INVITE and issue a new INVITE > > to establish a > > >different session. > > > > > > > > > > > > > > > > > > > > > here is a way for your sip phone to automatically answer calls > > > > > from your alarm > > > > > clock, or for your pager to automatically answer calls and > > > > > perform the page. > > > > > These devices could modify their behaviors depending > > upon the application > > > > > requested for the session, low level alarm, high level > > alarm, page. > > > > > > > > Automatically answering calls is different from > > delivering media before the > > > > answer. If you automatically answer a call there is no > > possibility for the > > > > callee to later really answer the call. For example the > > alarm clock servive > > > > I proposed would not be possible - the service is > > terminated by the callee > > > > answering the call, listening to a message, and hanging up. > > > > > > > > > >If your SIP phone has automatically answered the call > > because it recognizes > > >that it is from your alarm clock, then the session is > > established. There is no > > >need to tear it down just because a person wants to talk. > > Your phone as an > > >intelligent endpoint could recognize the off hook, and if > > necessary issue a > > >re-INVITE to modify the session parameters for the voice call. > > > > > > > > > > > > > > > > > > > > The recipient of the call or his/her agents (phones, > pagers,...) > > > > > must have the > > > > > authority to decide whether or not to accept the session, and > > > > > receive media. > > > > > > > > > > > > > Certainly the recipient of the call should have good > > control over what > > > > sessions they accept, and these control should include > > controls over > > > > sessions delivering media before the call is answered. > > These controls > > > may be > > > > partly provided in the UA and partly in the proxy servers > > that forward the > > > > call to the user's UA. > > > > > > > > Simon Barber > > > > > >Delivery of media to the callee before the session has been > > completely setup > > >worries me somehow (I picture telemarketers sending their > > spiel into my living > > >room). But I suppose that since the callee can accept or > > reject this media via > > >the SDP in the 183 then that allows sufficient control. This > > may be useful if > > >the endpoint can recognize the caller and allow or disallow > > receipt of the > > >media according to who is calling. Though if the SIP phone > > can do this, it > > >should be able to accept the call for call screening > > purposes, and allow the > > >callee to pick it up if he/she wants to. > > > > > >Doug Harbert > > > > > > > > >_______________________________________________ > > >SIP mailing list > > >SIP@lists.bell-labs.com > > >http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > ------_=_NextPart_001_01C039DC.29A93FC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [SIP] Re-direct of Media During Ringing

Sorry to take so long to reply to this, but it was a = nice vacation :-)  In my particular situation I am not talking = about early media.  Instead, it's a matter of where media gets = directed when the call is answered.  Here's the primary call flow = as I envisioned it:

UAC->UAS: INVITE(Call-Id=3Dx, CRef=3Dy; = SDP)
UAS->UAC: 180 Ringing

Now the UAC finds it necessary to send new = SDP.
UAC->UAS: INVITE(Call-Id=3Dx, CRef=3Dy+; new = SDP)
UAS->UAC: 200 OK to the new INVITE
UAC->UAS: ACK

Now the called party answers:
UAS->UAC: 200 OK to the original INVITE
UAC->UAS: ACK

There is an obvious race condition where the called = party answers before the re-INVITE is processed.  No matter what = approach we take, the called party's initial greeting will be clipped = in consequence, so the real issue is to make sure that the call = processing sequence is consistent with the general spirit of SIP while = meeting the requirements of the call.

With the call flow above, the race condition is no = problem for the call processing.  From the UAS point of view, we = end up with serial INVITEs rather than nested ones.  It's slightly = more complicated for the UAC -- the order in which it receives the = respective final responses changes.

One open issue in my mind is whether a second 180 = Ringing interim response has to be sent to indicate call state as a = result of the second INVITE.

The alternative call flow is as follows:


UAC->UAS: INVITE(Call-Id=3Dx, CRef=3Dy; = SDP)
UAS->UAC: 180 Ringing

Now the UAC finds it necessary to send new = SDP.
UAC->UAS: CANCEL
UAS->UAC: 200 OK

UAC->UAS: INVITE(Call-Id=3Du, CRef=3Dv; new = SDP)
UAS->UAC: 180 Ringing

Now the called party answers:
UAS->UAC: 200 OK to the new INVITE
UAC->UAS: ACK


Again we have a race between called party answer and = the second invitation.  This time it leads to trouble.  When = the second INVITE comes along, the application behind the UAS may = perceive that the called party is busy and refuse the call.  The = calling party sees the call go from alerting to called party busy = state, and the called party answers a call with no one there.  The = risk of this race occurring may be acceptable, but the matter is open = to discussion.

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> Sent: Monday, October 02, 2000 1:18 AM
> To: 'hammer michael'; Doug Harbert; Simon = Barber
> Cc: Jonathan Rosenberg; Taylor, Tom-PT = [NORSE:B901:EXCH]; 'sip'
> Subject: RE: [SIP] Re-direct of Media During = Ringing
>
>
> I agree that the notion of the caller = delivering all kinds of
> media to the
> called party, before the call is = "answered", worries me a
> lot. Particularly
> if you want the called party to modify some = aspect of the "early media
> session". Security is definitely a problem = here. You can
> argue that the
> called party shouldn't return a 183 with SDP = containing a
> sendrecv parameter
> if it didn't know the caller. But, this imposes = an
> unreasonable burden on
> the called party.
>
> I think the problem is related to people's = coupling of a session with
> answering a physical telephone device. To me, = the example
> with the alarm
> clock is clear - a session has most definitely = been started.
>
> Allowing re-invites before a session is = established is
> complicated. Take the
> simple case of a normal phone call. Does the = UAS need to
> collect all these
> invites, and then answer them all once it = accepts the call?
> If it accepts,
> does it send a 200 OK to the first, then reject = the rest, 200
> OK to all of
> them? WHat happens if one of those transactions = doesn't complete? The
> primary complexity is really holding on to = those reinvites, and then
> responding to all when the call is answered. = This is quite a pain.
>
> -Jonathan R.
>
> ---
> Jonathan D. = Rosenberg          &nb= sp;            = 72 Eagle Rock Ave.
> Chief = Scientist          &nb= sp;           &nb= sp;      First Floor
> = dynamicsoft          &= nbsp;           &= nbsp;          East = Hanover, NJ 07936
> = jdrosen@dynamicsoft.com        &= nbsp;            = FAX:   (973) 952-5050
> http://www.cs.columbia.edu/~jdrosen  &nb= sp;      PHONE: (973) 952-5000
> http://www.dynamicsoft.com
>
> > -----Original Message-----
> > From: hammer michael [mailto:mhammer@cisco.com]
> > Sent: Friday, September 29, 2000 1:27 = PM
> > To: Doug Harbert; Simon Barber
> > Cc: Jonathan Rosenberg; 'Tom-PT Taylor'; = 'sip'
> > Subject: Re: [SIP] Re-direct of Media = During Ringing
> >
> >
> > Simon,
> >
> > I would not rely on being able to identify = the calling party
> > (long live
> > anonymity???).  As I have noticed on = the telephone network,
> > telemarketers
> > are very good at not identifying = themselves ("out of area" on
> > my caller id
> > box) and can be expected to do the same on = the net.
> >
> > Mike
> >
> >
> > At 05:59 PM 09/28/2000 -0600, Doug Harbert = wrote:
> > >Simon Barber wrote:
> > >
> > > > > > Example = service:
> > > > > >
> > > > > > Morning alarm clock, = calls me on my SIP phone,
> > connecting early inbound
> > > > > > media first to a quiet = internet radio station (the
> phone plays
> > > > > this on its
> > > > > > speaker, instead of = ringing), then if unanswered after 2
> > > > > minutes, re-invite
> > > > > > the early media to a = thrash metal sample from an
> RTSP server.
> > > > > When the call
> > > > > > is answered connect me = to a message telling me what's
> > on my to-do list
> > > > > > today, and reminding = me it's my girlfriend's birthday.
> > > > > >
> > > > >
> > > > > The applications you = describe here sound like
> sessions. In fact,
> > > > > any time one
> > > > > party delivers media to = another party, there is a session and
> > > > > there should be
> > > > > explicit agreement between = parties to form this
> session. Perhaps
> > > > > what is needed
> > > >
> > > > By this notion there should be = no re-invite at all -
> > changing the media at
> > > > all would be counted as a new = session, requiring the user
> > explicitly accept
> > > > the new session. I do not accept = this at all.
> > >
> > >No, re-INVITE during an established = session is ok. The above
> > example indicates
> > >a re-INVITE before the session has = been established.
> > Possibly a better method
> > >would be to CANCEL the current INVITE = and issue a new INVITE
> > to establish a
> > >different session.
> > >
> > > >
> > > >
> > > > >
> > > > > here is a way for your sip = phone to automatically answer calls
> > > > > from your alarm
> > > > > clock, or for your pager to = automatically answer calls and
> > > > > perform the page.
> > > > > These devices could modify = their behaviors depending
> > upon the application
> > > > > requested for the session, = low level alarm, high level
> > alarm, page.
> > > >
> > > > Automatically answering calls is = different from
> > delivering media before the
> > > > answer. If you automatically = answer a call there is no
> > possibility for the
> > > > callee to later really answer = the call. For example the
> > alarm clock servive
> > > > I proposed would not be possible = - the service is
> > terminated by the callee
> > > > answering the call, listening to = a message, and hanging up.
> > > >
> > >
> > >If your SIP phone has automatically = answered the call
> > because it recognizes
> > >that it is from your alarm clock, then = the session is
> > established. There is no
> > >need to tear it down just because a = person wants to talk.
> > Your phone as an
> > >intelligent endpoint could recognize = the off hook, and if
> > necessary issue a
> > >re-INVITE to modify the session = parameters for the voice call.
> > >
> > >
> > > >
> > > > >
> > > > > The recipient of the call = or his/her agents (phones,
> pagers,...)
> > > > > must have the
> > > > > authority to decide whether = or not to accept the session, and
> > > > > receive media.
> > > > >
> > > >
> > > > Certainly the recipient of the = call should have good
> > control over what
> > > > sessions they accept, and these = control should include
> > controls over
> > > > sessions delivering media before = the call is answered.
> > These controls
> > > may be
> > > > partly provided in the UA and = partly in the proxy servers
> > that forward the
> > > > call to the user's UA.
> > > >
> > > > Simon Barber
> > >
> > >Delivery of media to the callee before = the session has been
> > completely setup
> > >worries me somehow (I picture = telemarketers sending their
> > spiel into my living
> > >room). But I suppose that since the = callee can accept or
> > reject this media via
> > >the SDP in the 183 then that allows = sufficient control. This
> > may be useful if
> > >the endpoint can recognize the caller = and allow or disallow
> > receipt of the
> > >media according to who is calling. = Though if the SIP phone
> > can do this, it
> > >should be able to accept the call for = call screening
> > purposes, and allow the
> > >callee to pick it up if he/she wants = to.
> > >
> > >Doug Harbert
> > >
> > >
> > = >_______________________________________________
> > >SIP mailing list
> > >SIP@lists.bell-labs.com
> > >http://lists.bell-labs.com/mailman/listinfo/sip
> >
> >
>
>

------_=_NextPart_001_01C039DC.29A93FC0-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Oct 19 11:54:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA15704 for ; Thu, 19 Oct 2000 11:54:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 77A9C4437B; Thu, 19 Oct 2000 10:54:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mail01.netian.com (unknown [203.231.231.171]) by lists.bell-labs.com (Postfix) with ESMTP id 032AB44374 for ; Thu, 19 Oct 2000 10:53:56 -0400 (EDT) Received: by mail01.netian.com (5.1.048k) id 39D2F8A500252635 for sip@lists.bell-labs.com; Fri, 20 Oct 2000 00:53:49 +0900 Message-ID: <39E66F33000077F5@mail01.netian.com> From: 772kh@netian.com To: "sip@lists.bell-labs.com" MIME-Version: 1.0 Importance: Normal Content-Type: text/plain; charset="EUC-KR" Subject: [SIP] Redirect Server's merit?? Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 20 Oct 2000 00:53:48 +0900 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA15704 Hi.. Redirect Server has less overhead than Proxy Server.. Other merit?? thank you... _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Oct 19 12:16:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA19419 for ; Thu, 19 Oct 2000 12:16:03 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id ECDCE44385; Thu, 19 Oct 2000 11:16:07 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from hvmta01-stg.us.psimail.psi.net (hvmta01-ext.us.psimail.psi.net [38.202.36.29]) by lists.bell-labs.com (Postfix) with ESMTP id 5057B44383 for ; Thu, 19 Oct 2000 11:15:48 -0400 (EDT) Received: from softwareo ([38.150.216.6]) by hvmta01-stg.us.psimail.psi.net (InterMail v4.01.01.00 201-229-111) with SMTP id <20001019161535.QLBK1216.hvmta01-stg@softwareo>; Thu, 19 Oct 2000 12:15:35 -0400 Reply-To: From: "Orit Levin" To: "Chris Harris" , "Itamar Gilad" Cc: , , Subject: RE: [SIPFORUM] Re: [SIP] JAIN SIP Specification Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0018_01C039C6.447E4E50" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <39EEF762.A8C8B6FA@dynamicsoft.com> Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 19 Oct 2000 12:15:28 -0400 This is a multi-part message in MIME format. ------=_NextPart_000_0018_01C039C6.447E4E50 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Hello! I am sure we are going to have this discussion during the JAIN meeting next week. But it is hard from not intervening here. The great benefit of SIP (compared to other competing technologies :-)) is the abstraction it defines, starting from the low protocol’s level. The lowest one is the “messages”. The next one is the “transaction”. The next one is the “call (leg)”. In our case, we are talking about the keeper of the “Transactions State machine”. This point is obvious. Based on the discussions here, yet another point is less obvious. In order to define an efficient and interoperable API, there should be (in my opinion, MUST) one single MASTER of the “Transactions State machine”. The API itself should be driven by this main architectural decision. It doesn’t preclude from “exporting” by this Master both the “transaction states” and “the SIP messages”. It does not preclude from providing by this Master “modification tools” for both transaction state machine and the SIP messages. My point is, that depending on this FIRST decision, the semantic of the “SIP messages API” part would be very different, even if its syntax may look alike!!! Therefore, before diving into the API details, SPEC should define the chosen model, clearly specifying the real “state machine” MASTER for each abstraction level. This is the only way to define an interoperable API. BTW, my technical opinion is to use the SIP design advantage at its best and to define the Provider, to be the MASTER for the transaction state machine. Best Regards, Orit Levin RADVision Inc. TEL: 201.529.4300 x 230 FAX:201.529.3516 mailto:orit@radvision.com http://www.radvision.com 575 Corporate Drive Suite 420 Mahwah, NJ 07430 -----Original Message----- From: sip-admin@lists.bell-labs.com [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Chris Harris Sent: Thursday, October 19, 2000 9:30 AM To: Itamar Gilad Cc: sip@lists.bell-labs.com; discussion@sipforum.org; jainsip@Sun.COM Subject: Re: [SIPFORUM] Re: [SIP] JAIN SIP Specification Hi Itamar, Sure - after all an application can completely ignore the transaction ids given to it by the Provider, and use the send methods that don't take transaction id parameters - the Provider has to cover both types of application. Note that I don't necessarily think an application can't have an object to represent a transaction, just that such an object must operate through the Provider - since the Provider is supposed to be the applications only access to the SIP stack. So you could have a client transaction object containing the request sent returned by the Provider, and have a cancel method on it - that calls the sendCancel method on the Provider etc... But I'm not sure how useful this would be - you are also forcing an application that is not interested in transactions to extract messages from transaction objects. Then again, we could always define two JainSipListener subtypes - JainSipMessageListener and JainSipTransactionListener...this might be a good idea - then we can have an application indicate to the Provider whether it is interested in transactions - if it isn't it just receives Message objects, and if it is it receives Transaction objects (incorporating the associated Messages) The Transaction objects contain a transaction id, and can by ClientTransaction or ServerTransaction, and their methods can call the Provider's methods with the transaction id parameters. Opinions? I think incorporating call-legs and calls into the API is asking too much of an API that deals with messages and transactions - unless we create a JainSipCall(Leg)Listener...but now we're mandating that the inderlying implementation has to keep call state...and above we have to map JCC onto these...that could get very messy! Chris Itamar Gilad wrote: Hi Chris,It could be argued that it makes just as much sense for the Provider to identify also the Call-Leg and Call. Still I think I understand what you are after and I agree that this might help applications that for some reason want to know about transaction 'ids', but don't want to work with transaction objects. Regards Itamar -----Original Message----- From: Chris Harris [ mailto:charris@dynamicsoft.com] Sent: Thu, October 19, 2000 12:11 PM To: sip@lists.bell-labs.com Cc: discussion@sipforum.org; jainsip@Sun.COM Subject: Re: [SIPFORUM] Re: [SIP] JAIN SIP Specification Hi Itamar, I can't really think of any applications other than a stateless proxy that don't care about transactions. And since stateless proxies are really just SIP routers and need maximum performance, I can't really see anyone implementing them with JAIN SIP. I think any application that does anything interesting needs to know about transactions, so the the JAIN SIP API should include some means of identifying transactions or transaction control. But this has to fit in with the Listener/Provider event model, so we can't hand a Listener a transaction object that they can work with directly - we need to give an application access to transactions through the Provider. I thought a transaction id would be the simplest way to achieve this. Do you have any suggestions for improving transaction control for the event model? Chris Itamar Gilad wrote: No, that's not it. The application uses a stack to do all of this. The stack should export a message-related API like the one defined in the JAIN SIP specification you presented. The stack should also export interfaces for Call control and Transaction control. It seems more logical for the application to use a transaction object which handles messaging and notifies it whenever a message belonging to this transaction is received rather then having a message object that tells it which transaction it belongs too. Stateless proxies for example would use only the message layer and they don't care at all about transactions. I'm Sorry to be so picky, but I just think that this makes for a cleaner design both in the application and in the stack. Our experience with our SIP stack proves that this model works fine.Itamar -----Original Message----- From: Chris Harris [ mailto:charris@dynamicsoft.com] Sent: Wed, October 18, 2000 8:18 PM To: discussion@sipforum.org Cc: Itamar Gilad; 'Bobby Sardana'; mranga@nist.gov; sip@lists.bell-labs.com; jainsip@Sun.COM Subject: Re: [SIPFORUM] Re: [SIP] JAIN SIP Specification OK - so if an application just sends a message to the Provider, it has to check all response messages to see if they match - this is so messy for an application. What if a response message never arrives - how should the Provider inform the application of a timeout? Call a timeout method and pass the request message back? Itamar Gilad wrote: Chris, I agree that few SIP applications would like to bother with transaction mapping. This is clearly the responsibility of the stack as is transaction management in general. However in a previous thread you explained that the issue of managing call and transaction state is outside the scope of this API specification, which led me to believe that the goal is to define message-related functionality. I think that injecting transaction keys into the mix is crossing the lines you defined. Regards, Itamar -----Original Message----- From: Chris Harris [ mailto:charris@dynamicsoft.com] Sent: Wed, October 18, 2000 7:44 PM To: Itamar Gilad Cc: 'Bobby Sardana'; discussion@sipforum.org; mranga@nist.gov; sip@lists.bell-labs.com; jainsip@Sun.COM Subject: Re: [SIPFORUM] Re: [SIP] JAIN SIP Specification Itamar, It is for the very reason that identifying a transaction from a message is not a trivial matter that I wanted to put the transaction handling inside the JainSipProvider. I don't think the spec should just deal with just the message layer. How many people are going to write JAIN SIP applications if they have to implement their own transaction keys? I'd imagine very few. Regards, Chris Itamar Gilad wrote: Hi again Chris,I'd like to re-emphasize what Bobby says below. The JAIN SIP specification presented here seems to deal just with the "message layer" i.e. parsing, encoding, message and message part containers. I'd like to join those who commend the fine and comprehensive work done. However, this layer has nothing to do with transactions and their state. It would be a mistake to rely on it to retain 'transaction-ids' and associate messages to them (please correct me if I'm misinterpreting your meaning). Note that identifying a transaction from a message is not a trivial matter and continuously more message fields are added to the "transaction key" in order to deal with spiraling, merging etc. A more straight-forward approach would be to put this functionality in the "transaction layer" where transaction objects live and make a clean separation between the two layers.Regards Itamar -----Original Message----- From: Bobby Sardana [ mailto:bobby.sardana@mobilerain.com] Sent: Wed, October 18, 2000 6:39 PM To: discussion@sipforum.org Cc: mranga@nist.gov; sip@lists.bell-labs.com; jainsip@sun.com Subject: Re: [SIPFORUM] Re: [SIP] JAIN SIP Specification Greetings Chris: Just to add a pointer to this thread: Maintaining trasaction state is an application level functionality and *shouldn't* be implemented in the base stack. For applications like state oriented proxy server, the JAIN SIP can provide enough hooks for event delivery but the state has to be maintained by the proxy server. Pleas keep up the good work. It is really appreciated. Regards, Bobby.Sardana@mobilerain.com Chris Harris wrote: "M. Ranganathan" wrote: Hi Chris, Thanks for replying so promptly (I am sure you are flooded with email ). I get one or two :) As you pointed out, I suppose we cannot do away with making Messages into classes because of the tie-in with java events (unfortunately) but I still like the notion of being able to specify interfaces where ever possible. I see where you're coming from alright, and I suppose changing header classes into interfaces, could fit in with Gethin's proposal nicely? I dont quite follow the motivation behind the following design decision (excerpted from your reply): Maybe I've misunderstood what you're saying - but a JAIN SIP implementation is only stateless when it comes to call state. The JainSipProvider implementation must maintain transaction state - it simply exposes a reference to a transaction via the transaction id for the convenience of the JainSipListener. The service does not have total control over transacton state - the stack implementation does. It appears that I have indded mis-understood the architecture. Why should the above be so? Can one not rely on the JainSipListener to keep transaction state also, thereby making the stack simply a way of recognising messages and triggering event handlers on the basis of message type. This would (IMHO) be a cleaner model yet. That way, we can do away with transaction identifiers being passed back and forth and keep all of this information in the handler. ( You may have to extend the architecture somewhat to deal with timeouts and failures so that the handler knows about transaction failure.) In any case, if this is not a viable idea, I would be grateful if you can explain why not (or point me to the portion of the spec that explains why not) so I can get a better understanding. It would be cleaner model, and personally I am in total agreement with you - but it means the application is forced to maintain transaction state, match up headers - which has been said places too much of a burden on applications. How about finding a way to let the application choose whether or not it wants to keep transaction state? Regards, Ranga. Chris Harris wrote: > Hi Ranga, > > Response below... > > Chris > > "M. Ranganathan" wrote: > >> JAIN-SIP is a groovy idea. Hats off to the whole concept and many >> thanks to Chris and >> the JAIN-SIP team for putting together a spec and more flower power >> to them :-) . In >> particular I like the notion of treating UAS, Redirect and Proxy >> servers as merely >> special cases of the general notion of Services and the idea of >> unifying these >> notions with an event mechanism and event handlers. Second, I like >> the idea of >> separation between a stateless event -oriented "stack" and a bunch >> of event >> handlers that are triggered by the stack with all state (including >> transaction >> state) being separated from the event stack via the JAIN-SIP mapping >> layer if you >> will. ( Correct me if I wax poetic but have the wrong >> understanding....) > >> >> >> I hope I will not be viewed as being too critical, but I would >> like to go one step >> further than what Gethin is suggesting. I am all for using >> interfaces as much as >> possible and leaving class hierarchy definitions to implemeters. >> Defining class >> hierarchies almost lays out an implementation and involves >> considerable rework for >> those who have a working java-based stack, but have not used the >> same classes. OK it >> is just a matter of labor to map things to the JAIN-SIP class >> hierarchy but it IS a >> dis-incentive. >> >> 1. Lets use interfaces for all messages rather than actually define >> class >> hierarchies ( yes Chris has pointed out the historical precedent >> behind actually >> defining class hierarchies for messages. IMHO, there has to be a >> more compelling >> reason than that.) > > I suppose all classes could be turned into interfaces, except for the > Message classes which must extend java.util.EventObject to fit into > the JAIN framework. > >> >> >> 2. The tie-in with the JAVA event mechanism has necessitated the >> explicit definition >> of class hierarchies in certain places. Why not use callbacks >> instead and do away >> with this dependency as well? (Basically the same thing as events >> but does not tie >> into the JAVA event mechanism and its associated limitations.) > > Unfortunately the JAIN framework expilicitly relies on the Java Event > model, and I don't think callbacks would be accepted within the JAIN > community. > >> >> >> Nice work and keep it rolling! Thanks. > > Couldn't do it without you guys - thank you! > >> >> >> Ranga. >> >> Gethin Liddell wrote: >> >> > All, >> > >> > This idea of abstraction of the JAIN API is certainly a valid and >> > interesting idea. However, i'm a bit concerened that the proposed >> >> > solution of many different packages, will only seek to complicate >> and >> > maybe enlarge the API. >> > >> > I too see no reason why there is an EntityHeader etc... and i also >> do >> > not see any requirement for an InviteMessage, AckMessage etc... >> > >> > How about if the format of the API remains as is: >> > >> > jain.protocol.ip.sip >> > jain.protocol.ip.sip.header >> > jain.protocol.ip.sip.message >> > >> > except that the messages available in the message package >> consisted of >> > BasicRequest/Response, MinimalRequest/Response etc... where each >> > message is extened in turn (e.g. Minimal extends Basic, Moderate >> > extends Minimal etc...), of course as Chris points out it is not >> hard >> > to see that a combination would be required that is not provided. >> So >> > in the interest of flexibility, it could be possible for the user >> to >> > plug-in to the message class what extra headers it requires. The >> only >> > issue then is that the user will have to use a "public Header >> > getHeader(String headerName)" and then cast the header to their >> desired >> > header type. Either that or create their own Message class >> > (extending the current ones) that simply does the casting >> automatically >> > for them. Then after compiling, run an obfuscator on the code and >> it >> > will automatically extract and only extract the Message, Headers >> and >> > even methods that are used. >> > >> > This then will also cut down on the number of methods in the >> Provider >> > as there will be no need for the sendAck(AckMessage), >> > sendInvite(InviteMessage) etc.. as they would be replaced by the >> > single method sendRequest(RequestMessage). >> > >> > I personally see three arguments for keeping the JAIN SIP stack as >> small >> > as possible: >> > >> > 1) The first is for embedded applications where stack size has to >> be >> > kept to a minimum as memory is at a premium. So if just using the >> >> > Basic message suffices then this will compile and run with a small >> >> > number of classes present from the stack. Don't forget, >> obfuscation >> > will help in extracting only the Messages, Headers and even >> methods >> > required from a jar file but it won't do everything. >> > >> > 2) The second is that users may be put off or confused by the >> sheer >> > size and complexity of the JAIN stack. So if only using the >> > BasicMessage gets them on the first rung of the ladder then it is >> a >> > good starting point and allows them to build up to bigger and >> better >> > things. >> > >> > 3) We also have to consider who is going to implement the JAIN SIP >> >> > stack. If it is indeed overly complicated then no-one or a single >> > vendor may end up implmenting the stack and thus its definition >> and >> > all the hard work that has gone into it is useless. >> > >> > On Mon, 16 Oct 2000, Chris Harris wrote: >> > > Itamar, >> > > >> > > The idea of levelling the API based on what messages, headers >> and response codes >> > > are understood is certainly an interesting one - minimal, basic, >> redirection, >> > > firewall-friendly, negotiation, authentication and "full". >> > > >> > > jain.protocol.ip.sip >> > > jain.protocol.ip.sip.header >> > > jain.protocol.ip.sip.message >> > > >> > > could then become... >> > > >> > > jain.protocol.ip.sip - listener, provider, stack, general >> classes used at all >> > > levels >> > > jain.protocol.ip.sip.header - contains base Header class (and >> requestHeader, >> > > ResponseHeader, EntityHeader, GeneralHeader) >> > > jain.protocol.ip.sip.message - contains base Message class >> > > >> > > jain.protocol.ip.sip.minimal - general classes used only at this >> level and above >> > > >> > > jain.protocol.ip.sip.minimal.header - headers used only at this >> level and above >> > > jain.protocol.ip.sip.minimal.message - messages only used at >> this level and >> > > above >> > > >> > > jain.protocol.ip.sip.basic - general classes used only at this >> level and above >> > > jain.protocol.ip.sip.basic.header - headers used only at this >> level and above >> > > jain.protocol.ip.sip.basic.message - messages used only at this >> level and above >> > > ... >> > > .... >> > > jjain.protocol.ip.sip."full" - general classes only used at this >> level >> > > jain.protocol.ip.sip."full".header - headers used only at this >> level >> > > jain.protocol.ip.sip."full".message - messages used only at this >> level >> > > >> > > The API user could then pick the packages they need - say they >> initially only >> > > want the minimal features, but then realise they need to use >> their application >> > > behind a firewall - then they can simply add the >> firewall-friendly package. The >> > > RFC says "In general, each capability listed builds on the ones >> above it" but it >> > > is not hard to see that firewall-friendly and authentication may >> be desired >> > > without redirection for example. >> > > >> > > Is this what you hand in mind Itamar? >> > >> > -- >> > Gethin Liddell >> > Ubiquity Software Corporation >> > >> > http://www.ubiquity.net >> > mailto:gethin@ubiquity.net >> > >> > _______________________________________________ >> > SIP mailing list >> > SIP@lists.bell-labs.com >> > http://lists.bell-labs.com/mailman/listinfo/sip >> >> -- >> M.Ranganathan >> NIST Advanced Networking Technologies Group, >> 100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899. >> Tel: 301 975 3664 Fax: 301 590 0932 >> >> Hfæj)b? b²Ô^>X¬¶ÆÞ-YZnÇ(sm§ÿåSËlmée*¦ìr?¿?¨¥?©ÿ-+-SwèþÈ© > -- M.Ranganathan NIST Advanced Networking Technologies Group, 100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899. Tel: 301 975 3664 Fax: 301 590 0932 Hfæj)b? b²Ô^>X¬¶ÆÞ-YZnÇ(sm§ÿåSËlmée*¦ìr?¿?¨¥?©ÿ-+-SwèþÈ© ------=_NextPart_000_0018_01C039C6.447E4E50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

He= llo!

I = am sure we are going to have this discussion during the JAIN meeting next week. But = it is hard from not intervening here.

 

Th= e great benefit of SIP (compared to other competing technologies = J) is the abstraction it defines, starting from the = low protocol’s level. The lowest one is the “messages”. = The next one is the “transaction”. The next one is the “call (leg)”. =

In= our case, we are talking about the keeper of the “Transactions State = machine”.  This point is = obvious.

 

Ba= sed on the discussions here, yet another point is less obvious. In order to = define an efficient and interoperable API, there should be (in my opinion, MUST) one single = MASTER of the “Transactions State machine”. The API itself should = be driven by this main architectural decision. It doesn’t preclude from = “exporting” by this Master both the “transaction states” and “the SIP messages”. = It does not preclude from providing by this Master “modification tools” for both = transaction state machine and the SIP messages.

My= point is, that depending on this FIRST decision, the semantic of the “SIP messages API” part would be very = different, even if its syntax may look alike!!!=

 

Th= erefore, before diving into the API details, SPEC should define the chosen model, = clearly specifying the real “state machine” MASTER for each = abstraction level. This is the only way to define an interoperable = API.

 

BT= W, my technical opinion is to use the SIP design advantage at its best and to define the Provider, to be the MASTER for the transaction state = machine.

 

Be= st Regards,

Orit Levin

RADVision Inc.

TEL: 201.529.4300 x = 230

FAX:201.529.3516

mailto:orit@radvision.com

http://www.radvision.com =

575 Corporate Drive Suite 420 = Mahwah, NJ 07430

<= span class=3DEmailStyle18> 

-----Original Message-----
From: sip-admin@lists.bell-labs.com = [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Chris Harris
Sent: Thursday, October = 19, 2000 9:30 AM
To: Itamar Gilad
Cc: = sip@lists.bell-labs.com; discussion@sipforum.org; jainsip@Sun.COM
Subject: Re: [SIPFORUM] = Re: [SIP] JAIN SIP Specification

 

Hi = Itamar, <= /p>

Sure - after all an application = can completely ignore the transaction ids given to it by the Provider, and = use the send methods that don't take transaction id parameters - the Provider = has to cover both types of application. <= /p>

Note that I don't necessarily = think an application can't have an object to represent a transaction, just that = such an object must operate through the Provider - since the Provider is = supposed to be the applications only access to the SIP stack. So you could have a = client transaction object containing the request sent returned by the Provider, = and have a cancel method on it - that calls the sendCancel method on the = Provider etc... But I'm not sure how useful this would be - you are also forcing = an application that is not interested in transactions to extract messages = from transaction objects.

Then again, we could always = define two JainSipListener subtypes - JainSipMessageListener and = JainSipTransactionListener...this might be a good idea - then we can have an application indicate to the = Provider whether it is interested in transactions - if it isn't it just receives = Message objects, and if it is it receives Transaction objects (incorporating the = associated Messages) The Transaction objects contain a transaction id, and can by ClientTransaction or ServerTransaction, and their methods can call the Provider's methods with the transaction id parameters. Opinions? = <= /p>

I think incorporating call-legs = and calls into the API is asking too much of an API that deals with messages and transactions - unless we create a JainSipCall(Leg)Listener...but now = we're mandating that the inderlying implementation has to keep call = state...and above we have to map JCC onto these...that could get very messy! = <= /p>

Chris <= /p>

Itamar Gilad wrote: = <= /p>

 Hi Chris,It could be argued that it makes just as much sense = for the Provider to identify also the Call-Leg and Call. Still I think I = understand what you are after and I agree that this might help applications that = for some reason want to know about transaction 'ids', but don't want to work with transaction objects. Regards   = Itamar  <= /p>

-----Original Message-----
From: Chris Harris [mailto:charris@dynamicsoft.com]
Sent: Thu, October 19, 2000 12:11 PM
To:= sip@lists.bell-labs.com
Cc:= discussion@sipforum.org; = jainsip@Sun.COM
Subject: Re: [SIPFORUM] Re: [SIP] JAIN SIP = Specification
 

Hi = Itamar, <= /p>

I can't really think of any applications other than a stateless proxy that = don't care about transactions. And since stateless proxies are really just SIP routers and need maximum performance, I can't really see anyone = implementing them with JAIN SIP.

I think any application that does anything interesting needs to know about transactions, so the the JAIN SIP API should include some means of = identifying transactions or transaction control. But this has to fit in with the Listener/Provider event model, so we can't hand a Listener a transaction = object that they can work with directly - we need to give an application access = to transactions through the Provider. I thought a transaction id would be = the simplest way to achieve this. Do you have any suggestions for improving transaction control for the event model? <= /p>

Chris <= /p>

Itamar Gilad wrote:

No, that's not it.  The application uses a stack to do = all of this.  The stack should export a message-related API like the one = defined in the JAIN SIP specification you presented.  The stack should also = export interfaces for Call control and Transaction control.  It seems more logical for the application to use a transaction object which handles = messaging and notifies it whenever a message belonging to this transaction is = received rather then having a message object that tells it which transaction it = belongs too.  Stateless proxies for example would use only the message = layer and they don't care at all about transactions. I'm Sorry to be so = picky, but I just think that this makes for a cleaner design both in the application = and in the stack.  Our experience with our SIP stack proves that this = model works fine.Itamar <= /p>

 Chris, I agree that few SIP applications would like to bother with transaction mapping.  This is clearly the responsibility of the = stack as is transaction management in general. However in a previous thread you explained that the issue of managing call and transaction state is = outside the scope of this API specification, which led me to believe that the goal = is to define message-related functionality. I think that injecting transaction = keys into the mix is crossing the lines you defined. Regards,  = Itamar <= /p>

Hi again Chris,I'd like to re-emphasize what Bobby says below.  The JAIN SIP specification presented here seems to deal = just with the "message layer" i.e. parsing, encoding, message and = message part containers.  I'd like to join those who commend the fine and = comprehensive work done.  However, this layer has nothing to do with transactions = and their state.  It would be a mistake to rely on it to retain = 'transaction-ids' and associate messages to them (please correct me if I'm misinterpreting = your meaning). Note that identifying a transaction from a message is not a = trivial matter and continuously more message fields are added to the = "transaction key" in order to deal with spiraling, merging etc. A more = straight-forward approach would be to put this functionality in the "transaction layer" where transaction objects live and make a clean separation = between the two layers.Regards Itamar
-----Original = Message-----
From: Bobby Sardana [mailto:bobby.sardana@mobiler= ain.com]
Sent: Wed, October 18, 2000 6:39 PM
To:= discussion@sipforum.org
Cc:= mranga@nist.gov; sip@lists.bell-labs.com; = jainsip@sun.com
Subject: Re: [SIPFORUM] Re: [SIP] JAIN SIP = Specification
 

Greetings Chris:

Just to add a pointer to this thread: <= /p>

Maintaining trasaction state is an application level functionality and *shouldn't* = be implemented in the base stack. For applications like state oriented = proxy server, the JAIN SIP can provide enough hooks for event delivery but the state = has to be maintained by the proxy server. <= /p>

Pleas keep up the good work. It is really appreciated. <= /p>

Regards, <= /p>

Bobby.Sardana@mobilerain.com <= /p>

Chris Harris wrote:

"M. Ranganathan" wrote: <= /p>

Hi Chris,

Thanks for replying so promptly (I am sure you are flooded with email = ).<= /p>

I get one or two :) <= /p>

 
As you pointed out, I suppose we cannot do away with making Messages =
into classes because of the tie-in with java events (unfortunately) but =
I still like the notion of being able to specify  interfaces where = ever
possible.

I see where you're coming from alright, and I suppose changing header classes = into interfaces, could fit in with Gethin's proposal = nicely? <= /p>

 
 I dont quite follow  the motivation behind the following = design
decision (excerpted from your reply): <= /p>

Maybe I've misunderstood what you're saying - but a JAIN SIP
implementation is only stateless when it comes to call state. The
JainSipProvider implementation must maintain transaction state - it
simply exposes a reference to a transaction via the transaction id for =
the convenience of the JainSipListener. The service does not have total =
control over transacton state - the stack implementation does. = <= /p>

It appears that I have indded mis-understood the architecture.  Why =
should the above be so? Can one not rely on the JainSipListener to keep =
transaction state also, thereby making the stack simply a way of
recognising messages and triggering  event handlers on the basis of =
message type. This would (IMHO) be a cleaner model = yet.    That way,  we
can do away with transaction identifiers being passed back and forth and =
keep all of this information in the handler.  ( You may have to = extend
the architecture somewhat to deal with timeouts and failures so that the =
handler knows about transaction failure.) In any case, if this is not a =
viable idea, I would be grateful if you can explain why not (or point me =
to the portion of the spec that explains why not) so I can get a better =
understanding.

It would be cleaner model, and personally I am in total agreement with you = - but it means the application is forced to maintain transaction state, match = up headers - which has been said places too much of a burden on = applications. How about finding a way to let the application choose whether or not it = wants to keep transaction state? <= /p>

  <= /p>

Regards, <= /p>

Ranga. <= /p>

Chris Harris wrote:

> Hi Ranga,
>
> Response below...
>
> Chris
>
> "M. Ranganathan" wrote:
>
>> JAIN-SIP is a groovy idea. Hats off to the whole concept and = many
>> thanks to Chris and
>> the JAIN-SIP team for putting together a spec and more flower = power
>> to them :-) .  In
>> particular I like the notion of treating UAS,  Redirect = and Proxy
>> servers as merely
>> special cases of the general notion of Services and  the = idea of
>> unifying these
>> notions with an event mechanism and  event handlers.  Second, I like
>> the idea of
>> separation between a  stateless  event -oriented "stack" and a bunch
>> of event
>> handlers that are triggered by the stack with all state = (including
>> transaction
>> state) being separated from the event stack via the JAIN-SIP = mapping
>> layer if you
>> will.  ( Correct me if I  wax poetic but have the = wrong
>> understanding....)
>
>>
>>
>> I hope I  will not be viewed as being too critical,  = but I would
>> like to go  one step
>> further than what Gethin is suggesting.   I am all = for using
>> interfaces as much as
>> possible and leaving class hierarchy definitions to = implemeters.
>> Defining class
>> hierarchies almost lays out an implementation and involves
>> considerable rework for
>> those who have a working java-based stack, but have not used = the
>> same classes. OK it
>> is just a matter of labor to map things to the JAIN-SIP class =
>> hierarchy but it  IS a
>> dis-incentive.
>>
>> 1. Lets use interfaces for all messages rather than actually = define
>> class
>> hierarchies  ( yes Chris has pointed out the historical = precedent
>> behind actually
>> defining class hierarchies for messages. IMHO,  there has = to be a
>> more compelling
>> reason than that.)
>
> I suppose all classes could be turned into interfaces, except for = the
> Message classes which must extend java.util.EventObject to fit into =
> the JAIN framework.
>
>>
>>
>> 2. The tie-in with the JAVA event mechanism has necessitated = the
>> explicit definition
>> of class hierarchies in certain places.  Why not use = callbacks
>> instead and do away
>> with this dependency as well?  (Basically the same thing = as events
>> but does not tie
>> into the JAVA event mechanism and its associated limitations.) =
>
> Unfortunately the JAIN framework expilicitly relies on the Java = Event
> model, and I don't think callbacks would be accepted within the = JAIN
> community.
>
>>
>>
>> Nice work and keep it rolling!  Thanks.
>
> Couldn't do it without you guys - thank you!
>
>>
>>
>> Ranga.
>>
>> Gethin Liddell wrote:
>>
>> > All,
>> >
>> > This idea of abstraction of the JAIN API is certainly a = valid and
>> > interesting idea.  However, i'm a bit concerened that = the proposed
>>
>> > solution of many different packages, will only seek to = complicate
>> and
>> > maybe enlarge the API.
>> >
>> > I too see no reason why there is an EntityHeader etc... = and i also
>> do
>> > not see any requirement for an InviteMessage, AckMessage = etc...
>> >
>> > How about if the format of the API remains as is:
>> >
>> > jain.protocol.ip.sip
>> > jain.protocol.ip.sip.header
>> > jain.protocol.ip.sip.message
>> >
>> > except that the messages available in the message package =
>> consisted of
>> > BasicRequest/Response, MinimalRequest/Response etc... = where each
>> > message is extened in turn (e.g. Minimal extends Basic, = Moderate
>> > extends Minimal etc...), of course as Chris points out it = is not
>> hard
>> > to see that a combination would be required that is not = provided.
>> So
>> > in the interest of flexibility, it could be possible for = the user
>> to
>> > plug-in to the message class what extra headers it requires.  The
>> only
>> > issue then is that the user will have to use a = "public Header
>> > getHeader(String headerName)" and then cast the = header to their
>> desired
>> > header type. Either that or create their own Message class =
>> > (extending the current ones) that simply does the casting =
>> automatically
>> > for them.  Then after compiling, run an obfuscator on = the code and
>> it
>> > will automatically extract and only extract the Message, = Headers
>> and
>> > even methods that are used.
>> >
>> > This then will also cut down on the number of methods in = the
>> Provider
>> > as there will be no need for the sendAck(AckMessage),
>> > sendInvite(InviteMessage) etc.. as they would be replaced = by the
>> > single method sendRequest(RequestMessage).
>> >
>> > I personally see three arguments for keeping the JAIN SIP = stack as
>> small
>> > as possible:
>> >
>> > 1) The first is for embedded applications where stack size = has to
>> be
>> > kept to a minimum as memory is at a premium.  So if = just using the
>>
>> > Basic message suffices then this will compile and run with = a small
>>
>> > number of classes present from the stack.  Don't = forget,
>> obfuscation
>> > will help in extracting only the Messages, Headers and = even
>> methods
>> > required from a jar file but it won't do everything.
>> >
>> > 2) The second is that users may be put off or confused by = the
>> sheer
>> > size and complexity of the JAIN stack.  So if only = using the
>> > BasicMessage gets them on the first rung of the ladder = then it is
>> a
>> > good starting point and allows them to build up to bigger = and
>> better
>> > things.
>> >
>> > 3) We also have to consider who is going to implement the = JAIN SIP
>>
>> > stack. If it is indeed overly complicated then no-one or a = single
>> > vendor may end up implmenting the stack and thus its = definition
>> and
>> > all the hard work that has gone into it is useless.
>> >
>> > On Mon, 16 Oct 2000, Chris Harris wrote:
>> > > Itamar,
>> > >
>> > > The idea of levelling the API based on what messages, headers
>> and response codes
>> > > are understood is certainly an interesting one - = minimal, basic,
>> redirection,
>> > > firewall-friendly, negotiation, authentication and "full".
>> > >
>> > > jain.protocol.ip.sip
>> > > jain.protocol.ip.sip.header
>> > > jain.protocol.ip.sip.message
>> > >
>> > > could then become...
>> > >
>> > > jain.protocol.ip.sip - listener, provider, stack, = general
>> classes used at all
>> > > levels
>> > > jain.protocol.ip.sip.header - contains base Header = class (and
>> requestHeader,
>> > > ResponseHeader, EntityHeader, GeneralHeader)
>> > > jain.protocol.ip.sip.message - contains base Message = class
>> > >
>> > > jain.protocol.ip.sip.minimal - general classes used = only at this
>> level and above
>> > >
>> > > jain.protocol.ip.sip.minimal.header - headers used = only at this
>> level and above
>> > > jain.protocol.ip.sip.minimal.message - messages only = used at
>> this level and
>> > > above
>> > >
>> > > jain.protocol.ip.sip.basic - general classes used = only at this
>> level and above
>> > > jain.protocol.ip.sip.basic.header - headers used only = at this
>> level and above
>> > > jain.protocol.ip.sip.basic.message - messages used = only at this
>> level and above
>> > > ...
>> > > ....
>> > > jjain.protocol.ip.sip."full" - general = classes only used at this
>> level
>> > > jain.protocol.ip.sip."full".header - = headers used only at this
>> level
>> > > jain.protocol.ip.sip."full".message - = messages used only at this
>> level
>> > >
>> > > The API user could then pick the packages they need - = say they
>> initially only
>> > > want the minimal features, but then realise they need = to use
>> their application
>> > > behind a firewall - then they can simply add the
>> firewall-friendly package. The
>> > > RFC says "In general, each capability listed = builds on the ones
>> above it" but it
>> > > is not hard to see that firewall-friendly and = authentication may
>> be desired
>> > > without redirection for example.
>> > >
>> > > Is this what you hand in mind Itamar?
>> >
>> > --
>> > Gethin Liddell
>> > Ubiquity Software Corporation
>> >
>> > http://www.ubiquity.net
>> > mailto:gethin@ubiquity.net
>> >
>> > _______________________________________________
>> > SIP mailing list
>> > SIP@lists.bell-labs.com
>> > http://lists.bel= l-labs.com/mailman/listinfo/sip
>>
>> --
>> M.Ranganathan
>> NIST Advanced Networking Technologies Group,
>> 100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899.
>> Tel: 301 975 3664 Fax: 301 590 0932
>>
>> Hf=E6j)b? = b=B2=D4^>X=AC=B6=C6=DE-YZn=C7(sm=A7=FF=E5S=CBlm=E9e*=A6=ECr?=BF?=A8=A5= ?=A9=FF-+-Sw=E8=FE=C8=A9
>

--
M.Ranganathan
NIST Advanced Networking Technologies Group,
100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899.
Tel: 301 975 3664 Fax: 301 590 0932 <= /p>

Hf=E6j)b? b=B2=D4^>X=AC=B6=C6=DE-YZn=C7(sm=A7=FF=E5S=CBlm=E9e*=A6=ECr?=BF?=A8=A5= ?=A9=FF-+-Sw=E8=FE=C8=A9<= /p>

------=_NextPart_000_0018_01C039C6.447E4E50-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Oct 19 13:03:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA29726 for ; Thu, 19 Oct 2000 13:03:02 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 819FE4434A; Thu, 19 Oct 2000 12:03:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from drago1.ubiquity.net (unknown [194.202.146.92]) by lists.bell-labs.com (Postfix) with SMTP id F06F244392 for ; Thu, 19 Oct 2000 11:18:35 -0400 (EDT) Received: from gecko.ubiquity.co.uk by drago1.ubiquity.net via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 19 Oct 2000 16:19:05 UT Received: from phoffer by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id RAA05617; Thu, 19 Oct 2000 17:16:56 +0100 (BST) Message-ID: <003401c039e7$e85950d0$5334c3c1@ubiquity.co.uk> From: "Phil Hoffer" To: Subject: Re:[SIP] Error in draft-ietf-sip-call-flows-01.txt 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: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 19 Oct 2000 17:16:15 +0100 Content-Transfer-Encoding: 7bit Hi, Just to clarify. The quoting of some of the authentication parameters in Neal's :) corrected call flows are unfortunately incorrect. Specifically, the use of quotation marks on the algorithm parameter and stale parameter. There has been discussion on this list before about the quoting of the authentication parameters. I have supplied the authors of the call flows document with updates. The corrected call flows are listed below. Cheers, Phil http://www.ubiquity.net -- 2.1.1 SIP Client New Registration F1 REGISTER B -> SIP Server REGISTER sip:ss2.wcom.com SIP/2.0 Via: SIP/2.0/UDP there.com:5060 From: LittleGuy To: LittleGuy Call-ID: 123456789@here.com CSeq: 1 REGISTER Contact: LittleGuy Contact: sip:+1-972-555-2222@gw1.wcom.com;user=phone Contact: tel:+1-972-555-2222 Content-Length: 0 F2 401 Unauthorized SIP Server -> User B SIP/2.0 401 Unauthorized Via: SIP/2.0/UDP there.com:5060 From: LittleGuy To: LittleGuy Call-ID: 123456789@here.com CSeq: 1 REGISTER WWW-Authenticate: Digest realm="MCI WorldCom SIP", domain="wcom.com", nonce="ea9c8e88df84f1cec4341ae6cbe5a359", opaque="", stale=FALSE, algorithm=MD5 Content-Length: 0 F3 REGISTER B -> SIP Server REGISTER sip:ss2.wcom.com SIP/2.0 Via: SIP/2.0/UDP there.com:5060 From: LittleGuy To: LittleGuy Call-ID: 123456789@here.com CSeq: 2 REGISTER Contact: LittleGuy Contact: sip:+1-972-555-2222@gw1.wcom.com;user=phone Contact: tel:+1-972-555-2222 Authorization:Digest username="UserB", realm="MCI WorldCom SIP", nonce="ea9c8e88df84f1cec4341ae6cbe5a359", opaque="", uri="sip:ss2.wcom.com", response="dfe56131d1958046689cd83306477ecc" Content-Length: 0 F4 200 OK SIP Server -> B SIP/2.0 200 OK Via: SIP/2.0/UDP there.com:5060 From: LittleGuy To: LittleGuy Call-ID: 123456789@here.com CSeq: 2 REGISTER Contact: LittleGuy Contact: sip:+1-972-555-2222@gw1.wcom.com;user=phone Contact: tel:+1-972-555-2222 Content-Length: 0 2.2.1 Unsuccessful SIP registration F1 REGISTER B -> SIP Server REGISTER sip:ss2.wcom.com SIP/2.0 Via: SIP/2.0/UDP there.com:5060 From: LittleGuy To: LittleGuy Call-ID: 123456789@here.com CSeq: 1 REGISTER Contact: LittleGuy Contact: sip:+1-972-555-2222@gw1.wcom.com;user=phone Contact: tel:+1-972-555-2222 Content-Length: 0 F2 Unauthorized SIP Server -> User B SIP/2.0 401 Unauthorized Via: SIP/2.0/UDP there.com:5060 From: LittleGuy To: LittleGuy Call-ID: 123456789@here.com CSeq: 1 REGISTER WWW-Authenticate: Digest realm="MCI WorldCom SIP", domain="wcom.com", nonce="f1cec4341ae6ca9c8e88df84be55a359", opaque="", stale=FALSE, algorithm=MD5 Content-Length: 0 F3 REGISTER B -> SIP Server REGISTER sip:ss2.wcom.com SIP/2.0 Via: SIP/2.0/UDP there.com:5060 From: LittleGuy To: LittleGuy Call-ID: 123456789@here.com CSeq: 2 REGISTER Contact: LittleGuy Contact: sip:+1-972-555-2222@gw1.wcom.com;user=phone Contact: tel:+1-972-555-2222 Authorization:Digest username="UserB", realm="MCI WorldCom SIP", nonce="f1cec4341ae6ca9c8e88df84be55a359", opaque="", uri="sip:ss2.wcom.com", response="61f8470ceb87d7ebf508220214ed438b" Content-Length: 0 /* The response above encodes the incorrect password _IForgotIt_ */ F4 401 Unauthorized SIP Server -> User B SIP/2.0 401 Unauthorized Via: SIP/2.0/UDP there.com:5060 From: LittleGuy To: LittleGuy Call-ID: 123456789@here.com CSeq: 2 REGISTER WWW-Authenticate: Digest realm="MCI WorldCom SIP", domain="wcom.com", nonce="84f1c1ae6cbe5ua9c8e88dfa3ecm3459", opaque="", stale=FALSE, algorithm=MD5 Content-Length: 0 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Oct 19 13:43:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA05217 for ; Thu, 19 Oct 2000 13:43:02 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 341314433A; Thu, 19 Oct 2000 12:43:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from pigeon.vovida.com (a98.vovida.com [209.237.8.98]) by lists.bell-labs.com (Postfix) with ESMTP id A469744336 for ; Thu, 19 Oct 2000 12:42:27 -0400 (EDT) Received: from vovida.com ([209.237.8.113]) by pigeon.vovida.com (Netscape Messaging Server 4.15) with ESMTP id G2OU5B00.M4G for ; Thu, 19 Oct 2000 10:34:23 -0700 Message-ID: <39EF3276.9D0DF858@vovida.com> From: Sunitha Kumar Organization: Vovida Networks X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14 i686) X-Accept-Language: en MIME-Version: 1.0 To: sip bell labs Content-Type: multipart/alternative; boundary="------------5C4A8CA1DE7DC90F4381B539" Subject: [SIP] clarification on tags in the BYE request. Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 19 Oct 2000 10:42:14 -0700 --------------5C4A8CA1DE7DC90F4381B539 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit With respect to section 11.3 and 11.4 in September 4, SIPbis, It is given that all subsequent requests of the same callLeg contains the same To header field, including the *tags*. It is also given here, that a UAC copies the tag from the final response into the ACK, but it *MUST NOT* copy the tag into any subsequent requests unless the response was a 200 class response to an INVITE request. Does this mean: UAC -------send INVITE------------->UAS UAC<------send 200 OK with tag in To----UAS UAC-------send ACK, with same tag as in To of 200 OK-->UAS UAC<-------RTP---------------------->UAS Now , if BYE is sent from UAC to a UAS, should UAC tag the To field of the BYE , the same as the 200 OK that it received. If yes, why, isn't this another transaction? I agree that if the BYE were to be sent instead of the ACK( in order to cancel the call), then it needs to be tagged in the To field. But, not if the BYE was sent independently, after establishing the call. The FAQ had no explanation of this. Could someone explain this? Thanks much. -- Sunitha Kumar http://www.vovida.com --------------5C4A8CA1DE7DC90F4381B539 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit With respect to section 11.3 and 11.4 in September 4, SIPbis,

It is given that all subsequent requests of the same callLeg  contains the same To header field, including the *tags*.
It is also given here, that a UAC copies the tag from the final response into the ACK, but it *MUST NOT* copy the tag into any subsequent requests unless the response was a 200 class response to an INVITE request.

Does this mean:
UAC -------send INVITE------------->UAS
UAC<------send 200 OK with tag in To----UAS
UAC-------send ACK, with same tag as in To of 200 OK-->UAS
UAC<-------RTP---------------------->UAS

Now , if BYE is sent from UAC to a UAS, should UAC tag the To field of the BYE , the same as the 200 OK that it received.
If yes, why, isn't this another transaction?

I agree that if the BYE were to be sent instead of the ACK( in order to cancel the call), then it needs to be tagged in the To field. But, not if the BYE was sent independently, after establishing the call.
The FAQ had no explanation of this. Could someone explain this?

Thanks much. 

-- 
Sunitha Kumar
http://www.vovida.com
  --------------5C4A8CA1DE7DC90F4381B539-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Oct 19 13:53:16 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA06538 for ; Thu, 19 Oct 2000 13:53:16 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 834C044394; Thu, 19 Oct 2000 12:50:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from pmesmtp02.wcom.com (pmesmtp02.wcom.com [199.249.20.2]) by lists.bell-labs.com (Postfix) with ESMTP id 5DF8B44394 for ; Thu, 19 Oct 2000 12:49:49 -0400 (EDT) Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-32 #42257) id <0G2O00401UU6N2@firewall.mcit.com> for sip@lists.bell-labs.com; Thu, 19 Oct 2000 17:49:18 +0000 (GMT) Received: from dgismtp04.wcomnet.com ([166.38.58.144]) by firewall.mcit.com (PMDF V5.2-32 #42257) with ESMTP id <0G2O0037EUU6LX@firewall.mcit.com> for sip@lists.bell-labs.com; Thu, 19 Oct 2000 17:49:18 +0000 (GMT) Received: from CONVERSION-DAEMON by dgismtp04.wcomnet.com (PMDF V5.2-33 #42262) id <0G2O00501UWDTL@dgismtp04.wcomnet.com> for sip@lists.bell-labs.com; Thu, 19 Oct 2000 17:50:37 +0000 (GMT) Received: from dgismtp04.wcomnet.com by dgismtp04.wcomnet.com (PMDF V5.2-33 #42262) with SMTP id <0G2O00501UW2SH@dgismtp04.wcomnet.com> for sip@lists.bell-labs.com; Thu, 19 Oct 2000 17:50:36 +0000 (GMT) Received: from wcom.com ([166.33.132.84]) by dgismtp04.wcomnet.com (PMDF V5.2-33 #42262) with ESMTP id <0G2O00540UVR88@dgismtp04.wcomnet.com> for sip@lists.bell-labs.com; Thu, 19 Oct 2000 17:50:15 +0000 (GMT) From: Alan Johnston Subject: Re: [SIP] Error in draft-ietf-sip-call-flows-01.txt Cc: sip@lists.bell-labs.com Message-id: <39EF34D1.C1F594A9@wcom.com> MIME-version: 1.0 X-Mailer: Mozilla 4.7 [en] (Win98; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en References: <003401c039e7$e85950d0$5334c3c1@ubiquity.co.uk> Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 19 Oct 2000 12:52:17 -0500 Content-Transfer-Encoding: 7bit Both of these errors have been previously discussed on the list and have been corrected in the next draft, due out soon... Thanks, Alan Johnston Phil Hoffer wrote: > Hi, > > Just to clarify. > The quoting of some of the authentication parameters in Neal's :) corrected > call flows are > unfortunately incorrect. Specifically, the use of quotation marks on the > algorithm parameter and > stale parameter. > > There has been discussion on this list before about the quoting of the > authentication parameters. > I have supplied the authors of the call flows document with updates. > > The corrected call flows are listed below. > > Cheers, > Phil > > http://www.ubiquity.net > > -- > 2.1.1 SIP Client New Registration > F1 REGISTER B -> SIP Server > REGISTER sip:ss2.wcom.com SIP/2.0 > Via: SIP/2.0/UDP there.com:5060 > From: LittleGuy > To: LittleGuy > Call-ID: 123456789@here.com > CSeq: 1 REGISTER > Contact: LittleGuy > Contact: sip:+1-972-555-2222@gw1.wcom.com;user=phone > Contact: tel:+1-972-555-2222 > Content-Length: 0 > F2 401 Unauthorized SIP Server -> User B > SIP/2.0 401 Unauthorized > Via: SIP/2.0/UDP there.com:5060 > From: LittleGuy > To: LittleGuy > Call-ID: 123456789@here.com > CSeq: 1 REGISTER > WWW-Authenticate: Digest realm="MCI WorldCom SIP", > domain="wcom.com", > nonce="ea9c8e88df84f1cec4341ae6cbe5a359", opaque="", > stale=FALSE, > algorithm=MD5 > Content-Length: 0 > F3 REGISTER B -> SIP Server > REGISTER sip:ss2.wcom.com SIP/2.0 > Via: SIP/2.0/UDP there.com:5060 > From: LittleGuy > To: LittleGuy > Call-ID: 123456789@here.com > CSeq: 2 REGISTER > Contact: LittleGuy > Contact: sip:+1-972-555-2222@gw1.wcom.com;user=phone > Contact: tel:+1-972-555-2222 > Authorization:Digest username="UserB", realm="MCI WorldCom > SIP", > nonce="ea9c8e88df84f1cec4341ae6cbe5a359", opaque="", > uri="sip:ss2.wcom.com", > response="dfe56131d1958046689cd83306477ecc" > Content-Length: 0 > F4 200 OK SIP Server -> B > SIP/2.0 200 OK > Via: SIP/2.0/UDP there.com:5060 > From: LittleGuy > To: LittleGuy > Call-ID: 123456789@here.com > CSeq: 2 REGISTER > Contact: LittleGuy > Contact: sip:+1-972-555-2222@gw1.wcom.com;user=phone > Contact: tel:+1-972-555-2222 > Content-Length: 0 > 2.2.1 Unsuccessful SIP registration > F1 REGISTER B -> SIP Server > REGISTER sip:ss2.wcom.com SIP/2.0 > Via: SIP/2.0/UDP there.com:5060 > From: LittleGuy > To: LittleGuy > Call-ID: 123456789@here.com > CSeq: 1 REGISTER > Contact: LittleGuy > Contact: sip:+1-972-555-2222@gw1.wcom.com;user=phone > Contact: tel:+1-972-555-2222 > Content-Length: 0 > F2 Unauthorized SIP Server -> User B > > SIP/2.0 401 Unauthorized > Via: SIP/2.0/UDP there.com:5060 > From: LittleGuy > To: LittleGuy > Call-ID: 123456789@here.com > CSeq: 1 REGISTER > WWW-Authenticate: Digest realm="MCI WorldCom SIP", > domain="wcom.com", > nonce="f1cec4341ae6ca9c8e88df84be55a359", opaque="", > stale=FALSE, > algorithm=MD5 > Content-Length: 0 > F3 REGISTER B -> SIP Server > REGISTER sip:ss2.wcom.com SIP/2.0 > Via: SIP/2.0/UDP there.com:5060 > From: LittleGuy > To: LittleGuy > Call-ID: 123456789@here.com > CSeq: 2 REGISTER > Contact: LittleGuy > Contact: sip:+1-972-555-2222@gw1.wcom.com;user=phone > Contact: tel:+1-972-555-2222 > Authorization:Digest username="UserB", realm="MCI WorldCom > SIP", > nonce="f1cec4341ae6ca9c8e88df84be55a359", opaque="", > uri="sip:ss2.wcom.com", > response="61f8470ceb87d7ebf508220214ed438b" > Content-Length: 0 > /* The response above encodes the incorrect password > _IForgotIt_ */ > F4 401 Unauthorized SIP Server -> User B > SIP/2.0 401 Unauthorized > Via: SIP/2.0/UDP there.com:5060 > From: LittleGuy > To: LittleGuy > Call-ID: 123456789@here.com > CSeq: 2 REGISTER > WWW-Authenticate: Digest realm="MCI WorldCom SIP", > domain="wcom.com", > nonce="84f1c1ae6cbe5ua9c8e88dfa3ecm3459", opaque="", > stale=FALSE, > algorithm=MD5 > Content-Length: 0 > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Oct 19 14:36:06 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA13141 for ; Thu, 19 Oct 2000 14:36:03 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 073784433A; Thu, 19 Oct 2000 13:36:06 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 0DE1744336 for ; Thu, 19 Oct 2000 13:35:08 -0400 (EDT) Received: from dynamicsoft.com (userab72.ie.uudial.com [212.120.133.172]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id OAA11024; Thu, 19 Oct 2000 14:36:50 -0400 (EDT) Message-ID: <39EF3ED3.9DA6E3DE@dynamicsoft.com> From: Chris Harris Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 Cc: sip@lists.bell-labs.com, discussion@sipforum.org, jainsip@Sun.COM Subject: Re: [SIPFORUM] Re: [SIP] JAIN SIP Specification References: Content-Type: multipart/alternative; boundary="------------4B505C83AE98CD77F6B0967F" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 19 Oct 2000 19:35:00 +0100 --------------4B505C83AE98CD77F6B0967F Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi Orit, Yes, there is plenty to discuss at next week's meeting :) I totally agree that the Provider should be the master of transaction state - (by "master" I assume you mean who has absolute control). In fact I think the Provider should be the Master of everything it exports through the API. I believe this is the case in API as it stands... For example, an application invokes a send method on the Provider, which the Provider can reject. You could say the application is only making a request of the Provider, and the result of this request is given by a thrown exception or a returned transaction id. A similar situation exists for cancelling a transaction. Doesn't this fulfil the role of master you mention? Chris Orit Levin wrote: > Hello! > > I am sure we are going to have this discussion during the JAIN meeting > next week. But it is hard from not intervening here. > > The great benefit of SIP (compared to other competing technologies J) > is the abstraction it defines, starting from the low protocol’s level. > The lowest one is the “messages”. The next one is the “transaction”. > The next one is the “call (leg)”. > > In our case, we are talking about the keeper of the “Transactions > State machine”. This point is obvious. > > Based on the discussions here, yet another point is less obvious. In > order to define an efficient and interoperable API, there should be > (in my opinion, MUST) one single MASTER of the “Transactions State > machine”. The API itself should be driven by this main architectural > decision. It doesn’t preclude from “exporting” by this Master both the > “transaction states” and “the SIP messages”. It does not preclude from > providing by this Master “modification tools” for both transaction > state machine and the SIP messages. > > My point is, that depending on this FIRST decision, the semantic of > the “SIP messages API” part would be very different, even if its > syntax may look alike!!! > > Therefore, before diving into the API details, SPEC should define the > chosen model, clearly specifying the real “state machine” MASTER for > each abstraction level. This is the only way to define an > interoperable API. > > BTW, my technical opinion is to use the SIP design advantage at its > best and to define the Provider, to be the MASTER for the transaction > state machine. > > Best Regards, > > Orit Levin > > RADVision Inc. > > TEL: 201.529.4300 x 230 > > FAX:201.529.3516 > > mailto:orit@radvision.com > > http://www.radvision.com > > 575 Corporate Drive Suite 420 Mahwah, NJ 07430 > > -----Original Message----- > From: sip-admin@lists.bell-labs.com > [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Chris Harris > Sent: Thursday, October 19, 2000 9:30 AM > To: Itamar Gilad > Cc: sip@lists.bell-labs.com; discussion@sipforum.org; jainsip@Sun.COM > Subject: Re: [SIPFORUM] Re: [SIP] JAIN SIP Specification > > Hi Itamar, > > Sure - after all an application can completely ignore the transaction > ids given to it by the Provider, and use the send methods that don't > take transaction id parameters - the Provider has to cover both types > of application. > > Note that I don't necessarily think an application can't have an > object to represent a transaction, just that such an object must > operate through the Provider - since the Provider is supposed to be > the applications only access to the SIP stack. So you could have a > client transaction object containing the request sent returned by the > Provider, and have a cancel method on it - that calls the sendCancel > method on the Provider etc... But I'm not sure how useful this would > be - you are also forcing an application that is not interested in > transactions to extract messages from transaction objects. > > Then again, we could always define two JainSipListener subtypes - > JainSipMessageListener and JainSipTransactionListener...this might be > a good idea - then we can have an application indicate to the Provider > whether it is interested in transactions - if it isn't it just > receives Message objects, and if it is it receives Transaction objects > (incorporating the associated Messages) The Transaction objects > contain a transaction id, and can by ClientTransaction or > ServerTransaction, and their methods can call the Provider's methods > with the transaction id parameters. Opinions? > > I think incorporating call-legs and calls into the API is asking too > much of an API that deals with messages and transactions - unless we > create a JainSipCall(Leg)Listener...but now we're mandating that the > inderlying implementation has to keep call state...and above we have > to map JCC onto these...that could get very messy! > > Chris > > Itamar Gilad wrote: > > Hi Chris,It could be argued that it makes just as much sense for the > Provider to identify also the Call-Leg and Call. Still I think I > understand what you are after and I agree that this might help > applications that for some reason want to know about transaction > 'ids', but don't want to work with transaction objects. Regards > Itamar > -----Original Message----- > > From: Chris Harris [mailto:charris@dynamicsoft.com] > Sent: Thu, October 19, 2000 12:11 PM > To: sip@lists.bell-labs.com > Cc: discussion@sipforum.org; jainsip@Sun.COM > Subject: Re: [SIPFORUM] Re: [SIP] JAIN SIP Specification > > Hi Itamar, > > I can't really think of any applications other than a stateless proxy > that don't care about transactions. And since stateless proxies are > really just SIP routers and need maximum performance, I can't really > see anyone implementing them with JAIN SIP. > > I think any application that does anything interesting needs to know > about transactions, so the the JAIN SIP API should include some means > of identifying transactions or transaction control. But this has to > fit in with the Listener/Provider event model, so we can't hand a > Listener a transaction object that they can work with directly - we > need to give an application access to transactions through the > Provider. I thought a transaction id would be the simplest way to > achieve this. Do you have any suggestions for improving transaction > control for the event model? > > Chris > > Itamar Gilad wrote: > No, that's not it. The application uses a stack to do all of this. > The stack should export a message-related API like the one defined in > the JAIN SIP specification you presented. The stack should also > export interfaces for Call control and Transaction control. It seems > more logical for the application to use a transaction object which > handles messaging and notifies it whenever a message belonging to this > transaction is received rather then having a message object that tells > it which transaction it belongs too. Stateless proxies for example > would use only the message layer and they don't care at all about > transactions. I'm Sorry to be so picky, but I just think that this > makes for a cleaner design both in the application and in the stack. > Our experience with our SIP stack proves that this model works > fine.Itamar > -----Original Message----- > > From: Chris Harris [mailto:charris@dynamicsoft.com] > Sent: Wed, October 18, 2000 8:18 PM > To: discussion@sipforum.org > Cc: Itamar Gilad; 'Bobby Sardana'; mranga@nist.gov; > sip@lists.bell-labs.com; jainsip@Sun.COM > Subject: Re: [SIPFORUM] Re: [SIP] JAIN SIP Specification > > OK - so if an application just sends a message to the Provider, it has > to check all response messages to see if they match - this is so messy > for an application. What if a response message never arrives - how > should the Provider inform the application of a timeout? Call a > timeout method and pass the request message back? > > Itamar Gilad wrote: > Chris,I agree that few SIP applications would like to bother with > transaction mapping. This is clearly the responsibility of the stack > as is transaction management in general. However in a previous thread > you explained that the issue of managing call and transaction state is > outside the scope of this API specification, which led me to believe > that the goal is to define message-related functionality. I think that > injecting transaction keys into the mix is crossing the lines you > defined.Regards, Itamar > -----Original Message----- > > From: Chris Harris [mailto:charris@dynamicsoft.com] > Sent: Wed, October 18, 2000 7:44 PM > To: Itamar Gilad > Cc: 'Bobby Sardana'; discussion@sipforum.org; mranga@nist.gov; > sip@lists.bell-labs.com; jainsip@Sun.COM > Subject: Re: [SIPFORUM] Re: [SIP] JAIN SIP Specification > > Itamar, > > It is for the very reason that identifying a transaction from a > message is not a trivial matter that I wanted to put the transaction > handling inside the JainSipProvider. I don't think the spec should > just deal with just the message layer. How many people are going to > write JAIN SIP applications if they have to implement their own > transaction keys? I'd imagine very few. > > Regards, > Chris > > Itamar Gilad wrote: > Hi again Chris,I'd like to re-emphasize what Bobby says below. The > JAIN SIP specification presented here seems to deal just with the > "message layer" i.e. parsing, encoding, message and message part > containers. I'd like to join those who commend the fine and > comprehensive work done. However, this layer has nothing to do with > transactions and their state. It would be a mistake to rely on it to > retain 'transaction-ids' and associate messages to them (please > correct me if I'm misinterpreting your meaning). Note that identifying > a transaction from a message is not a trivial matter and continuously > more message fields are added to the "transaction key" in order to > deal with spiraling, merging etc. A more straight-forward approach > would be to put this functionality in the "transaction layer" where > transaction objects live and make a clean separation between the two > layers.Regards Itamar > > -----Original Message----- > From: Bobby Sardana [mailto:bobby.sardana@mobilerain.com] > Sent: Wed, October 18, 2000 6:39 PM > To: discussion@sipforum.org > Cc: mranga@nist.gov; sip@lists.bell-labs.com; jainsip@sun.com > Subject: Re: [SIPFORUM] Re: [SIP] JAIN SIP Specification > Greetings Chris: > > Just to add a pointer to this thread: > > Maintaining trasaction state is an application level functionality and > *shouldn't* be implemented in the base stack. For applications like > state oriented proxy server, the JAIN SIP can provide enough hooks for > event delivery but the state has to be maintained by the proxy > server. > > Pleas keep up the good work. It is really appreciated. > > Regards, > > Bobby.Sardana@mobilerain.com > > Chris Harris wrote: > "M. Ranganathan" wrote: > Hi Chris, > > Thanks for replying so promptly (I am sure you are flooded with email > ). > I get one or two :) > > As you pointed out, I suppose we cannot do away with making Messages > into classes because of the tie-in with java events (unfortunately) > but > I still like the notion of being able to specify interfaces where > ever > possible. > I see where you're coming from alright, and I suppose changing header > classes into interfaces, could fit in with Gethin's proposal nicely? > > I dont quite follow the motivation behind the following design > decision (excerpted from your reply): > > Maybe I've misunderstood what you're saying - but a JAIN SIP > implementation is only stateless when it comes to call state. The > JainSipProvider implementation must maintain transaction state - it > simply exposes a reference to a transaction via the transaction id for > > the convenience of the JainSipListener. The service does not have > total > control over transacton state - the stack implementation does. > > It appears that I have indded mis-understood the architecture. Why > should the above be so? Can one not rely on the JainSipListener to > keep > transaction state also, thereby making the stack simply a way of > recognising messages and triggering event handlers on the basis of > message type. This would (IMHO) be a cleaner model yet. That way, > we > can do away with transaction identifiers being passed back and forth > and > keep all of this information in the handler. ( You may have to extend > > the architecture somewhat to deal with timeouts and failures so that > the > handler knows about transaction failure.) In any case, if this is not > a > viable idea, I would be grateful if you can explain why not (or point > me > to the portion of the spec that explains why not) so I can get a > better > understanding. > It would be cleaner model, and personally I am in total agreement with > you - but it means the application is forced to maintain transaction > state, match up headers - which has been said places too much of a > burden on applications. How about finding a way to let the application > choose whether or not it wants to keep transaction state? > > Regards, > > Ranga. > > Chris Harris wrote: > > > Hi Ranga, > > > > Response below... > > > > Chris > > > > "M. Ranganathan" wrote: > > > >> JAIN-SIP is a groovy idea. Hats off to the whole concept and many > >> thanks to Chris and > >> the JAIN-SIP team for putting together a spec and more flower power > > >> to them :-) . In > >> particular I like the notion of treating UAS, Redirect and Proxy > >> servers as merely > >> special cases of the general notion of Services and the idea of > >> unifying these > >> notions with an event mechanism and event handlers. Second, I > like > >> the idea of > >> separation between a stateless event -oriented "stack" and a > bunch > >> of event > >> handlers that are triggered by the stack with all state (including > >> transaction > >> state) being separated from the event stack via the JAIN-SIP > mapping > >> layer if you > >> will. ( Correct me if I wax poetic but have the wrong > >> understanding....) > > > >> > >> > >> I hope I will not be viewed as being too critical, but I would > >> like to go one step > >> further than what Gethin is suggesting. I am all for using > >> interfaces as much as > >> possible and leaving class hierarchy definitions to implemeters. > >> Defining class > >> hierarchies almost lays out an implementation and involves > >> considerable rework for > >> those who have a working java-based stack, but have not used the > >> same classes. OK it > >> is just a matter of labor to map things to the JAIN-SIP class > >> hierarchy but it IS a > >> dis-incentive. > >> > >> 1. Lets use interfaces for all messages rather than actually define > > >> class > >> hierarchies ( yes Chris has pointed out the historical precedent > >> behind actually > >> defining class hierarchies for messages. IMHO, there has to be a > >> more compelling > >> reason than that.) > > > > I suppose all classes could be turned into interfaces, except for > the > > Message classes which must extend java.util.EventObject to fit into > > the JAIN framework. > > > >> > >> > >> 2. The tie-in with the JAVA event mechanism has necessitated the > >> explicit definition > >> of class hierarchies in certain places. Why not use callbacks > >> instead and do away > >> with this dependency as well? (Basically the same thing as events > >> but does not tie > >> into the JAVA event mechanism and its associated limitations.) > > > > Unfortunately the JAIN framework expilicitly relies on the Java > Event > > model, and I don't think callbacks would be accepted within the JAIN > > > community. > > > >> > >> > >> Nice work and keep it rolling! Thanks. > > > > Couldn't do it without you guys - thank you! > > > >> > >> > >> Ranga. > >> > >> Gethin Liddell wrote: > >> > >> > All, > >> > > >> > This idea of abstraction of the JAIN API is certainly a valid and > > >> > interesting idea. However, i'm a bit concerened that the > proposed > >> > >> > solution of many different packages, will only seek to complicate > > >> and > >> > maybe enlarge the API. > >> > > >> > I too see no reason why there is an EntityHeader etc... and i > also > >> do > >> > not see any requirement for an InviteMessage, AckMessage etc... > >> > > >> > How about if the format of the API remains as is: > >> > > >> > jain.protocol.ip.sip > >> > jain.protocol.ip.sip.header > >> > jain.protocol.ip.sip.message > >> > > >> > except that the messages available in the message package > >> consisted of > >> > BasicRequest/Response, MinimalRequest/Response etc... where each > >> > message is extened in turn (e.g. Minimal extends Basic, Moderate > >> > extends Minimal etc...), of course as Chris points out it is not > >> hard > >> > to see that a combination would be required that is not provided. > > >> So > >> > in the interest of flexibility, it could be possible for the user > > >> to > >> > plug-in to the message class what extra headers it requires. The > > >> only > >> > issue then is that the user will have to use a "public Header > >> > getHeader(String headerName)" and then cast the header to their > >> desired > >> > header type. Either that or create their own Message class > >> > (extending the current ones) that simply does the casting > >> automatically > >> > for them. Then after compiling, run an obfuscator on the code > and > >> it > >> > will automatically extract and only extract the Message, Headers > >> and > >> > even methods that are used. > >> > > >> > This then will also cut down on the number of methods in the > >> Provider > >> > as there will be no need for the sendAck(AckMessage), > >> > sendInvite(InviteMessage) etc.. as they would be replaced by the > >> > single method sendRequest(RequestMessage). > >> > > >> > I personally see three arguments for keeping the JAIN SIP stack > as > >> small > >> > as possible: > >> > > >> > 1) The first is for embedded applications where stack size has to > > >> be > >> > kept to a minimum as memory is at a premium. So if just using > the > >> > >> > Basic message suffices then this will compile and run with a > small > >> > >> > number of classes present from the stack. Don't forget, > >> obfuscation > >> > will help in extracting only the Messages, Headers and even > >> methods > >> > required from a jar file but it won't do everything. > >> > > >> > 2) The second is that users may be put off or confused by the > >> sheer > >> > size and complexity of the JAIN stack. So if only using the > >> > BasicMessage gets them on the first rung of the ladder then it is > > >> a > >> > good starting point and allows them to build up to bigger and > >> better > >> > things. > >> > > >> > 3) We also have to consider who is going to implement the JAIN > SIP > >> > >> > stack. If it is indeed overly complicated then no-one or a single > > >> > vendor may end up implmenting the stack and thus its definition > >> and > >> > all the hard work that has gone into it is useless. > >> > > >> > On Mon, 16 Oct 2000, Chris Harris wrote: > >> > > Itamar, > >> > > > >> > > The idea of levelling the API based on what messages, headers > >> and response codes > >> > > are understood is certainly an interesting one - minimal, > basic, > >> redirection, > >> > > firewall-friendly, negotiation, authentication and "full". > >> > > > >> > > jain.protocol.ip.sip > >> > > jain.protocol.ip.sip.header > >> > > jain.protocol.ip.sip.message > >> > > > >> > > could then become... > >> > > > >> > > jain.protocol.ip.sip - listener, provider, stack, general > >> classes used at all > >> > > levels > >> > > jain.protocol.ip.sip.header - contains base Header class (and > >> requestHeader, > >> > > ResponseHeader, EntityHeader, GeneralHeader) > >> > > jain.protocol.ip.sip.message - contains base Message class > >> > > > >> > > jain.protocol.ip.sip.minimal - general classes used only at > this > >> level and above > >> > > > >> > > jain.protocol.ip.sip.minimal.header - headers used only at this > > >> level and above > >> > > jain.protocol.ip.sip.minimal.message - messages only used at > >> this level and > >> > > above > >> > > > >> > > jain.protocol.ip.sip.basic - general classes used only at this > >> level and above > >> > > jain.protocol.ip.sip.basic.header - headers used only at this > >> level and above > >> > > jain.protocol.ip.sip.basic.message - messages used only at this > > >> level and above > >> > > ... > >> > > .... > >> > > jjain.protocol.ip.sip."full" - general classes only used at > this > >> level > >> > > jain.protocol.ip.sip."full".header - headers used only at this > >> level > >> > > jain.protocol.ip.sip."full".message - messages used only at > this > >> level > >> > > > >> > > The API user could then pick the packages they need - say they > >> initially only > >> > > want the minimal features, but then realise they need to use > >> their application > >> > > behind a firewall - then they can simply add the > >> firewall-friendly package. The > >> > > RFC says "In general, each capability listed builds on the ones > > >> above it" but it > >> > > is not hard to see that firewall-friendly and authentication > may > >> be desired > >> > > without redirection for example. > >> > > > >> > > Is this what you hand in mind Itamar? > >> > > >> > -- > >> > Gethin Liddell > >> > Ubiquity Software Corporation > >> > > >> > http://www.ubiquity.net > >> > mailto:gethin@ubiquity.net > >> > > >> > _______________________________________________ > >> > SIP mailing list > >> > SIP@lists.bell-labs.com > >> > http://lists.bell-labs.com/mailman/listinfo/sip > >> > >> -- > >> M.Ranganathan > >> NIST Advanced Networking Technologies Group, > >> 100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899. > >> Tel: 301 975 3664 Fax: 301 590 0932 > >> > >> Hfæj)b? b²Ô^>X¬¶ÆÞ-YZnÇ(sm§ÿåSËlmée*¦ìr?¿?¨¥?©ÿ-+-SwèþÈ© > > > > -- > M.Ranganathan > NIST Advanced Networking Technologies Group, > 100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899. > Tel: 301 975 3664 Fax: 301 590 0932 > > Hfæj)b? b²Ô^>X¬¶ÆÞ-YZnÇ(sm§ÿåSËlmée*¦ìr?¿?¨¥?©ÿ-+-SwèþÈ© > --------------4B505C83AE98CD77F6B0967F Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi Orit,

Yes, there is plenty to discuss at next week's meeting :)

I totally agree that the Provider should be the master of transaction state - (by "master" I assume you mean who has absolute control). In fact I think the Provider should be the Master of everything it exports through the API. I believe this is the case in API as it stands...

For example, an application invokes a send method on the Provider, which the Provider can reject. You could say the application is only making a request of the Provider, and the result of this request is given by a thrown exception or a returned transaction id. A similar situation exists for cancelling a transaction.

Doesn't this fulfil the role of master you mention?

Chris
 

Orit Levin wrote:

Hello!

I am sure we are going to have this discussion during the JAIN meeting next week. But it is hard from not intervening here.

The great benefit of SIP (compared to other competing technologies J) is the abstraction it defines, starting from the low protocol’s level. The lowest one is the “messages”. The next one is the “transaction”. The next one is the “call (leg)”. 

In our case, we are talking about the keeper of the “Transactions State machine”. This point is obvious.

Based on the discussions here, yet another point is less obvious. In order to define an efficient and interoperable API, there should be (in my opinion, MUST) one single MASTER of the “Transactions State machine”. The API itself should be driven by this main architectural decision. It doesn’t preclude from “exporting” by this Master both the “transaction states” and “the SIP messages”. It does not preclude from providing by this Master “modification tools” for both transaction state machine and the SIP messages.

My point is, that depending on this FIRST decision, the semantic of the “SIP messages API” part would be very different, even if its syntax may look alike!!!

Therefore, before diving into the API details, SPEC should define the chosen model, clearly specifying the real “state machine” MASTER for each abstraction level. This is the only way to define an interoperable API.

BTW, my technical opinion is to use the SIP design advantage at its best and to define the Provider, to be the MASTER for the transaction state machine.

Best Regards,

Orit Levin

RADVision Inc.

TEL: 201.529.4300 x 230

FAX:201.529.3516

mailto:orit@radvision.com

http://www.radvision.com 

575 Corporate Drive Suite 420 Mahwah, NJ 07430

-----Original Message-----
From: sip-admin@lists.bell-labs.com [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Chris Harris
Sent: Thursday, October 19, 2000 9:30 AM
To: Itamar Gilad
Cc: sip@lists.bell-labs.com; discussion@sipforum.org; jainsip@Sun.COM
Subject: Re: [SIPFORUM] Re: [SIP] JAIN SIP Specification

Hi Itamar, 

Sure - after all an application can completely ignore the transaction ids given to it by the Provider, and use the send methods that don't take transaction id parameters - the Provider has to cover both types of application. 

Note that I don't necessarily think an application can't have an object to represent a transaction, just that such an object must operate through the Provider - since the Provider is supposed to be the applications only access to the SIP stack. So you could have a client transaction object containing the request sent returned by the Provider, and have a cancel method on it - that calls the sendCancel method on the Provider etc... But I'm not sure how useful this would be - you are also forcing an application that is not interested in transactions to extract messages from transaction objects. 

Then again, we could always define two JainSipListener subtypes - JainSipMessageListener and JainSipTransactionListener...this might be a good idea - then we can have an application indicate to the Provider whether it is interested in transactions - if it isn't it just receives Message objects, and if it is it receives Transaction objects (incorporating the associated Messages) The Transaction objects contain a transaction id, and can by ClientTransaction or ServerTransaction, and their methods can call the Provider's methods with the transaction id parameters. Opinions? 

I think incorporating call-legs and calls into the API is asking too much of an API that deals with messages and transactions - unless we create a JainSipCall(Leg)Listener...but now we're mandating that the inderlying implementation has to keep call state...and above we have to map JCC onto these...that could get very messy! 

Chris 

Itamar Gilad wrote: 

Hi Chris,It could be argued that it makes just as much sense for the Provider to identify also the Call-Leg and Call. Still I think I understand what you are after and I agree that this might help applications that for some reason want to know about transaction 'ids', but don't want to work with transaction objects. Regards   Itamar 

-----Original Message-----

From: Chris Harris [mailto:charris@dynamicsoft.com]
Sent: Thu, October 19, 2000 12:11 PM
To: sip@lists.bell-labs.com
Cc: discussion@sipforum.org; jainsip@Sun.COM
Subject: Re: [SIPFORUM] Re: [SIP] JAIN SIP Specification

Hi Itamar, 

I can't really think of any applications other than a stateless proxy that don't care about transactions. And since stateless proxies are really just SIP routers and need maximum performance, I can't really see anyone implementing them with JAIN SIP. 

I think any application that does anything interesting needs to know about transactions, so the the JAIN SIP API should include some means of identifying transactions or transaction control. But this has to fit in with the Listener/Provider event model, so we can't hand a Listener a transaction object that they can work with directly - we need to give an application access to transactions through the Provider. I thought a transaction id would be the simplest way to achieve this. Do you have any suggestions for improving transaction control for the event model? 

Chris

Itamar Gilad wrote: 

No, that's not it.  The application uses a stack to do all of this.  The stack should export a message-related API like the one defined in the JAIN SIP specification you presented.  The stack should also export interfaces for Call control and Transaction control.  It seems more logical for the application to use a transaction object which handles messaging and notifies it whenever a message belonging to this transaction is received rather then having a message object that tells it which transaction it belongs too.  Stateless proxies for example would use only the message layer and they don't care at all about transactions. I'm Sorry to be so picky, but I just think that this makes for a cleaner design both in the application and in the stack.  Our experience with our SIP stack proves that this model works fine.Itamar
-----Original Message-----

From: Chris Harris [mailto:charris@dynamicsoft.com]
Sent: Wed, October 18, 2000 8:18 PM
To: discussion@sipforum.org
Cc: Itamar Gilad; 'Bobby Sardana'; mranga@nist.gov; sip@lists.bell-labs.com; jainsip@Sun.COM
Subject: Re: [SIPFORUM] Re: [SIP] JAIN SIP Specification

OK - so if an application just sends a message to the Provider, it has to check all response messages to see if they match - this is so messy for an application. What if a response message never arrives - how should the Provider inform the application of a timeout? Call a timeout method and pass the request message back? 

Itamar Gilad wrote: 

Chris,I agree that few SIP applications would like to bother with transaction mapping.  This is clearly the responsibility of the stack as is transaction management in general. However in a previous thread you explained that the issue of managing call and transaction state is outside the scope of this API specification, which led me to believe that the goal is to define message-related functionality. I think that injecting transaction keys into the mix is crossing the lines you defined.Regards,  Itamar
-----Original Message-----

From: Chris Harris [mailto:charris@dynamicsoft.com]
Sent: Wed, October 18, 2000 7:44 PM
To: Itamar Gilad
Cc: 'Bobby Sardana'; discussion@sipforum.org; mranga@nist.gov; sip@lists.bell-labs.com; jainsip@Sun.COM
Subject: Re: [SIPFORUM] Re: [SIP] JAIN SIP Specification

Itamar,

It is for the very reason that identifying a transaction from a message is not a trivial matter that I wanted to put the transaction handling inside the JainSipProvider. I don't think the spec should just deal with just the message layer. How many people are going to write JAIN SIP applications if they have to implement their own transaction keys? I'd imagine very few. 

Regards,
Chris 

Itamar Gilad wrote: 

Hi again Chris,I'd like to re-emphasize what Bobby says below.  The JAIN SIP specification presented here seems to deal just with the "message layer" i.e. parsing, encoding, message and message part containers.  I'd like to join those who commend the fine and comprehensive work done.  However, this layer has nothing to do with transactions and their state.  It would be a mistake to rely on it to retain 'transaction-ids' and associate messages to them (please correct me if I'm misinterpreting your meaning). Note that identifying a transaction from a message is not a trivial matter and continuously more message fields are added to the "transaction key" in order to deal with spiraling, merging etc. A more straight-forward approach would be to put this functionality in the "transaction layer" where transaction objects live and make a clean separation between the two layers.Regards Itamar

-----Original Message-----
From: Bobby Sardana [mailto:bobby.sardana@mobilerain.com]
Sent: Wed, October 18, 2000 6:39 PM
To: discussion@sipforum.org
Cc: mranga@nist.gov; sip@lists.bell-labs.com; jainsip@sun.com
Subject: Re: [SIPFORUM] Re: [SIP] JAIN SIP Specification
Greetings Chris: 

Just to add a pointer to this thread: 

Maintaining trasaction state is an application level functionality and *shouldn't* be implemented in the base stack. For applications like state oriented proxy server, the JAIN SIP can provide enough hooks for event delivery but the state has to be maintained by the proxy server. 

Pleas keep up the good work. It is really appreciated. 

Regards,

Bobby.Sardana@mobilerain.com

Chris Harris wrote: 

"M. Ranganathan" wrote: 
Hi Chris, 

Thanks for replying so promptly (I am sure you are flooded with email ).

I get one or two :)

As you pointed out, I suppose we cannot do away with making Messages
into classes because of the tie-in with java events (unfortunately) but
I still like the notion of being able to specify  interfaces where ever
possible.
I see where you're coming from alright, and I suppose changing header classes into interfaces, could fit in with Gethin's proposal nicely?

 I dont quite follow  the motivation behind the following design
decision (excerpted from your reply): 

Maybe I've misunderstood what you're saying - but a JAIN SIP
implementation is only stateless when it comes to call state. The
JainSipProvider implementation must maintain transaction state - it
simply exposes a reference to a transaction via the transaction id for
the convenience of the JainSipListener. The service does not have total
control over transacton state - the stack implementation does. 

It appears that I have indded mis-understood the architecture.  Why
should the above be so? Can one not rely on the JainSipListener to keep
transaction state also, thereby making the stack simply a way of
recognising messages and triggering  event handlers on the basis of
message type. This would (IMHO) be a cleaner model yet.    That way,  we
can do away with transaction identifiers being passed back and forth and
keep all of this information in the handler.  ( You may have to extend
the architecture somewhat to deal with timeouts and failures so that the
handler knows about transaction failure.) In any case, if this is not a
viable idea, I would be grateful if you can explain why not (or point me
to the portion of the spec that explains why not) so I can get a better
understanding.

It would be cleaner model, and personally I am in total agreement with you - but it means the application is forced to maintain transaction state, match up headers - which has been said places too much of a burden on applications. How about finding a way to let the application choose whether or not it wants to keep transaction state?

Regards,

Ranga.

Chris Harris wrote: 

> Hi Ranga,
>
> Response below...
>
> Chris
>
> "M. Ranganathan" wrote:
>
>> JAIN-SIP is a groovy idea. Hats off to the whole concept and many
>> thanks to Chris and
>> the JAIN-SIP team for putting together a spec and more flower power
>> to them :-) .  In
>> particular I like the notion of treating UAS,  Redirect and Proxy
>> servers as merely
>> special cases of the general notion of Services and  the idea of
>> unifying these
>> notions with an event mechanism and  event handlers.  Second, I like
>> the idea of
>> separation between a  stateless  event -oriented "stack" and a bunch
>> of event
>> handlers that are triggered by the stack with all state (including
>> transaction
>> state) being separated from the event stack via the JAIN-SIP mapping
>> layer if you
>> will.  ( Correct me if I  wax poetic but have the wrong
>> understanding....)
>
>>
>>
>> I hope I  will not be viewed as being too critical,  but I would
>> like to go  one step
>> further than what Gethin is suggesting.   I am all for using
>> interfaces as much as
>> possible and leaving class hierarchy definitions to implemeters.
>> Defining class
>> hierarchies almost lays out an implementation and involves
>> considerable rework for
>> those who have a working java-based stack, but have not used the
>> same classes. OK it
>> is just a matter of labor to map things to the JAIN-SIP class
>> hierarchy but it  IS a
>> dis-incentive.
>>
>> 1. Lets use interfaces for all messages rather than actually define
>> class
>> hierarchies  ( yes Chris has pointed out the historical precedent
>> behind actually
>> defining class hierarchies for messages. IMHO,  there has to be a
>> more compelling
>> reason than that.)
>
> I suppose all classes could be turned into interfaces, except for the
> Message classes which must extend java.util.EventObject to fit into
> the JAIN framework.
>
>>
>>
>> 2. The tie-in with the JAVA event mechanism has necessitated the
>> explicit definition
>> of class hierarchies in certain places.  Why not use callbacks
>> instead and do away
>> with this dependency as well?  (Basically the same thing as events
>> but does not tie
>> into the JAVA event mechanism and its associated limitations.)
>
> Unfortunately the JAIN framework expilicitly relies on the Java Event
> model, and I don't think callbacks would be accepted within the JAIN
> community.
>
>>
>>
>> Nice work and keep it rolling!  Thanks.
>
> Couldn't do it without you guys - thank you!
>
>>
>>
>> Ranga.
>>
>> Gethin Liddell wrote:
>>
>> > All,
>> >
>> > This idea of abstraction of the JAIN API is certainly a valid and
>> > interesting idea.  However, i'm a bit concerened that the proposed
>>
>> > solution of many different packages, will only seek to complicate
>> and
>> > maybe enlarge the API.
>> >
>> > I too see no reason why there is an EntityHeader etc... and i also
>> do
>> > not see any requirement for an InviteMessage, AckMessage etc...
>> >
>> > How about if the format of the API remains as is:
>> >
>> > jain.protocol.ip.sip
>> > jain.protocol.ip.sip.header
>> > jain.protocol.ip.sip.message
>> >
>> > except that the messages available in the message package
>> consisted of
>> > BasicRequest/Response, MinimalRequest/Response etc... where each
>> > message is extened in turn (e.g. Minimal extends Basic, Moderate
>> > extends Minimal etc...), of course as Chris points out it is not
>> hard
>> > to see that a combination would be required that is not provided.
>> So
>> > in the interest of flexibility, it could be possible for the user
>> to
>> > plug-in to the message class what extra headers it requires.  The
>> only
>> > issue then is that the user will have to use a "public Header
>> > getHeader(String headerName)" and then cast the header to their
>> desired
>> > header type. Either that or create their own Message class
>> > (extending the current ones) that simply does the casting
>> automatically
>> > for them.  Then after compiling, run an obfuscator on the code and
>> it
>> > will automatically extract and only extract the Message, Headers
>> and
>> > even methods that are used.
>> >
>> > This then will also cut down on the number of methods in the
>> Provider
>> > as there will be no need for the sendAck(AckMessage),
>> > sendInvite(InviteMessage) etc.. as they would be replaced by the
>> > single method sendRequest(RequestMessage).
>> >
>> > I personally see three arguments for keeping the JAIN SIP stack as
>> small
>> > as possible:
>> >
>> > 1) The first is for embedded applications where stack size has to
>> be
>> > kept to a minimum as memory is at a premium.  So if just using the
>>
>> > Basic message suffices then this will compile and run with a small
>>
>> > number of classes present from the stack.  Don't forget,
>> obfuscation
>> > will help in extracting only the Messages, Headers and even
>> methods
>> > required from a jar file but it won't do everything.
>> >
>> > 2) The second is that users may be put off or confused by the
>> sheer
>> > size and complexity of the JAIN stack.  So if only using the
>> > BasicMessage gets them on the first rung of the ladder then it is
>> a
>> > good starting point and allows them to build up to bigger and
>> better
>> > things.
>> >
>> > 3) We also have to consider who is going to implement the JAIN SIP
>>
>> > stack. If it is indeed overly complicated then no-one or a single
>> > vendor may end up implmenting the stack and thus its definition
>> and
>> > all the hard work that has gone into it is useless.
>> >
>> > On Mon, 16 Oct 2000, Chris Harris wrote:
>> > > Itamar,
>> > >
>> > > The idea of levelling the API based on what messages, headers
>> and response codes
>> > > are understood is certainly an interesting one - minimal, basic,
>> redirection,
>> > > firewall-friendly, negotiation, authentication and "full".
>> > >
>> > > jain.protocol.ip.sip
>> > > jain.protocol.ip.sip.header
>> > > jain.protocol.ip.sip.message
>> > >
>> > > could then become...
>> > >
>> > > jain.protocol.ip.sip - listener, provider, stack, general
>> classes used at all
>> > > levels
>> > > jain.protocol.ip.sip.header - contains base Header class (and
>> requestHeader,
>> > > ResponseHeader, EntityHeader, GeneralHeader)
>> > > jain.protocol.ip.sip.message - contains base Message class
>> > >
>> > > jain.protocol.ip.sip.minimal - general classes used only at this
>> level and above
>> > >
>> > > jain.protocol.ip.sip.minimal.header - headers used only at this
>> level and above
>> > > jain.protocol.ip.sip.minimal.message - messages only used at
>> this level and
>> > > above
>> > >
>> > > jain.protocol.ip.sip.basic - general classes used only at this
>> level and above
>> > > jain.protocol.ip.sip.basic.header - headers used only at this
>> level and above
>> > > jain.protocol.ip.sip.basic.message - messages used only at this
>> level and above
>> > > ...
>> > > ....
>> > > jjain.protocol.ip.sip."full" - general classes only used at this
>> level
>> > > jain.protocol.ip.sip."full".header - headers used only at this
>> level
>> > > jain.protocol.ip.sip."full".message - messages used only at this
>> level
>> > >
>> > > The API user could then pick the packages they need - say they
>> initially only
>> > > want the minimal features, but then realise they need to use
>> their application
>> > > behind a firewall - then they can simply add the
>> firewall-friendly package. The
>> > > RFC says "In general, each capability listed builds on the ones
>> above it" but it
>> > > is not hard to see that firewall-friendly and authentication may
>> be desired
>> > > without redirection for example.
>> > >
>> > > Is this what you hand in mind Itamar?
>> >
>> > --
>> > Gethin Liddell
>> > Ubiquity Software Corporation
>> >
>> > http://www.ubiquity.net
>> > mailto:gethin@ubiquity.net
>> >
>> > _______________________________________________
>> > SIP mailing list
>> > SIP@lists.bell-labs.com
>> > http://lists.bell-labs.com/mailman/listinfo/sip
>>
>> --
>> M.Ranganathan
>> NIST Advanced Networking Technologies Group,
>> 100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899.
>> Tel: 301 975 3664 Fax: 301 590 0932
>>
>> Hfæj)b? b²Ô^>X¬¶ÆÞ-YZnÇ(sm§ÿåSËlmée*¦ìr?¿?¨¥?©ÿ-+-SwèþÈ©
> 

--
M.Ranganathan
NIST Advanced Networking Technologies Group,
100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899.
Tel: 301 975 3664 Fax: 301 590 0932 

Hfæj)b? b²Ô^>X¬¶ÆÞ-YZnÇ(sm§ÿåSËlmée*¦ìr?¿?¨¥?©ÿ-+-SwèþÈ©

--------------4B505C83AE98CD77F6B0967F-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Oct 19 15:07:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA19764 for ; Thu, 19 Oct 2000 15:07:02 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 142434433A; Thu, 19 Oct 2000 14:07:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from thalia.fm.intel.com (thalia.fm.intel.com [132.233.247.11]) by lists.bell-labs.com (Postfix) with ESMTP id 6172644336 for ; Thu, 19 Oct 2000 14:06:31 -0400 (EDT) Received: from SMTP (fmsmsxvs01-1.fm.intel.com [132.233.42.201]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.32 2000/10/12 22:57:04 dmccart Exp $) with SMTP id TAA05608 for ; Thu, 19 Oct 2000 19:07:41 GMT Received: from fmsmsx17.intel.com ([132.233.48.17]) by 132.233.48.201 (Norton AntiVirus for Internet Email Gateways 1.0) ; Thu, 19 Oct 2000 19:06:25 0000 (GMT) Received: by fmsmsx17.fm.intel.com with Internet Mail Service (5.5.2650.21) id <4VB8P076>; Thu, 19 Oct 2000 12:06:24 -0700 Message-ID: From: "Singh, Manish" To: "'sip@lists.bell-labs.com'" Subject: [SIP] Multicast Registration MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 19 Oct 2000 12:06:21 -0700 > Hi, > > Section 4.2.6 of the RFC2543 says : > > "It is RECOMMENDED that the UA registers via multicast and send a > registration to its > "home" address, i.e, the server for the domain that it uses as its From > address in outgoing > requests. > > Multicast reqistrations are addressed to the well known "all SIP servers" > multicast address > "sip.mcast.net". > > RFC further adds : " SIP UAs MAY listen to that address......, however > they do not respond > to the request". > > From this I understand that a UA will send a multicast REGISTER request to > "sip.mcast.net" > as well as a unicast REGISTER request to the domain Registrar server, > that it uses as its > From address. > > Pls clarify the following : > > - Does the term "all SIP servers" include standalone Registrar servers? > > - Should the Registrar server listen to the multicast address and accept > registrations? > > - If it should, then should registrar server respond to such REGISTER > requests? > > - Should the UA which issues the REGISTER request, expect multiple 2xx > responses for it. > > Thanks, > Manish > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Oct 19 15:29:08 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA24438 for ; Thu, 19 Oct 2000 15:29:05 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A016544344; Thu, 19 Oct 2000 14:29:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from smtprch2.nortel.com (smtprch2.nortelnetworks.com [192.135.215.15]) by lists.bell-labs.com (Postfix) with ESMTP id 79E6A4433C for ; Thu, 19 Oct 2000 14:28:41 -0400 (EDT) Received: from zrchb200.us.nortel.com (actually zrchb200) by smtprch2.nortel.com; Thu, 19 Oct 2000 14:22:41 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2652.35) id <4VMDDASX>; Thu, 19 Oct 2000 14:26:43 -0500 Message-ID: <36FA02BD7083D411BC9E0000F8073E43F31A06@crchy271.us.nortel.com> From: "Brian Stucker" To: Christer Holmberg , sip@lists.bell-labs.com Cc: hammer michael Subject: RE: [SIP] Session-timer with INFO MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C03A02.7FF7DD70" X-Orig: Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 19 Oct 2000 14:26:37 -0500 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_01C03A02.7FF7DD70 Content-Type: text/plain; charset="iso-8859-1" Your correct, I can't stop the UAC from sending the method again, but I'd like to plead to as many implementors as I can that it would definitely be preferable in any setting if you wouldn't. =) Brian -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] Sent: Tuesday, October 17, 2000 9:00 AM To: sip@lists.bell-labs.com Cc: hammer michael Subject: Re: [SIP] Session-timer with INFO Hi, If I send you an INFO, or any other method that you don't support, you can for example send a 501 Not Implemented response, and include an Allow header with the methods you support. Of course, you can't stop the UAC of sending the method again, if he chooses to... You can not, however, tell an UAC not to send you re-INVITEs, because then you would also forbid the UAC to send you INVITEs - and I don't think you want to do that. Also, the specification says that a UA MUST be able to receive INVITEs (which included re-INVITEs), so... Regards, Christer Holmberg Ericsson Finland hammer michael wrote: > > Is this the Internet version of "let them eat cake?" Signal-spam is not > more palatable than the normal variety. > > Is there a response code that can indicate the sentiment: I don't support > this method, don't try it again? It might also be good to make sure that > such undesirable sub-methods are indicated as "Unsupported." If that > sub-method is well-defined, then that header parameter should be applicable. > > Mike > > At 12:30 AM 10/17/2000 +0300, Christer Holmberg wrote: > > >Hi, > > > > >Good points. Here's one more problem you may want to consider. > > >Whenever you invoke a ping-style method of deciding if a session is > > >alive, you open up problems due to network jitter and bandwidth. For > > >instance, you could easily have a packet delayed at an endpoint due to > > >a large file transfer starting up, or some other bandwidth consuming > > >event. In this case, your ping could be delayed long enough to cause > > >the session to drop for no good reason. > > > >Well, this could be the case no matter which method (INVITE, INFO, or > >whatever...) you use in the heartbeat request... > > > > >You're also creating the potential for artificial problems in wireless > > >networks by using a ping-method to keep a session alive. During a > > >handover there may be a period where packets are in effect "muted" for > > >a short period of time. The mute period may not, by itself be long > > >enough to trigger a ping-timer to pop and kill the session, but if the > > >ping was near the edge of the time envelope to be accepted as > > >"on-time" anyhow, once again, your session could very easily drop when > > >the media was operating just fine. > > >Also, keep in mind, the longer you set the ping timer for, the more > > >network resources you will likely waste over time because of the > > >additional latentcy in discovering a "dead" session. > > > >Just to clarify, this "ping-method" IS already defined for SIP > >(draft-ietf-sip-session-timer-02.txt), and re-INVITEs are used to ping. > >My idea was about replacing the re-INVITE with INFO, which mean we would > >actually save resources since we don't have to send ACK every time. > > > > >This method has one other nasty side-effect. You'd be wasting network > > >resources on an event that will likely not occur very often. After > > >all, every INFO exchange except the very last one that invalidates the > > >session could have very well not been sent without any negative impact > > >on the session (otherwise they would have been the last one). So > > >you've got proxies and UAs, and other transport resources being tied > > >up processing packets that by and large are providing no value, and > > >they're chewing up bandwidth budget that other services could be using > > >instead. > > > >That is an interesting point, and it is valid also for a number of other > >SIP extensions where extra messages are sent (e.g. PRACK), but it is > >another discussion. > > > > >Please keep in mind that not everyone is looking at implementing SIP > > >on a 10Mbit+ hardwired LAN (or has to scale up to tremendous numbers > > >of users), pinging and triangle-routing can be the death-knell of > > >these sorts of networks. > > > >Who said "bandwidth is free"? :) > > > > >Because of all of this, I think it would be a very bad idea for a UA > > >to send an INFO to a client who repeatedly tells him "I don't > > >understand INFO" to see if he's alive. > > > >The number of messages on the network will be the same no matter if we > >send an INVITE which he understands, or an INFO he may not understand. > >Also, when we receive the response for the INVITE we also have to send > >back an ACK, which is not the case when INFO is used. > > > > >He may not understand INFO because that particular network doesn't > > deem >the bandwidth required for this mechanism as being best used for > > that >purpose. If someone tells you "don't send me this method" then > > don't send >it to them. > > > >Again, this has nothing to do with the bandwith issue. Even if I send > >re-INVITEs, which the other party understands, he can not tell me not to > >send any more re-INVITEs. > > > > >Otherwise your implementation may be viewed as favorably as the record > > >clubs that used to require you to send them a card every month telling > > >them not to send you anything by some groups. > > > >Well, it's not up to me to decide when and if an operator will use the > >session-timer, as defined in the draft, or not - I am just trying to > >make it as good (and less resource consuming) if he choses to. > > > >Regards, > > > >Christer Holmberg > >Ericsson Finland > > > > > > > > > > Brian Stucker > > > Nortel Networks > > > > > > -----Original Message----- > > > From: Culpepper, Bert [mailto:bert.culpepper@intervoice-brite.com] > > > Sent: Monday, October 16, 2000 3:38 PM > > > To: Christer Holmberg; sip@lists.bell-labs.com > > > Cc: Rohan Mahy > > > Subject: RE: [SIP] Session-timer with INFO > > > > > > Some things to think about. > > > > > > I believe INFO is _not_ to be used to modify the state of a session. > > > I > > > suppose a debate is possible about session-timer affecting session > > > state - present vs. future and if INFO is only restricted to one. But > > > it's > > > probably best to leave it alone. Also, the INV-200-ACK exchange > > > allows multiple parties to agree on the duration of the session. If > > > the > > > recipient of the INFO request wants a smaller value (because its > > > heartbeat interval is shorter) for the session timer it would have to > > > send its own INFO request (unless you plan to keep the proposed > > > Session-expires header and its use in a 200 OK). Now four > > > messages are needed. In addition, there may be proxy issues when > > > using INFO. There's other behavior described in the draft too. > > > > > > > -----Original Message----- > > > > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > > > > Sent: Monday, October 16, 2000 3:42 PM > > > > To: sip@lists.bell-labs.com > > > > Cc: Rohan Mahy > > > > Subject: Re: [SIP] Session-timer with INFO > > > > > > > > > > > > > > > > Hi, > > > > > > > > Thanks for the comments! > > > > > > > > >If the UA crashed and rebooted and forgot about the old session, it > > > > > > > would > > > > >respond with either a 481 call leg doesn't exist (you would know > > > the > > > > call > > > > >is down), or a 501 (you know the UA is up, but is the call?) > > > > > > > > > >thanks, > > > > >-rohan > > > > > > > > I think that would be good, because then we could inform the user > > > that > > > > the call doesn't exist anymore. > > > > > > > > Let's assume the UAS crashes, reboots and the UAC sends the > > > > session-timer re-INVITE. If the UAS has forgotten about the old > > > > session > > > > it would consider the re-INVITE as a new INVITE, for a new session. > > > It > > > > would try to establish a new session - and we could suddenly start > > > > receiving provisional 18x responses (with or without SDP bodies), > > > > and/or > > > > a 200 response with a SDP body, to the session-timer re-INVITE. What > > > > > > > do > > > > we do then? > > > > > > Well, you could ignore the provisional responses (you know the other > > > end > > > is confused) and let the session get re-established or decide to > > > terminate > > > the session with CANCEL/BYE. > > > > > > Regards, > > > Bert > > > > > > > > > > > Regards, > > > > > > > > Christer Holmberg > > > > Ericsson Finland > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > At 10:55 AM 10/16/00 , Christer Holmberg wrote: > > > > > > > > > > > >Hi, > > > > > > > > > > > >First, this mail is NOT a proposal for a change. I would just > > > like > > > > to > > > > > >hear some opinions - or maybe it has already been discussed on > > > the > > > > list? > > > > > > > > > > > >The INFO Method RFC says that for INFO requests without a message > > > > > > > body, > > > > > >a server supporting INFO MUST respond with response code 200. So, > > > > > > > my > > > > > >question is: why couldn't INFO be used for the session-timer > > > > > >functionality? Is the ACK the (re-)INVITE provides really > > > necessary > > > > for > > > > > >the purpose? > > > > > > > > > > > >And, like the session-timer is defined now, the other party would > > > > > > > not > > > > > >even have to support the INFO method, because a 501 Not > > > Implemented > > > > > >would be sent, and the sender of the INFO would know the session > > > is > > > > > >"alive". > > > > > > > > > > > >Just some thoughts... Please let me know if there is something I > > > > haven't > > > > > >taken into consideration. > > > > > > > > > > > >Regards, > > > > > > > > > > > >Christer Holmberg > > > > > >Ericsson Finland > > > > > > > > > > > > > > > > _______________________________________________ > > > SIP mailing list > > > SIP@lists.bell-labs.com > > > http://lists.bell-labs.com/mailman/listinfo/sip ------_=_NextPart_001_01C03A02.7FF7DD70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [SIP] Session-timer with INFO

Your correct, I can't stop the UAC from sending the = method again, but I'd like to plead to as many implementors as I can = that it would definitely be preferable in any setting if you wouldn't. = =3D)

Brian

-----Original Message-----
From: Christer Holmberg [mailto:christer.holmbe= rg@lmf.ericsson.se]
Sent: Tuesday, October 17, 2000 9:00 AM
To: sip@lists.bell-labs.com
Cc: hammer michael
Subject: Re: [SIP] Session-timer with INFO



Hi,

If I send you an INFO, or any other method that you = don't support, you
can for example send a 501 Not Implemented response, = and include an
Allow header with the methods you support. Of = course, you can't stop the
UAC of sending the method again, if he chooses = to...

You can not, however, tell an UAC not to send you = re-INVITEs, because
then you would also forbid the UAC to send you = INVITEs - and I don't
think you want to do that. Also, the specification = says that a UA MUST
be able to receive INVITEs (which included = re-INVITEs), so...

Regards,

Christer Holmberg
Ericsson Finland


hammer michael wrote:
>
> Is this the Internet version of "let them = eat cake?"  Signal-spam is not
> more palatable than the normal variety.
>
> Is there a response code that can indicate the = sentiment:  I don't support
> this method, don't try it again?  It might = also be good to make sure that
> such undesirable sub-methods are indicated as = "Unsupported."  If that
> sub-method is well-defined, then that header = parameter should be applicable.
>
> Mike
>
> At 12:30 AM 10/17/2000 +0300, Christer Holmberg = wrote:
>
> >Hi,
> >
> > >Good points. Here's one more problem = you may want to consider.
> > >Whenever you invoke a ping-style = method of deciding if a session is
> > >alive, you open up problems due to = network jitter and bandwidth. For
> > >instance, you could easily have a = packet delayed at an endpoint due to
> > >a large file transfer starting up, or = some other bandwidth consuming
> > >event. In this case, your ping could = be delayed long enough to cause
> > >the session to drop for no good = reason.
> >
> >Well, this could be the case no matter = which method (INVITE, INFO, or
> >whatever...) you use in the heartbeat = request...
> >
> > >You're also creating the potential for = artificial problems in wireless
> > >networks by using a ping-method to = keep a session alive. During a
> > >handover there may be a period where = packets are in effect "muted" for
> > >a short period of time. The mute = period may not, by itself be long
> > >enough to trigger a ping-timer to pop = and kill the session, but if the
> > >ping was near the edge of the time = envelope to be accepted as
> > >"on-time" anyhow, once = again, your session could very easily drop when
> > >the media was operating just = fine.
> > >Also, keep in mind, the longer you set = the ping timer for, the more
> > >network resources you will likely = waste over time because of the
> > >additional latentcy in discovering a = "dead" session.
> >
> >Just to clarify, this = "ping-method" IS already defined for SIP
> >(draft-ietf-sip-session-timer-02.txt), and = re-INVITEs are used to ping.
> >My idea was about replacing the re-INVITE = with INFO, which mean we would
> >actually save resources since we don't have = to send ACK every time.
> >
> > >This method has one other nasty = side-effect. You'd be wasting network
> > >resources on an event that will likely = not occur very often. After
> > >all, every INFO exchange except the = very last one that invalidates the
> > >session could have very well not been = sent without any negative impact
> > >on the session (otherwise they would = have been the last one). So
> > >you've got proxies and UAs, and other = transport resources being tied
> > >up processing packets that by and = large are providing no value, and
> > >they're chewing up bandwidth budget = that other services could be using
> > >instead.
> >
> >That is an interesting point, and it is = valid also for a number of other
> >SIP extensions where extra messages are = sent (e.g. PRACK), but it is
> >another discussion.
> >
> > >Please keep in mind that not everyone = is looking at implementing SIP
> > >on a 10Mbit+ hardwired LAN (or has to = scale up to tremendous numbers
> > >of users), pinging and = triangle-routing can be the death-knell of
> > >these sorts of networks.
> >
> >Who said "bandwidth is free"? = :)
> >
> > >Because of all of this, I think it = would be a very bad idea for a UA
> > >to send an INFO to a client who = repeatedly tells him "I don't
> > >understand INFO" to see if he's = alive.
> >
> >The number of messages on the network will = be the same no matter if we
> >send an INVITE which he understands, or an = INFO he may not understand.
> >Also, when we receive the response for the = INVITE we also have to send
> >back an ACK, which is not the case when = INFO is used.
> >
> > >He may not understand INFO because = that particular network doesn't
> > deem >the bandwidth required for this = mechanism as being best used for
> > that >purpose. If someone tells you = "don't send me this method" then
> > don't send >it to them.
> >
> >Again, this has nothing to do with the = bandwith issue. Even if I send
> >re-INVITEs, which the other party = understands, he can not tell me not to
> >send any more re-INVITEs.
> >
> > >Otherwise your implementation may be = viewed as favorably as the record
> > >clubs that used to require you to send = them a card every month telling
> > >them not to send you anything by some = groups.
> >
> >Well, it's not up to me to decide when and = if an operator will use the
> >session-timer, as defined in the draft, or = not - I am just trying to
> >make it as good (and less resource = consuming) if he choses to.
> >
> >Regards,
> >
> >Christer Holmberg
> >Ericsson Finland
> >
> >
> > >
> > > Brian Stucker
> > > Nortel Networks
> > >
> > > -----Original Message-----
> > > From: Culpepper, Bert [mailto:bert.culpeppe= r@intervoice-brite.com]
> > > Sent: Monday, October 16, 2000 3:38 = PM
> > > To: Christer Holmberg; = sip@lists.bell-labs.com
> > > Cc: Rohan Mahy
> > > Subject: RE: [SIP] Session-timer with = INFO
> > >
> > > Some things to think about.
> > >
> > > I believe INFO is _not_ to be used to = modify the state of a session.
> > > I
> > > suppose a debate is possible about = session-timer affecting session
> > > state - present vs. future and if = INFO is only restricted to one.  But
> > > it's
> > > probably best to leave it = alone.  Also, the INV-200-ACK exchange
> > > allows multiple parties to agree on = the duration of the session.  If
> > > the
> > > recipient of the INFO request wants a = smaller value (because its
> > > heartbeat interval is shorter) for = the session timer it would have to
> > > send its own INFO request (unless you = plan to keep the proposed
> > > Session-expires header and its use in = a 200 OK).  Now four
> > > messages are needed.  In = addition, there may be proxy issues when
> > > using INFO.  There's other = behavior described in the draft too.
> > >
> > > > -----Original = Message-----
> > > > From: Christer Holmberg [mailto:christer.holmbe= rg@lmf.ericsson.se]
> > > > Sent: Monday, October 16, 2000 = 3:42 PM
> > > > To: = sip@lists.bell-labs.com
> > > > Cc: Rohan Mahy
> > > > Subject: Re: [SIP] Session-timer = with INFO
> > > >
> > > >
> > > >
> > > > Hi,
> > > >
> > > > Thanks for the comments!
> > > >
> > > > >If the UA crashed and = rebooted and forgot about the old session, it
> > >
> > > > would
> > > > >respond with either a 481 = call leg doesn't exist (you would know
> > > the
> > > > call
> > > > >is down), or a 501 (you know = the UA is up, but is the call?)
> > > > >
> > > > >thanks,
> > > > >-rohan
> > > >
> > > > I think that would be good, = because then we could inform the user
> > > that
> > > > the call doesn't exist = anymore.
> > > >
> > > > Let's assume the UAS crashes, = reboots and the UAC sends the
> > > > session-timer re-INVITE. If the = UAS has forgotten about the old
> > > > session
> > > > it would consider the re-INVITE = as a new INVITE, for a new session.
> > > It
> > > > would try to establish a new = session - and we could suddenly start
> > > > receiving provisional 18x = responses (with or without SDP bodies),
> > > > and/or
> > > > a 200 response with a SDP body, = to the session-timer re-INVITE. What
> > >
> > > > do
> > > > we do then?
> > >
> > > Well, you could ignore the = provisional responses (you know the other
> > > end
> > > is confused) and let the session get = re-established or decide to
> > > terminate
> > > the session with CANCEL/BYE.
> > >
> > > Regards,
> > > Bert
> > >
> > > >
> > > > Regards,
> > > >
> > > > Christer Holmberg
> > > > Ericsson Finland
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > >
> > > > > At 10:55 AM 10/16/00 , = Christer Holmberg wrote:
> > > > > >
> > > > > >Hi,
> > > > > >
> > > > > >First, this mail is NOT = a proposal for a change. I would just
> > > like
> > > > to
> > > > > >hear some opinions - or = maybe it has already been discussed on
> > > the
> > > > list?
> > > > > >
> > > > > >The INFO Method RFC = says that for INFO requests without a message
> > >
> > > > body,
> > > > > >a server supporting = INFO MUST respond with response code 200. So,
> > >
> > > > my
> > > > > >question is: why = couldn't INFO be used for the session-timer
> > > > > >functionality? Is the = ACK the (re-)INVITE provides really
> > > necessary
> > > > for
> > > > > >the purpose?
> > > > > >
> > > > > >And, like the = session-timer is defined now, the other party would
> > >
> > > > not
> > > > > >even have to support = the INFO method, because a 501 Not
> > > Implemented
> > > > > >would be sent, and the = sender of the INFO would know the session
> > > is
> > > > > = >"alive".
> > > > > >
> > > > > >Just some thoughts... = Please let me know if there is something I
> > > > haven't
> > > > > >taken into = consideration.
> > > > > >
> > > > > >Regards,
> > > > > >
> > > > > >Christer = Holmberg
> > > > > >Ericsson Finland
> > > > > >
> > > >
> > >
> > > = _______________________________________________
> > > SIP mailing list
> > > SIP@lists.bell-labs.com
> > > http://lists.bell-labs.com/mailman/listinfo/sip

------_=_NextPart_001_01C03A02.7FF7DD70-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Oct 19 15:51:08 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA28979 for ; Thu, 19 Oct 2000 15:51:06 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 63E1544340; Thu, 19 Oct 2000 14:51:08 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from hvmta02-stg.us.psimail.psi.net (hvmta02-ext.us.psimail.psi.net [38.202.36.30]) by lists.bell-labs.com (Postfix) with ESMTP id 052DD44336 for ; Thu, 19 Oct 2000 14:50:39 -0400 (EDT) Received: from softwareo ([38.150.216.6]) by hvmta02-stg.us.psimail.psi.net (InterMail v4.01.01.00 201-229-111) with SMTP id <20001019195032.BSUK26052.hvmta02-stg@softwareo>; Thu, 19 Oct 2000 15:50:32 -0400 Reply-To: From: "Orit Levin" To: "Chris Harris" Cc: , , Subject: RE: [SIPFORUM] Re: [SIP] JAIN SIP Specification Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0039_01C039E4.4B82BD80" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <39EF3ED3.9DA6E3DE@dynamicsoft.com> Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 19 Oct 2000 15:50:24 -0400 This is a multi-part message in MIME format. ------=_NextPart_000_0039_01C039E4.4B82BD80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Hi Chris! Conceptually we definitely agree here. Which is great :-) I am not sure either the “proposed wording” completely grasps the whole concept. There are still a number of “subtle” technical issues here, that, I believe, the SPEC should explicitly specify. It has to be explained how - the Provider has the control of the Transaction State machine - the Application has the whole freedom to look and edit all the messages fields And all this without - putting a huge overhead on the Provider’s “consistency checking” logic - and still providing means for keeping the Transaction State in both the Provider and the Application in complete synch! Some compromises have obviously be defined and agreed upon. The next week is going to be interesting, for sure! Regards, Orit Levin RADVision Inc. TEL: 201.529.4300 x 230 FAX:201.529.3516 mailto:orit@radvision.com http://www.radvision.com 575 Corporate Drive Suite 420 Mahwah, NJ 07430 -----Original Message----- From: sip-admin@lists.bell-labs.com [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Chris Harris Sent: Thursday, October 19, 2000 2:35 PM Cc: sip@lists.bell-labs.com; discussion@sipforum.org; jainsip@Sun.COM Subject: Re: [SIPFORUM] Re: [SIP] JAIN SIP Specification Hi Orit, Yes, there is plenty to discuss at next week's meeting :) I totally agree that the Provider should be the master of transaction state - (by "master" I assume you mean who has absolute control). In fact I think the Provider should be the Master of everything it exports through the API. I believe this is the case in API as it stands... For example, an application invokes a send method on the Provider, which the Provider can reject. You could say the application is only making a request of the Provider, and the result of this request is given by a thrown exception or a returned transaction id. A similar situation exists for cancelling a transaction. Doesn't this fulfil the role of master you mention? Chris Orit Levin wrote: Hello! I am sure we are going to have this discussion during the JAIN meeting next week. But it is hard from not intervening here. The great benefit of SIP (compared to other competing technologies :-)) is the abstraction it defines, starting from the low protocol’s level. The lowest one is the “messages”. The next one is the “transaction”. The next one is the “call (leg)”. In our case, we are talking about the keeper of the “Transactions State machine”. This point is obvious. Based on the discussions here, yet another point is less obvious. In order to define an efficient and interoperable API, there should be (in my opinion, MUST) one single MASTER of the “Transactions State machine”. The API itself should be driven by this main architectural decision. It doesn’t preclude from “exporting” by this Master both the “transaction states” and “the SIP messages”. It does not preclude from providing by this Master “modification tools” for both transaction state machine and the SIP messages. My point is, that depending on this FIRST decision, the semantic of the “SIP messages API” part would be very different, even if its syntax may look alike!!! Therefore, before diving into the API details, SPEC should define the chosen model, clearly specifying the real “state machine” MASTER for each abstraction level. This is the only way to define an interoperable API. BTW, my technical opinion is to use the SIP design advantage at its best and to define the Provider, to be the MASTER for the transaction state machine. Best Regards, Orit Levin RADVision Inc. TEL: 201.529.4300 x 230 FAX:201.529.3516 mailto:orit@radvision.com http://www.radvision.com 575 Corporate Drive Suite 420 Mahwah, NJ 07430 -----Original Message----- From: sip-admin@lists.bell-labs.com [ mailto:sip-admin@lists.bell-labs.com]On Behalf Of Chris Harris Sent: Thursday, October 19, 2000 9:30 AM To: Itamar Gilad Cc: sip@lists.bell-labs.com; discussion@sipforum.org; jainsip@Sun.COM Subject: Re: [SIPFORUM] Re: [SIP] JAIN SIP Specification Hi Itamar, Sure - after all an application can completely ignore the transaction ids given to it by the Provider, and use the send methods that don't take transaction id parameters - the Provider has to cover both types of application. Note that I don't necessarily think an application can't have an object to represent a transaction, just that such an object must operate through the Provider - since the Provider is supposed to be the applications only access to the SIP stack. So you could have a client transaction object containing the request sent returned by the Provider, and have a cancel method on it - that calls the sendCancel method on the Provider etc... But I'm not sure how useful this would be - you are also forcing an application that is not interested in transactions to extract messages from transaction objects. Then again, we could always define two JainSipListener subtypes - JainSipMessageListener and JainSipTransactionListener...this might be a good idea - then we can have an application indicate to the Provider whether it is interested in transactions - if it isn't it just receives Message objects, and if it is it receives Transaction objects (incorporating the associated Messages) The Transaction objects contain a transaction id, and can by ClientTransaction or ServerTransaction, and their methods can call the Provider's methods with the transaction id parameters. Opinions? I think incorporating call-legs and calls into the API is asking too much of an API that deals with messages and transactions - unless we create a JainSipCall(Leg)Listener...but now we're mandating that the inderlying implementation has to keep call state...and above we have to map JCC onto these...that could get very messy! Chris Itamar Gilad wrote: Hi Chris,It could be argued that it makes just as much sense for the Provider to identify also the Call-Leg and Call. Still I think I understand what you are after and I agree that this might help applications that for some reason want to know about transaction 'ids', but don't want to work with transaction objects. Regards Itamar -----Original Message----- From: Chris Harris [ mailto:charris@dynamicsoft.com] Sent: Thu, October 19, 2000 12:11 PM To: sip@lists.bell-labs.com Cc: discussion@sipforum.org; jainsip@Sun.COM Subject: Re: [SIPFORUM] Re: [SIP] JAIN SIP Specification Hi Itamar, I can't really think of any applications other than a stateless proxy that don't care about transactions. And since stateless proxies are really just SIP routers and need maximum performance, I can't really see anyone implementing them with JAIN SIP. I think any application that does anything interesting needs to know about transactions, so the the JAIN SIP API should include some means of identifying transactions or transaction control. But this has to fit in with the Listener/Provider event model, so we can't hand a Listener a transaction object that they can work with directly - we need to give an application access to transactions through the Provider. I thought a transaction id would be the simplest way to achieve this. Do you have any suggestions for improving transaction control for the event model? Chris Itamar Gilad wrote: No, that's not it. The application uses a stack to do all of this. The stack should export a message-related API like the one defined in the JAIN SIP specification you presented. The stack should also export interfaces for Call control and Transaction control. It seems more logical for the application to use a transaction object which handles messaging and notifies it whenever a message belonging to this transaction is received rather then having a message object that tells it which transaction it belongs too. Stateless proxies for example would use only the message layer and they don't care at all about transactions. I'm Sorry to be so picky, but I just think that this makes for a cleaner design both in the application and in the stack. Our experience with our SIP stack proves that this model works fine.Itamar -----Original Message----- From: Chris Harris [ mailto:charris@dynamicsoft.com] Sent: Wed, October 18, 2000 8:18 PM To: discussion@sipforum.org Cc: Itamar Gilad; 'Bobby Sardana'; mranga@nist.gov; sip@lists.bell-labs.com; jainsip@Sun.COM Subject: Re: [SIPFORUM] Re: [SIP] JAIN SIP Specification OK - so if an application just sends a message to the Provider, it has to check all response messages to see if they match - this is so messy for an application. What if a response message never arrives - how should the Provider inform the application of a timeout? Call a timeout method and pass the request message back? Itamar Gilad wrote: Chris,I agree that few SIP applications would like to bother with transaction mapping. This is clearly the responsibility of the stack as is transaction management in general. However in a previous thread you explained that the issue of managing call and transaction state is outside the scope of this API specification, which led me to believe that the goal is to define message-related functionality. I think that injecting transaction keys into the mix is crossing the lines you defined.Regards, Itamar -----Original Message----- From: Chris Harris [ mailto:charris@dynamicsoft.com] Sent: Wed, October 18, 2000 7:44 PM To: Itamar Gilad Cc: 'Bobby Sardana'; discussion@sipforum.org; mranga@nist.gov; sip@lists.bell-labs.com; jainsip@Sun.COM Subject: Re: [SIPFORUM] Re: [SIP] JAIN SIP Specification Itamar, It is for the very reason that identifying a transaction from a message is not a trivial matter that I wanted to put the transaction handling inside the JainSipProvider. I don't think the spec should just deal with just the message layer. How many people are going to write JAIN SIP applications if they have to implement their own transaction keys? I'd imagine very few. Regards, Chris Itamar Gilad wrote: Hi again Chris,I'd like to re-emphasize what Bobby says below. The JAIN SIP specification presented here seems to deal just with the "message layer" i.e. parsing, encoding, message and message part containers. I'd like to join those who commend the fine and comprehensive work done. However, this layer has nothing to do with transactions and their state. It would be a mistake to rely on it to retain 'transaction-ids' and associate messages to them (please correct me if I'm misinterpreting your meaning). Note that identifying a transaction from a message is not a trivial matter and continuously more message fields are added to the "transaction key" in order to deal with spiraling, merging etc. A more straight-forward approach would be to put this functionality in the "transaction layer" where transaction objects live and make a clean separation between the two layers.Regards Itamar -----Original Message----- From: Bobby Sardana [ mailto:bobby.sardana@mobilerain.com] Sent: Wed, October 18, 2000 6:39 PM To: discussion@sipforum.org Cc: mranga@nist.gov; sip@lists.bell-labs.com; jainsip@sun.com Subject: Re: [SIPFORUM] Re: [SIP] JAIN SIP Specification Greetings Chris: Just to add a pointer to this thread: Maintaining trasaction state is an application level functionality and *shouldn't* be implemented in the base stack. For applications like state oriented proxy server, the JAIN SIP can provide enough hooks for event delivery but the state has to be maintained by the proxy server. Pleas keep up the good work. It is really appreciated. Regards, Bobby.Sardana@mobilerain.com Chris Harris wrote: "M. Ranganathan" wrote: Hi Chris, Thanks for replying so promptly (I am sure you are flooded with email ). I get one or two :) As you pointed out, I suppose we cannot do away with making Messages into classes because of the tie-in with java events (unfortunately) but I still like the notion of being able to specify interfaces where ever possible. I see where you're coming from alright, and I suppose changing header classes into interfaces, could fit in with Gethin's proposal nicely? I dont quite follow the motivation behind the following design decision (excerpted from your reply): Maybe I've misunderstood what you're saying - but a JAIN SIP implementation is only stateless when it comes to call state. The JainSipProvider implementation must maintain transaction state - it simply exposes a reference to a transaction via the transaction id for the convenience of the JainSipListener. The service does not have total control over transacton state - the stack implementation does. It appears that I have indded mis-understood the architecture. Why should the above be so? Can one not rely on the JainSipListener to keep transaction state also, thereby making the stack simply a way of recognising messages and triggering event handlers on the basis of message type. This would (IMHO) be a cleaner model yet. That way, we can do away with transaction identifiers being passed back and forth and keep all of this information in the handler. ( You may have to extend the architecture somewhat to deal with timeouts and failures so that the handler knows about transaction failure.) In any case, if this is not a viable idea, I would be grateful if you can explain why not (or point me to the portion of the spec that explains why not) so I can get a better understanding. It would be cleaner model, and personally I am in total agreement with you - but it means the application is forced to maintain transaction state, match up headers - which has been said places too much of a burden on applications. How about finding a way to let the application choose whether or not it wants to keep transaction state? Regards, Ranga. Chris Harris wrote: > Hi Ranga, > > Response below... > > Chris > > "M. Ranganathan" wrote: > >> JAIN-SIP is a groovy idea. Hats off to the whole concept and many >> thanks to Chris and >> the JAIN-SIP team for putting together a spec and more flower power >> to them :-) . In >> particular I like the notion of treating UAS, Redirect and Proxy >> servers as merely >> special cases of the general notion of Services and the idea of >> unifying these >> notions with an event mechanism and event handlers. Second, I like >> the idea of >> separation between a stateless event -oriented "stack" and a bunch >> of event >> handlers that are triggered by the stack with all state (including >> transaction >> state) being separated from the event stack via the JAIN-SIP mapping >> layer if you >> will. ( Correct me if I wax poetic but have the wrong >> understanding....) > >> >> >> I hope I will not be viewed as being too critical, but I would >> like to go one step >> further than what Gethin is suggesting. I am all for using >> interfaces as much as >> possible and leaving class hierarchy definitions to implemeters. >> Defining class >> hierarchies almost lays out an implementation and involves >> considerable rework for >> those who have a working java-based stack, but have not used the >> same classes. OK it >> is just a matter of labor to map things to the JAIN-SIP class >> hierarchy but it IS a >> dis-incentive. >> >> 1. Lets use interfaces for all messages rather than actually define >> class >> hierarchies ( yes Chris has pointed out the historical precedent >> behind actually >> defining class hierarchies for messages. IMHO, there has to be a >> more compelling >> reason than that.) > > I suppose all classes could be turned into interfaces, except for the > Message classes which must extend java.util.EventObject to fit into > the JAIN framework. > >> >> >> 2. The tie-in with the JAVA event mechanism has necessitated the >> explicit definition >> of class hierarchies in certain places. Why not use callbacks >> instead and do away >> with this dependency as well? (Basically the same thing as events >> but does not tie >> into the JAVA event mechanism and its associated limitations.) > > Unfortunately the JAIN framework expilicitly relies on the Java Event > model, and I don't think callbacks would be accepted within the JAIN > community. > >> >> >> Nice work and keep it rolling! Thanks. > > Couldn't do it without you guys - thank you! > >> >> >> Ranga. >> >> Gethin Liddell wrote: >> >> > All, >> > >> > This idea of abstraction of the JAIN API is certainly a valid and >> > interesting idea. However, i'm a bit concerened that the proposed >> >> > solution of many different packages, will only seek to complicate >> and >> > maybe enlarge the API. >> > >> > I too see no reason why there is an EntityHeader etc... and i also >> do >> > not see any requirement for an InviteMessage, AckMessage etc... >> > >> > How about if the format of the API remains as is: >> > >> > jain.protocol.ip.sip >> > jain.protocol.ip.sip.header >> > jain.protocol.ip.sip.message >> > >> > except that the messages available in the message package >> consisted of >> > BasicRequest/Response, MinimalRequest/Response etc... where each >> > message is extened in turn (e.g. Minimal extends Basic, Moderate >> > extends Minimal etc...), of course as Chris points out it is not >> hard >> > to see that a combination would be required that is not provided. >> So >> > in the interest of flexibility, it could be possible for the user >> to >> > plug-in to the message class what extra headers it requires. The >> only >> > issue then is that the user will have to use a "public Header >> > getHeader(String headerName)" and then cast the header to their >> desired >> > header type. Either that or create their own Message class >> > (extending the current ones) that simply does the casting >> automatically >> > for them. Then after compiling, run an obfuscator on the code and >> it >> > will automatically extract and only extract the Message, Headers >> and >> > even methods that are used. >> > >> > This then will also cut down on the number of methods in the >> Provider >> > as there will be no need for the sendAck(AckMessage), >> > sendInvite(InviteMessage) etc.. as they would be replaced by the >> > single method sendRequest(RequestMessage). >> > >> > I personally see three arguments for keeping the JAIN SIP stack as >> small >> > as possible: >> > >> > 1) The first is for embedded applications where stack size has to >> be >> > kept to a minimum as memory is at a premium. So if just using the >> >> > Basic message suffices then this will compile and run with a small >> >> > number of classes present from the stack. Don't forget, >> obfuscation >> > will help in extracting only the Messages, Headers and even >> methods >> > required from a jar file but it won't do everything. >> > >> > 2) The second is that users may be put off or confused by the >> sheer >> > size and complexity of the JAIN stack. So if only using the >> > BasicMessage gets them on the first rung of the ladder then it is >> a >> > good starting point and allows them to build up to bigger and >> better >> > things. >> > >> > 3) We also have to consider who is going to implement the JAIN SIP >> >> > stack. If it is indeed overly complicated then no-one or a single >> > vendor may end up implmenting the stack and thus its definition >> and >> > all the hard work that has gone into it is useless. >> > >> > On Mon, 16 Oct 2000, Chris Harris wrote: >> > > Itamar, >> > > >> > > The idea of levelling the API based on what messages, headers >> and response codes >> > > are understood is certainly an interesting one - minimal, basic, >> redirection, >> > > firewall-friendly, negotiation, authentication and "full". >> > > >> > > jain.protocol.ip.sip >> > > jain.protocol.ip.sip.header >> > > jain.protocol.ip.sip.message >> > > >> > > could then become... >> > > >> > > jain.protocol.ip.sip - listener, provider, stack, general >> classes used at all >> > > levels >> > > jain.protocol.ip.sip.header - contains base Header class (and >> requestHeader, >> > > ResponseHeader, EntityHeader, GeneralHeader) >> > > jain.protocol.ip.sip.message - contains base Message class >> > > >> > > jain.protocol.ip.sip.minimal - general classes used only at this >> level and above >> > > >> > > jain.protocol.ip.sip.minimal.header - headers used only at this >> level and above >> > > jain.protocol.ip.sip.minimal.message - messages only used at >> this level and >> > > above >> > > >> > > jain.protocol.ip.sip.basic - general classes used only at this >> level and above >> > > jain.protocol.ip.sip.basic.header - headers used only at this >> level and above >> > > jain.protocol.ip.sip.basic.message - messages used only at this >> level and above >> > > ... >> > > .... >> > > jjain.protocol.ip.sip."full" - general classes only used at this >> level >> > > jain.protocol.ip.sip."full".header - headers used only at this >> level >> > > jain.protocol.ip.sip."full".message - messages used only at this >> level >> > > >> > > The API user could then pick the packages they need - say they >> initially only >> > > want the minimal features, but then realise they need to use >> their application >> > > behind a firewall - then they can simply add the >> firewall-friendly package. The >> > > RFC says "In general, each capability listed builds on the ones >> above it" but it >> > > is not hard to see that firewall-friendly and authentication may >> be desired >> > > without redirection for example. >> > > >> > > Is this what you hand in mind Itamar? >> > >> > -- >> > Gethin Liddell >> > Ubiquity Software Corporation >> > >> > http://www.ubiquity.net >> > mailto:gethin@ubiquity.net >> > >> > _______________________________________________ >> > SIP mailing list >> > SIP@lists.bell-labs.com >> > http://lists.bell-labs.com/mailman/listinfo/sip >> >> -- >> M.Ranganathan >> NIST Advanced Networking Technologies Group, >> 100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899. >> Tel: 301 975 3664 Fax: 301 590 0932 >> >> Hfæj)b? b²Ô^>X¬¶ÆÞ-YZnÇ(sm§ÿåSËlmée*¦ìr?¿?¨¥?©ÿ-+-SwèþÈ© > -- M.Ranganathan NIST Advanced Networking Technologies Group, 100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899. Tel: 301 975 3664 Fax: 301 590 0932 Hfæj)b? b²Ô^>X¬¶ÆÞ-YZnÇ(sm§ÿåSËlmée*¦ìr?¿?¨¥?©ÿ-+-SwèþÈ© ------=_NextPart_000_0039_01C039E4.4B82BD80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Chris!

Conceptually we definitely agree here. Which is great = J

I am not sure either the “proposed wording” = completely grasps the whole concept.

There are still a number of “subtle” technical issues = here, that, I believe, the SPEC should explicitly specify.

It has to be explained how

-           = ;           the Provider has the control of the = Transaction State machine

-           = ;           the Application has the whole freedom to look = and edit all the messages fields

And all this without

-           = ;           putting a huge overhead on the = Provider’s “consistency checking” logic

-           = ;           and still providing means for keeping the = Transaction State in both the Provider and the Application in complete = synch!

Some compromises have obviously be defined and agreed = upon.

 

The next week is going to be interesting, for = sure!

Regards,

Orit = Levin

RADVision = Inc.

TEL: 201.529.4300 x = 230

FAX:201.529.3516

mailto:orit@radvision.com=

http://www.radvision.com =

575 Corporate Drive Suite 420 = Mahwah, NJ 07430

<= span class=3DEmailStyle20> 

-----Original Message-----
From: sip-admin@lists.bell-labs.com = [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Chris Harris
Sent: Thursday, October = 19, 2000 2:35 PM
Cc: = sip@lists.bell-labs.com; discussion@sipforum.org; jainsip@Sun.COM
Subject: Re: [SIPFORUM] = Re: [SIP] JAIN SIP Specification

 

Hi = Orit, <= /p>

Yes, there is plenty to discuss = at next week's meeting :)

I totally agree that the Provider = should be the master of transaction state - (by "master" I assume you = mean who has absolute control). In fact I think the Provider should be the = Master of everything it exports through the API. I believe this is the case in API = as it stands...

For example, an application = invokes a send method on the Provider, which the Provider can reject. You could say the = application is only making a request of the Provider, and the result of this request = is given by a thrown exception or a returned transaction id. A similar = situation exists for cancelling a transaction. <= /p>

Doesn't this fulfil the role of = master you mention?

Chris
 

Orit Levin wrote: = <= /p>

Hello!<= /p>

I am sure we are going to have this discussion = during the JAIN meeting next week. But it is hard from not intervening = here. <= /p>

The great benefit of SIP (compared to other = competing technologies J<= /span>) is the abstraction = it defines, starting from the low protocol’s level. The lowest one is = the “messages”. The next one is the “transaction”. = The next one is the “call (leg)”. 

In our case, we are talking about the keeper = of the “Transactions State machine”. This point is = obvious. <= /p>

Based on the discussions here, yet another = point is less obvious. In order to define an efficient and interoperable API, = there should be (in my opinion, MUST) one single MASTER of the = “Transactions State machine”. The API itself should be driven by this main = architectural decision. It doesn’t preclude from “exporting” by this Master = both the “transaction states” and “the SIP messages”. It does not preclude = from providing by this Master “modification tools” for both transaction state = machine and the SIP messages.

My point is, that depending on this FIRST decision, the semantic of the = “SIP messages API” part would be very different, even = if its syntax may look alike!!! <= /p>

Therefore, before diving into the API details, = SPEC should define the chosen model, clearly specifying the real “state = machine” MASTER for each abstraction level. This is the only way to define an interoperable API.

BTW, my technical opinion is to use the SIP = design advantage at its best and to define the Provider, to be the MASTER for = the transaction state machine.

Best = Regards, <= /p>

Orit = Levin <= /p>

RADVision = Inc. <= /p>

TEL: 201.529.4300 x 230

FAX:201.529.3516 <= /p>

mailto:orit@radvision.com <= /p>

http://www.radvision.com  <= /p>

575 = Corporate Drive Suite 420 Mahwah, NJ 07430

 <= /p>

-----Original Message-----
From: sip-admin@lists.bell-labs.com [mailto:sip-admin@lists.bell= -labs.com]On Behalf Of Chris = Harris
Sent: Thursday, October 19, 2000 9:30 AM
To:<= /b> Itamar Gilad
Cc:<= /b> sip@lists.bell-labs.com; discussion@sipforum.org; = jainsip@Sun.COM
Subject: Re: [SIPFORUM] Re: [SIP] JAIN SIP = Specification <= /p>

Hi Itamar,  <= /p>

Sure - after all an application can completely ignore the transaction ids given to it = by the Provider, and use the send methods that don't take transaction id = parameters - the Provider has to cover both types of application.  = <= /p>

Note that I don't necessarily think an application can't have an object to represent = a transaction, just that such an object must operate through the Provider = - since the Provider is supposed to be the applications only access to the SIP = stack. So you could have a client transaction object containing the request = sent returned by the Provider, and have a cancel method on it - that calls = the sendCancel method on the Provider etc... But I'm not sure how useful = this would be - you are also forcing an application that is not interested in = transactions to extract messages from transaction objects.  = <= /p>

Then again, we could always define two JainSipListener subtypes - = JainSipMessageListener and JainSipTransactionListener...this might be a good idea - then we can = have an application indicate to the Provider whether it is interested in transactions - if it isn't it just receives Message objects, and if it = is it receives Transaction objects (incorporating the associated Messages) The Transaction objects contain a transaction id, and can by = ClientTransaction or ServerTransaction, and their methods can call the Provider's methods = with the transaction id parameters. Opinions?  = <= /p>

I = think incorporating call-legs and calls into the API is asking too much of an = API that deals with messages and transactions - unless we create a JainSipCall(Leg)Listener...but now we're mandating that the inderlying implementation has to keep call state...and above we have to map JCC = onto these...that could get very messy!  = <= /p>

Chris  <= /p>

Itamar Gilad wrote:  <= /p>

Hi Chris,It could be argued that it makes just as much sense for the = Provider to identify also the Call-Leg and Call. Still I think I understand what you = are after and I agree that this might help applications that for some reason = want to know about transaction 'ids', but don't want to work with transaction objects. Regards   = Itamar  <= /p>

-----Original Message-----

Hi Itamar,  <= /p>

I can't really think of any applications other than a stateless proxy that = don't care about transactions. And since stateless proxies are really just SIP routers and need maximum performance, I can't really see anyone = implementing them with JAIN SIP.  <= /p>

I think any application that does anything interesting needs to know about transactions, so the the JAIN SIP API should include some means of = identifying transactions or transaction control. But this has to fit in with the Listener/Provider event model, so we can't hand a Listener a transaction = object that they can work with directly - we need to give an application access = to transactions through the Provider. I thought a transaction id would be = the simplest way to achieve this. Do you have any suggestions for improving transaction control for the event model?  = <= /p>

Chris <= /p>

Itamar Gilad wrote: <= /p>

No, that's not it.  The application uses a stack to do = all of this.  The stack should export a message-related API like the one = defined in the JAIN SIP specification you presented.  The stack should also = export interfaces for Call control and Transaction control.  It seems more logical for the application to use a transaction object which handles = messaging and notifies it whenever a message belonging to this transaction is = received rather then having a message object that tells it which transaction it = belongs too.  Stateless proxies for example would use only the message = layer and they don't care at all about transactions. I'm Sorry to be so picky, but = I just think that this makes for a cleaner design both in the application and = in the stack.  Our experience with our SIP stack proves that this model = works fine.Itamar

-----Original Message-----

OK - so if an application just sends a message to the Provider, it has to = check all response messages to see if they match - this is so messy for an application. What if a response message never arrives - how should the = Provider inform the application of a timeout? Call a timeout method and pass the = request message back?  <= /p>

Itamar Gilad wrote: <= /p>

Chris,I agree that few = SIP applications would like to bother with transaction mapping.  This = is clearly the responsibility of the stack as is transaction management in general. However in a previous thread you explained that the issue of = managing call and transaction state is outside the scope of this API = specification, which led me to believe that the goal is to define message-related functionality. I think that injecting transaction keys into the mix is = crossing the lines you defined.Regards,  = Itamar<= /p>

-----Original Message-----

Itamar, <= /p>

It is for the very reason that identifying a transaction from a message is = not a trivial matter that I wanted to put the transaction handling inside the JainSipProvider. I don't think the spec should just deal with just the = message layer. How many people are going to write JAIN SIP applications if they = have to implement their own transaction keys? I'd imagine very = few.  <= /p>

Regards,
Chris  <= /p>

Itamar Gilad wrote: <= /p>

Hi again Chris,I'd like to re-emphasize what Bobby says below.  The JAIN SIP specification presented here seems to deal = just with the "message layer" i.e. parsing, encoding, message and = message part containers.  I'd like to join those who commend the fine and = comprehensive work done.  However, this layer has nothing to do with transactions = and their state.  It would be a mistake to rely on it to retain 'transaction-ids' and associate messages to them (please correct me if = I'm misinterpreting your meaning). Note that identifying a transaction from = a message is not a trivial matter and continuously more message fields are = added to the "transaction key" in order to deal with spiraling, = merging etc. A more straight-forward approach would be to put this functionality = in the "transaction layer" where transaction objects live and make a = clean separation between the two layers.Regards Itamar


-----Original = Message-----
From: Bobby Sardana [mailto:bobby.sardana@mobiler= ain.com]
Sent: Wed, October 18, 2000 6:39 PM
To:<= /b> discussion@sipforum.org
Cc:<= /b> mranga@nist.gov; sip@lists.bell-labs.com; = jainsip@sun.com
Subject: Re: [SIPFORUM] Re: [SIP] JAIN SIP = Specification

Greetings Chris: <= /p>

Just to add a pointer to this thread:  <= /p>

Maintaining trasaction state is an application level functionality and *shouldn't* = be implemented in the base stack. For applications like state oriented = proxy server, the JAIN SIP can provide enough hooks for event delivery but the = state has to be maintained by the proxy server.  = <= /p>

Pleas keep up the good work. It is really appreciated.  = <= /p>

Regards, <= /p>

Bobby.Sardana@mobilerain.com= <= /p>

Chris Harris wrote: <= /p>

"M. Ranganathan" wrote: <= /p>

Hi Chris, <= /p>

Thanks for replying so promptly (I am sure you are flooded with email = ).<= /p>

I get one or two :)<= /p>


As you pointed out, I suppose we cannot do away with making Messages =
into classes because of the tie-in with java events (unfortunately) but =
I still like the notion of being able to specify  interfaces where = ever
possible.

I see where you're coming from alright, and I suppose changing header classes = into interfaces, could fit in with Gethin's proposal = nicely?<= /p>


 I dont quite follow  the motivation behind the following = design
decision (excerpted from your reply):  = <= /p>

Maybe I've misunderstood what you're saying - but a JAIN SIP
implementation is only stateless when it comes to call state. The
JainSipProvider implementation must maintain transaction state - it
simply exposes a reference to a transaction via the transaction id for =
the convenience of the JainSipListener. The service does not have total =
control over transacton state - the stack implementation = does.  <= /p>

It appears that I have indded mis-understood the architecture.  Why =
should the above be so? Can one not rely on the JainSipListener to keep =
transaction state also, thereby making the stack simply a way of
recognising messages and triggering  event handlers on the basis of =
message type. This would (IMHO) be a cleaner model = yet.    That way,  we
can do away with transaction identifiers being passed back and forth and =
keep all of this information in the handler.  ( You may have to = extend
the architecture somewhat to deal with timeouts and failures so that the =
handler knows about transaction failure.) In any case, if this is not a =
viable idea, I would be grateful if you can explain why not (or point me =
to the portion of the spec that explains why not) so I can get a better =
understanding.<= /p>

It would be cleaner model, and personally I am in total agreement with you = - but it means the application is forced to maintain transaction state, match = up headers - which has been said places too much of a burden on = applications. How about finding a way to let the application choose whether or not it = wants to keep transaction state?<= /p>

Regards,= <= /p>

Ranga. <= /p>

Chris Harris wrote:  <= /p>

> Hi Ranga,
>
> Response below...
>
> Chris
>
> "M. Ranganathan" wrote:
>
>> JAIN-SIP is a groovy idea. Hats off to the whole concept and = many
>> thanks to Chris and
>> the JAIN-SIP team for putting together a spec and more flower = power
>> to them :-) .  In
>> particular I like the notion of treating UAS,  Redirect = and Proxy
>> servers as merely
>> special cases of the general notion of Services and  the = idea of
>> unifying these
>> notions with an event mechanism and  event handlers.  Second, I like
>> the idea of
>> separation between a  stateless  event -oriented "stack" and a bunch
>> of event
>> handlers that are triggered by the stack with all state = (including
>> transaction
>> state) being separated from the event stack via the JAIN-SIP = mapping
>> layer if you
>> will.  ( Correct me if I  wax poetic but have the = wrong
>> understanding....)
>
>>
>>
>> I hope I  will not be viewed as being too critical,  = but I would
>> like to go  one step
>> further than what Gethin is suggesting.   I am all = for using
>> interfaces as much as
>> possible and leaving class hierarchy definitions to = implemeters.
>> Defining class
>> hierarchies almost lays out an implementation and involves
>> considerable rework for
>> those who have a working java-based stack, but have not used = the
>> same classes. OK it
>> is just a matter of labor to map things to the JAIN-SIP class =
>> hierarchy but it  IS a
>> dis-incentive.
>>
>> 1. Lets use interfaces for all messages rather than actually = define
>> class
>> hierarchies  ( yes Chris has pointed out the historical = precedent
>> behind actually
>> defining class hierarchies for messages. IMHO,  there has = to be a
>> more compelling
>> reason than that.)
>
> I suppose all classes could be turned into interfaces, except for = the
> Message classes which must extend java.util.EventObject to fit into =
> the JAIN framework.
>
>>
>>
>> 2. The tie-in with the JAVA event mechanism has necessitated = the
>> explicit definition
>> of class hierarchies in certain places.  Why not use = callbacks
>> instead and do away
>> with this dependency as well?  (Basically the same thing = as events
>> but does not tie
>> into the JAVA event mechanism and its associated limitations.) =
>
> Unfortunately the JAIN framework expilicitly relies on the Java = Event
> model, and I don't think callbacks would be accepted within the = JAIN
> community.
>
>>
>>
>> Nice work and keep it rolling!  Thanks.
>
> Couldn't do it without you guys - thank you!
>
>>
>>
>> Ranga.
>>
>> Gethin Liddell wrote:
>>
>> > All,
>> >
>> > This idea of abstraction of the JAIN API is certainly a = valid and
>> > interesting idea.  However, i'm a bit concerened that = the proposed
>>
>> > solution of many different packages, will only seek to = complicate
>> and
>> > maybe enlarge the API.
>> >
>> > I too see no reason why there is an EntityHeader etc... = and i also
>> do
>> > not see any requirement for an InviteMessage, AckMessage = etc...
>> >
>> > How about if the format of the API remains as is:
>> >
>> > jain.protocol.ip.sip
>> > jain.protocol.ip.sip.header
>> > jain.protocol.ip.sip.message
>> >
>> > except that the messages available in the message package =
>> consisted of
>> > BasicRequest/Response, MinimalRequest/Response etc... = where each
>> > message is extened in turn (e.g. Minimal extends Basic, = Moderate
>> > extends Minimal etc...), of course as Chris points out it = is not
>> hard
>> > to see that a combination would be required that is not = provided.
>> So
>> > in the interest of flexibility, it could be possible for = the user
>> to
>> > plug-in to the message class what extra headers it requires.  The
>> only
>> > issue then is that the user will have to use a = "public Header
>> > getHeader(String headerName)" and then cast the = header to their
>> desired
>> > header type. Either that or create their own Message class =
>> > (extending the current ones) that simply does the casting =
>> automatically
>> > for them.  Then after compiling, run an obfuscator on = the code and
>> it
>> > will automatically extract and only extract the Message, = Headers
>> and
>> > even methods that are used.
>> >
>> > This then will also cut down on the number of methods in = the
>> Provider
>> > as there will be no need for the sendAck(AckMessage),
>> > sendInvite(InviteMessage) etc.. as they would be replaced = by the
>> > single method sendRequest(RequestMessage).
>> >
>> > I personally see three arguments for keeping the JAIN SIP = stack as
>> small
>> > as possible:
>> >
>> > 1) The first is for embedded applications where stack size = has to
>> be
>> > kept to a minimum as memory is at a premium.  So if = just using the
>>
>> > Basic message suffices then this will compile and run with = a small
>>
>> > number of classes present from the stack.  Don't = forget,
>> obfuscation
>> > will help in extracting only the Messages, Headers and = even
>> methods
>> > required from a jar file but it won't do everything.
>> >
>> > 2) The second is that users may be put off or confused by = the
>> sheer
>> > size and complexity of the JAIN stack.  So if only = using the
>> > BasicMessage gets them on the first rung of the ladder = then it is
>> a
>> > good starting point and allows them to build up to bigger = and
>> better
>> > things.
>> >
>> > 3) We also have to consider who is going to implement the = JAIN SIP
>>
>> > stack. If it is indeed overly complicated then no-one or a = single
>> > vendor may end up implmenting the stack and thus its = definition
>> and
>> > all the hard work that has gone into it is useless.
>> >
>> > On Mon, 16 Oct 2000, Chris Harris wrote:
>> > > Itamar,
>> > >
>> > > The idea of levelling the API based on what messages, headers
>> and response codes
>> > > are understood is certainly an interesting one - = minimal, basic,
>> redirection,
>> > > firewall-friendly, negotiation, authentication and "full".
>> > >
>> > > jain.protocol.ip.sip
>> > > jain.protocol.ip.sip.header
>> > > jain.protocol.ip.sip.message
>> > >
>> > > could then become...
>> > >
>> > > jain.protocol.ip.sip - listener, provider, stack, = general
>> classes used at all
>> > > levels
>> > > jain.protocol.ip.sip.header - contains base Header = class (and
>> requestHeader,
>> > > ResponseHeader, EntityHeader, GeneralHeader)
>> > > jain.protocol.ip.sip.message - contains base Message = class
>> > >
>> > > jain.protocol.ip.sip.minimal - general classes used = only at this
>> level and above
>> > >
>> > > jain.protocol.ip.sip.minimal.header - headers used = only at this
>> level and above
>> > > jain.protocol.ip.sip.minimal.message - messages only = used at
>> this level and
>> > > above
>> > >
>> > > jain.protocol.ip.sip.basic - general classes used = only at this
>> level and above
>> > > jain.protocol.ip.sip.basic.header - headers used only = at this
>> level and above
>> > > jain.protocol.ip.sip.basic.message - messages used = only at this
>> level and above
>> > > ...
>> > > ....
>> > > jjain.protocol.ip.sip."full" - general = classes only used at this
>> level
>> > > jain.protocol.ip.sip."full".header - = headers used only at this
>> level
>> > > jain.protocol.ip.sip."full".message - = messages used only at this
>> level
>> > >
>> > > The API user could then pick the packages they need - = say they
>> initially only
>> > > want the minimal features, but then realise they need = to use
>> their application
>> > > behind a firewall - then they can simply add the
>> firewall-friendly package. The
>> > > RFC says "In general, each capability listed = builds on the ones
>> above it" but it
>> > > is not hard to see that firewall-friendly and = authentication may
>> be desired
>> > > without redirection for example.
>> > >
>> > > Is this what you hand in mind Itamar?
>> >
>> > --
>> > Gethin Liddell
>> > Ubiquity Software Corporation
>> >
>> > http://www.ubiquity.net
>> > mailto:gethin@ubiquity.net
>> >
>> > _______________________________________________
>> > SIP mailing list
>> > SIP@lists.bell-labs.com
>> > http://lists.bel= l-labs.com/mailman/listinfo/sip
>>
>> --
>> M.Ranganathan
>> NIST Advanced Networking Technologies Group,
>> 100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899.
>> Tel: 301 975 3664 Fax: 301 590 0932
>>
>> Hf=E6j)b? = b=B2=D4^>X=AC=B6=C6=DE-YZn=C7(sm=A7=FF=E5S=CBlm=E9e*=A6=ECr?=BF?=A8=A5= ?=A9=FF-+-Sw=E8=FE=C8=A9
> 

--
M.Ranganathan
NIST Advanced Networking Technologies Group,
100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899.
Tel: 301 975 3664 Fax: 301 590 0932  = <= /p>

Hf=E6j)b? b=B2=D4^>X=AC=B6=C6=DE-YZn=C7(sm=A7=FF=E5S=CBlm=E9e*=A6=ECr?=BF?=A8=A5= ?=A9=FF-+-Sw=E8=FE=C8=A9<= /p>

------=_NextPart_000_0039_01C039E4.4B82BD80-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Oct 19 16:07:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA02395 for ; Thu, 19 Oct 2000 16:07:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 480CF4433F; Thu, 19 Oct 2000 15:07:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 12F404433C for ; Thu, 19 Oct 2000 15:06:46 -0400 (EDT) Received: from dynamicsoft.com (useraa42.ie.uudial.com [212.120.133.43]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id QAA12162; Thu, 19 Oct 2000 16:08:47 -0400 (EDT) Message-ID: <39EF545B.271EA1A6@dynamicsoft.com> From: Chris Harris Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: discussion@sipforum.org Cc: Itamar Gilad , sip@lists.bell-labs.com, jainsip@sun.com Subject: Re: [SIPFORUM] Re: [SIP] JAIN SIP Specification References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 19 Oct 2000 21:06:51 +0100 Content-Transfer-Encoding: 7bit Hi David, OK - I definitely went overboard on this one :) Chris David Ferry wrote: > snip > > > > > Then again, we could always define two JainSipListener subtypes - > > JainSipMessageListener and JainSipTransactionListener...this might be a > > good idea - then we can have an application indicate to the Provider > > whether it is interested in transactions - if it isn't it just receives > > Message objects, and if it is it receives Transaction objects > > (incorporating the associated Messages) The Transaction objects contain > > a transaction id, and can by ClientTransaction or ServerTransaction, and > > their methods can call the Provider's methods with the transaction id > > parameters. Opinions? > > I dont see what this really gains you. > > The current API allows the application to care about transactions if it > wants to. The transaction ID (or handle if you want to think of it that > way) is sufficient for writing apps that care about transaction state. > > The app can also chose to *not* care about transactions very easily. > Making the API larger, to do something which it already does cleanly > seems unneccesary to me. > > Just my 2 cents. > > Cheers, > Dave _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Oct 19 16:12:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA03442 for ; Thu, 19 Oct 2000 16:12:03 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E9B1544398; Thu, 19 Oct 2000 15:12:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from bfb.opencloud.co.nz (bfb.opencloud.co.nz [203.96.151.72]) by lists.bell-labs.com (Postfix) with ESMTP id 1868944344 for ; Thu, 19 Oct 2000 14:33:19 -0400 (EDT) Received: from solid.opencloud.co.nz (solid.opencloud.co.nz [192.168.0.1]) by bfb.opencloud.co.nz (8.10.1/8.9.3) with ESMTP id e9K8VUA24184; Fri, 20 Oct 2000 21:31:30 +1300 (NZDT) Received: from morph.opencloud.co.nz (morph.opencloud.co.nz [192.168.0.8]) by solid.opencloud.co.nz (8.9.3+Sun/8.9.3) with ESMTP id IAA21890; Fri, 20 Oct 2000 08:32:45 +1300 (NZDT) From: David Ferry X-Sender: davidf@morph.opencloud.co.nz To: Chris Harris Cc: Itamar Gilad , sip@lists.bell-labs.com, discussion@sipforum.org, jainsip@sun.com Subject: Re: [SIPFORUM] Re: [SIP] JAIN SIP Specification In-Reply-To: <39EEF762.A8C8B6FA@dynamicsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 20 Oct 2000 08:32:45 +1300 (NZDT) snip > > Then again, we could always define two JainSipListener subtypes - > JainSipMessageListener and JainSipTransactionListener...this might be a > good idea - then we can have an application indicate to the Provider > whether it is interested in transactions - if it isn't it just receives > Message objects, and if it is it receives Transaction objects > (incorporating the associated Messages) The Transaction objects contain > a transaction id, and can by ClientTransaction or ServerTransaction, and > their methods can call the Provider's methods with the transaction id > parameters. Opinions? I dont see what this really gains you. The current API allows the application to care about transactions if it wants to. The transaction ID (or handle if you want to think of it that way) is sufficient for writing apps that care about transaction state. The app can also chose to *not* care about transactions very easily. Making the API larger, to do something which it already does cleanly seems unneccesary to me. Just my 2 cents. Cheers, Dave _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Oct 19 16:33:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA05901 for ; Thu, 19 Oct 2000 16:33:00 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 703944433A; Thu, 19 Oct 2000 15:33:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from elektron.elka.pw.edu.pl (elektron.elka.pw.edu.pl [194.29.160.2]) by lists.bell-labs.com (Postfix) with ESMTP id 9D4E644336 for ; Thu, 19 Oct 2000 15:32:30 -0400 (EDT) Received: from po10.warszawa.cvx.ppp.tpnet.pl ([213.76.110.10]:1137 "EHLO elka.pw.edu.pl") by elektron.elka.pw.edu.pl with ESMTP id ; Thu, 19 Oct 2000 22:31:51 +0200 Message-ID: <39EF59EF.BF0D0F27@elka.pw.edu.pl> From: "Piotr S. Kossowski" Organization: Warsaw University of Technology - Institute of Telecommunications X-Mailer: Mozilla 4.7 [pl] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] Multi-message UDP datagrams Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 19 Oct 2000 22:30:39 +0200 Content-Transfer-Encoding: 7bit Hello, >From rfc-2543bis-02: "(...) If there is additional data in the UDP packet after the last byte of the body has been read, the server MUST treat the remaining data as a separate message. This allows several messages to be placed in a single UDP packet." This way of message servicing is to my mind data queueing issue. I'm not sure of my interpretation. Let's consider scenario: UAS receiving UDP datagram containing two correct messages: INVITE and CANCEL (matched to this INVITE). Immediately, it receiving also BYE (to INVITE). We can conisder it as a FIFO queue of messages (1.INIVTE 2.CANCEL 3.BYE). Let's assume that UAS decide to send 200 response. So, to my mind, sequence of message processing should look like: UAC UAS INVITE -----> <-----------200 (without earilier 18x repsonses) CANCEL------> "<----------" CANCEL has no impact because of 200 resp. to INVITE (?) BYE---------> (Without ACK for 200 resp. to INVITE) <-----------200 (Cseq: xxx BYE) ... and call terminates To summarize: UAS should service all the messages from one UDP datagram BEFORE reading next portion of data from network. For each serviced message should generate a response (or take up other appropriate action) BEFORE processing next message from the datagram or network. It's rather correct, Is it ? Piotr _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Oct 19 17:33:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA12486 for ; Thu, 19 Oct 2000 17:33:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5D2F644354; Thu, 19 Oct 2000 16:33:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cybertron.div8.net (el05-24-131-150-91.ce.mediaone.net [24.131.150.91]) by lists.bell-labs.com (Postfix) with ESMTP id F1E544433A for ; Thu, 19 Oct 2000 16:13:12 -0400 (EDT) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for sip@lists.bell-labs.com; Thu, 19 Oct 2000 16:12:58 -0500 (CDT) From: Billy Biggs To: "Piotr S. Kossowski" Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Multi-message UDP datagrams Message-ID: <20001019161258.A5820@div8.net> References: <39EF59EF.BF0D0F27@elka.pw.edu.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i In-Reply-To: <39EF59EF.BF0D0F27@elka.pw.edu.pl>; from P.Kossowski@elka.pw.edu.pl on Thu, Oct 19, 2000 at 10:30:39PM +0200 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 19 Oct 2000 16:12:58 -0500 Piotr S. Kossowski (P.Kossowski@elka.pw.edu.pl): > [...] This allows several messages to be placed in a single UDP > packet." Looking at your example: > UAS receiving UDP datagram containing two correct messages: INVITE and > CANCEL (matched to this INVITE). Immediately, it receiving also BYE > (to INVITE). We can conisder it as a FIFO queue of messages (1.INIVTE > 2.CANCEL 3.BYE). > > UAC UAS > INVITE -----> > <-----------200 (without earilier 18x repsonses) > CANCEL------> > "<----------" CANCEL has no impact because of 200 resp. to INVITE (?) You should send a 200 response to the CANCEL anyways. > BYE---------> (Without ACK for 200 resp. to INVITE) > <-----------200 (Cseq: xxx BYE) > > ... and call terminates > > To summarize: > UAS should service all the messages from one UDP datagram BEFORE > reading next portion of data from network. For each serviced message > should generate a response (or take up other appropriate action) > BEFORE processing next message from the datagram or network. Why does it matter how the UA does it? In your example above, either way the call still does not complete. I can't think of any realistic example where it would make any difference. -- Billy Biggs, 3Com Email: Billy_Biggs@3com.com http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Oct 19 17:34:39 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA12681 for ; Thu, 19 Oct 2000 17:34:39 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3F92944379; Thu, 19 Oct 2000 16:33:18 -0400 (EDT) Delivered-To: sip@share.research.bell-labs.com Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by lists.bell-labs.com (Postfix) with SMTP id 12AEE4433A for ; Thu, 19 Oct 2000 16:14:07 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Thu Oct 19 17:12:50 EDT 2000 Received: by lists.bell-labs.com (Postfix) id A019C44380; Thu, 19 Oct 2000 16:59:41 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ans.ih.lucent.com (ans.ih.lucent.com [135.2.78.5]) by lists.bell-labs.com (Postfix) with SMTP id 570884437D for ; Thu, 19 Oct 2000 16:59:41 -0400 (EDT) Received: by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id PAA02084; Thu, 19 Oct 2000 15:59:38 -0500 Cc: sip@lists.bell-labs.com Received: from lucent.com by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id PAA02071; Thu, 19 Oct 2000 15:59:37 -0500 Message-ID: <39EF60B3.B1A8FE62@lucent.com> From: "Vijay K. Gurbani" Reply-To: vkg@lucent.com Organization: Intelligent Network/Messaging Systems & Internet Software Group X-Mailer: Mozilla 4.61 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: "Piotr S. Kossowski" Original-CC: sip@lists.bell-labs.com Subject: Re: [SIP] Multi-message UDP datagrams References: <39EF59EF.BF0D0F27@elka.pw.edu.pl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 19 Oct 2000 15:59:31 -0500 Content-Transfer-Encoding: 7bit "Piotr S. Kossowski" wrote: > > Hello, > > >From rfc-2543bis-02: > > "(...) > If there is additional data in the UDP packet after the last byte of > the body has been read, the server MUST treat the remaining data as > a separate message. This allows several messages to be placed in a > single UDP packet." > > This way of message servicing is to my mind data queueing issue. > I'm not sure of my interpretation. > Let's consider scenario: > > UAS receiving UDP datagram containing two correct messages: > INVITE and CANCEL (matched to this INVITE). Immediately, > it receiving also BYE (to INVITE). We can conisder it > as a FIFO queue of messages (1.INIVTE 2.CANCEL 3.BYE). > > Let's assume that UAS decide to send 200 response. > So, to my mind, sequence of message processing should look like: > > UAC UAS > INVITE -----> > <-----------200 (without earilier 18x repsonses) > CANCEL------> > "<----------" CANCEL has no impact because of 200 resp. to INVITE (?) > BYE---------> (Without ACK for 200 resp. to INVITE) > <-----------200 (Cseq: xxx BYE) > > ... and call terminates Piotr: Based on a re-reading of the spec, the CANCEL is responded to with a 200 OK in any case; the CANCEL has no effect on the UAS state if it got to the UAS after the UAS sent out a final response. However, the UAS still responds with a 200 OK for the CANCEL. So your call flow should be: UAC UAS INVITE--------> <------------- 200 OK (CSeq: xxx INVITE) CANCEL--------> ACK-----------> <------------- 200 OK (CSeq: xxx CANCEL) BYE-----------> <------------- 200 OK (CSeq: xxx BYE) - vijay -- Vijay K. Gurbani vkg@lucent.com vkg@research.bell-labs.com vkg@acm.org Internet Software Group/Intelligent Network and Messaging Systems Lucent Technologies/Bell Labs Innovations, 263 Shuman Blvd, Rm 1A-413 Naperville, Illinois 60566 Voice: +1 630 224 0216 Fax: +1 630 713 0184 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Oct 19 17:38:19 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA13081 for ; Thu, 19 Oct 2000 17:38:18 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 839324438C; Thu, 19 Oct 2000 16:33:29 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cybertron.div8.net (el05-24-131-150-91.ce.mediaone.net [24.131.150.91]) by lists.bell-labs.com (Postfix) with ESMTP id C4DCA4434F for ; Thu, 19 Oct 2000 16:22:11 -0400 (EDT) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for sip@lists.bell-labs.com; Thu, 19 Oct 2000 16:22:07 -0500 (CDT) From: Billy Biggs To: Sunitha Kumar Cc: Sip List Subject: Re: [SIP] clarification on tags in the BYE request. Message-ID: <20001019162207.B5820@div8.net> References: <39EF3276.9D0DF858@vovida.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i In-Reply-To: <39EF3276.9D0DF858@vovida.com>; from skumar@vovida.com on Thu, Oct 19, 2000 at 10:42:14AM -0700 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 19 Oct 2000 16:22:07 -0500 Sunitha Kumar (skumar@vovida.com): > It is given that all subsequent requests of the same callLeg contains > the same To header field, including the *tags*. It is also given > here, that a UAC copies the tag from the final response into the ACK, > but it *MUST NOT* copy the tag into any subsequent requests unless the > response was a 200 class response to an INVITE request. Yes, the tag is only valid for the active call. > Does this mean: > UAC -------send INVITE------------->UAS > UAC<------send 200 OK with tag in To----UAS > UAC-------send ACK, with same tag as in To of 200 OK-->UAS > UAC<-------RTP---------------------->UAS > > Now , if BYE is sent from UAC to a UAS, should UAC tag the To field of > the BYE , the same as the 200 OK that it received. Yes, you include the tag in all future transactions on the call-leg. > If yes, why, isn't this another transaction? Huh? The BYE is definitely a subsequent request, and a 200 class response was received. Sounds like this meets the requirements. > I agree that if the BYE were to be sent instead of the ACK( in order > to cancel the call), then it needs to be tagged in the To field. But, > not if the BYE was sent independently, after establishing the call. > The FAQ had no explanation of this. Could someone explain this? Say the original INVITE forked to two UACs, and both 200 responses were sent back to the caller. Then the caller would have created two active calls. Say the caller keeps talking on both calls and now wishes to hang up one of them. If the BYE does not have a tag, and the phones at the other end didn't put in a Contact (or are having both of their calls handled the same proxy), how can the BYE be distinguished at the far end? The tags conclusively define the call leg. -- Billy Biggs, 3Com Email: Billy_Biggs@3com.com http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Oct 19 19:05:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA22583 for ; Thu, 19 Oct 2000 19:05:04 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3908C4435C; Thu, 19 Oct 2000 18:05:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sj_exchange.sj.nuera.com (h-207-20-110-62.ncal.verio.net [207.20.110.62]) by lists.bell-labs.com (Postfix) with ESMTP id 2DF0444354 for ; Thu, 19 Oct 2000 18:04:02 -0400 (EDT) Received: by exchange.sj.nuera.com with Internet Mail Service (5.5.2650.21) id ; Thu, 19 Oct 2000 16:03:57 -0700 Message-ID: <350860CC5B2AD311991D0008C7F7EEAAA02662@exchange.sj.nuera.com> From: "Emami-Nouri, Mohsen" To: "'Phil Hoffer'" , sip@lists.bell-labs.com Subject: RE: [SIP] Repost: Use of Record-Route and Contact Headers MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 19 Oct 2000 16:03:57 -0700 the following text from bis 6.33 might help better understanding: "the UAS copies the record-route request header field unchanged into the response. (record-route is only relevant for 2xx responses and responses where the server can expect the client to retry the same call -id as in 401 or 484" -----Original Message----- From: Phil Hoffer [mailto:phoffer@ubiquity.net] Sent: Wednesday, October 18, 2000 5:02 AM To: sip@lists.bell-labs.com Subject: [SIP] Repost: Use of Record-Route and Contact Headers > Hi, > > Table 4 of bis02 states that a Contact header can occur in the following > response types: > > 1xx > 2xx > 3xx > 485 (Ambiguous) > > However, Table 5 states that Record-Route can occur in the following > response types: > > 2xx > 401 (Unauthorized) > 484 (Address Incomplete) > > I don't see how a response can include a Record-Route, if it can't contain > a Contact. > I believe that 401 and 484 should be added to the list of response types for > a Contact header. > > What do you think? > > Cheers > Phil (Just appreciating how overloaded Contact header is! :) Hi again, No replies so far! Probably got lost in the deluge. Thanks In Advance Phil http://www.ubiquity.net _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Oct 19 19:21:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA25267 for ; Thu, 19 Oct 2000 19:21:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E4AC04435C; Thu, 19 Oct 2000 18:21:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sj_exchange.sj.nuera.com (h-207-20-110-62.ncal.verio.net [207.20.110.62]) by lists.bell-labs.com (Postfix) with ESMTP id CC5D344354 for ; Thu, 19 Oct 2000 18:20:07 -0400 (EDT) Received: by exchange.sj.nuera.com with Internet Mail Service (5.5.2650.21) id ; Thu, 19 Oct 2000 16:20:03 -0700 Message-ID: <350860CC5B2AD311991D0008C7F7EEAAA02663@exchange.sj.nuera.com> From: "Emami-Nouri, Mohsen" To: "'Baniel Uri-CUB001'" , sip@lists.bell-labs.com Subject: RE: [SIP] Stateful proxy MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 19 Oct 2000 16:20:02 -0700 if it is agreed that statelessness means not caring about the reliability of delivery, then a TCP based server is statefull by nature. -----Original Message----- From: Baniel Uri-CUB001 [mailto:Uri.Baniel@motorola.com] Sent: Wednesday, October 18, 2000 8:14 AM To: sip@lists.bell-labs.com Subject: [SIP] Stateful proxy Hello Why does a proxy that uses TCP must be stateful ? Can someone show me a scenario which went wrong because of a proxy have used a TCP and was stateless? Thanks Uri ===================== Uri Baniel Motorola Network solution Sector 1155 W. Dundee Rd Arlington Heights Tel: 847 632 4616 ===================== _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Oct 19 20:19:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA01716 for ; Thu, 19 Oct 2000 20:19:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5C31C4433A; Thu, 19 Oct 2000 19:19:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103]) by lists.bell-labs.com (Postfix) with ESMTP id 375FD44336 for ; Thu, 19 Oct 2000 19:18:06 -0400 (EDT) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate3.mot.com (motgate3 2.1) with ESMTP id RAA20868 for ; Thu, 19 Oct 2000 17:15:14 -0700 (MST)] Received: [from il35exm01.cig.mot.com (IL35EXM01.cig.mot.com [160.19.16.101]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id RAA02758 for ; Thu, 19 Oct 2000 17:18:00 -0700 (MST)] Received: by IL35EXM01.cig.mot.com with Internet Mail Service (5.5.2651.58) id <429QHFP9>; Thu, 19 Oct 2000 19:18:00 -0500 Message-ID: <0DF9920C9AD8D211AB0C0008C7CF1C9A04ED8551@il27exm02.cig.mot.com> From: Baniel Uri-CUB001 To: "'Emami-Nouri, Mohsen'" , Baniel Uri-CUB001 , sip@lists.bell-labs.com Subject: RE: [SIP] Stateful proxy MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 19 Oct 2000 19:17:53 -0500 Nouri Frankly, I think any SIP entity can achieve SIP reliability, even when using UDP as a transport, by application means (RFC2543bis section 10.4.1 - exponential backoff) On the other hand... I have totally missed RFC2543bis section 10.3 which explicitly address my question. Looks like I need to do some more reading... Sorry for taking your time and thanks anyway! Uri -----Original Message----- From: Emami-Nouri, Mohsen [mailto:memami@nuera.com] Sent: Thursday, October 19, 2000 6:20 PM To: 'Baniel Uri-CUB001'; sip@lists.bell-labs.com Subject: RE: [SIP] Stateful proxy if it is agreed that statelessness means not caring about the reliability of delivery, then a TCP based server is statefull by nature. -----Original Message----- From: Baniel Uri-CUB001 [mailto:Uri.Baniel@motorola.com] Sent: Wednesday, October 18, 2000 8:14 AM To: sip@lists.bell-labs.com Subject: [SIP] Stateful proxy Hello Why does a proxy that uses TCP must be stateful ? Can someone show me a scenario which went wrong because of a proxy have used a TCP and was stateless? Thanks Uri ===================== Uri Baniel Motorola Network solution Sector 1155 W. Dundee Rd Arlington Heights Tel: 847 632 4616 ===================== _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Oct 19 20:52:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA05328 for ; Thu, 19 Oct 2000 20:52:02 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A88714434B; Thu, 19 Oct 2000 19:52:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103]) by lists.bell-labs.com (Postfix) with ESMTP id 3426C44346 for ; Thu, 19 Oct 2000 19:51:50 -0400 (EDT) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate3.mot.com (motgate3 2.1) with ESMTP id RAA28620 for ; Thu, 19 Oct 2000 17:48:58 -0700 (MST)] Received: [from il75exm02.cig.mot.com (IL75EXM02.cig.mot.com [136.182.110.102]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id RAA22520 for ; Thu, 19 Oct 2000 17:51:43 -0700 (MST)] Received: by IL75EXM02.cig.mot.com with Internet Mail Service (5.5.2651.58) id <4Q3SBFL2>; Thu, 19 Oct 2000 19:51:43 -0500 Message-ID: <0DF9920C9AD8D211AB0C0008C7CF1C9A04ED8554@il27exm02.cig.mot.com> From: Baniel Uri-CUB001 To: "'772kh@netian.com'" <772kh@netian.com>, sip@lists.bell-labs.com Subject: RE: [SIP] Redirect Server's merit?? MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="KS_C_5601-1987" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 19 Oct 2000 19:51:41 -0500 I think the fact that redirect server gets back to you right away with an answer may help in some cases. Also I think you can use redirect servers to learn/test the network because you get directly the redirection information as opposed to have it hidden from you by the proxies (unless all proxies are kind enough to ask for Record-Route). Uri -----Original Message----- From: 772kh@netian.com [mailto:772kh@netian.com] Sent: Thursday, October 19, 2000 10:54 AM To: sip@lists.bell-labs.com Subject: [SIP] Redirect Server's merit?? Hi.. Redirect Server has less overhead than Proxy Server.. Other merit?? thank you... _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Oct 19 23:12:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA01758 for ; Thu, 19 Oct 2000 23:12:02 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 659DF44338; Thu, 19 Oct 2000 22:12:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from smail2.channeli.net (unknown [210.112.223.112]) by lists.bell-labs.com (Postfix) with ESMTP id D7A9F44336 for ; Thu, 19 Oct 2000 22:11:23 -0400 (EDT) Received: (from root@localhost) by smail2.channeli.net (8.9.3+Sun/8.9.3) id MAA09984 for sip@lists.bell-labs.com.procmail; Fri, 20 Oct 2000 12:10:52 +0900 (KST) Received: from arnold ([210.101.115.22]) by smail2.channeli.net (8.9.3+Sun/8.9.3) with SMTP id MAA09967 for ; Fri, 20 Oct 2000 12:10:51 +0900 (KST) From: =?ks_c_5601-1987?B?wMzI8byu?= To: Message-ID: MIME-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" 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.50.4133.2400 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by smail2.channeli.net id MAA09967 Subject: [SIP] [SIP]When the proxy server send a CANCEL message?(Help) Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 20 Oct 2000 12:12:24 +0900 Content-Transfer-Encoding: 8bit Message 

I have a question about proxy server. help me please!

A                         proxy                     B
|     INVITE             |                         |
|--------------->|		        |
|      Trying	      |                        |
|<---------------|	INVITE	|
|		              |------------->|
|		              |     RINGING      |
|		              |<-------------|
|		              |                         |
|		              |                         |
|                            |                         |
|                            |    CANCEL        |       When the proxy server send a CANCEL message? 
|                            |------------->|
|                            |                         |

User B send a RINGING message but B is moved away temporarily. 
so User B can't send a 200 OK message to the proxy server. Accordingly User B's phone is ringing so long.

When the proxy server send a CANCEL messge? How long the proxy server wait for 200 OK message from User B?

In the draft-ietf-sip-rfc2543bis_00.ps Figure 13: State transition diagram of server for INVITE method,

After the server received 1XX message for INVITE(current state Call proceeding), when it send a CANCEL messge and goes to Initial state? 

Would anybody give me correct answell ? please




-----------------------------------

¸ø¸»¸®´Â ÀÎÅͳÝä³Î,

ä³Î¾ÆÀÌ http://www.channeli.net
_______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Oct 20 00:20:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA09451 for ; Fri, 20 Oct 2000 00:20:03 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 396BE44338; Thu, 19 Oct 2000 23:20:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from illyana.qualcomm.com (illyana.qualcomm.com [129.46.2.83]) by lists.bell-labs.com (Postfix) with ESMTP id 3299F44336 for ; Thu, 19 Oct 2000 23:19:25 -0400 (EDT) Received: from localhost (mwisdom@localhost) by illyana.qualcomm.com (8.9.3/8.9.3/1.0) with ESMTP id VAA10316 for ; Thu, 19 Oct 2000 21:19:20 -0700 (PDT) From: Mark Wisdom To: sip@lists.bell-labs.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [SIP] Digest Authentication Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 19 Oct 2000 21:19:19 -0700 (PDT) I need some clarification on, and help with, digest authentication. rfc2617, section 3.2.1 states: > A nonce might, for example, be constructed as the base 64 > encoding of > > time-stamp H(time-stamp ":" ETag ":" private-key) Then in section 4.5 it states: > The server created "nonce" value is implementation dependent, > but if it contains a digest of the client IP, a time-stamp, > the resource ETag, and a private server key (as recommended > above) then a replay attack is not simple. rfc2543bis-02, section 14.3 states: > 4. The example procedure for choosing a nonce based on Etag > does not work for SIP. It would be nice if rfc2543 provided an alternate example for creating a nonce. Can this be added to the rfc2543? Does anyone have any guidelines on creating a nonce for use with digest authentication? rfc2543bis-02, section 14.3 also states: > 5. The Authentication-Info and Proxy-Authentication-Info > fields are not used in SIP. If I understand correctly, not allowing the Authentication-Info header eliminates support for mutual authenication (i.e. allowing the server to also authenticate itself to the client by proving to the client that it knows the client's secret). Does SIP allow for mutual authentication when using digest authentication? If not, can we modify rfc2543 so that mutual authentication is possible? Thanks, Mark Wisdom _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Oct 20 01:11:08 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA17120 for ; Fri, 20 Oct 2000 01:11:05 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id CCC6544344; Fri, 20 Oct 2000 00:11:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id B121D44336 for ; Fri, 20 Oct 2000 00:10:07 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA15082; Fri, 20 Oct 2000 01:11:55 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <4WS2XWF6>; Fri, 20 Oct 2000 01:05:54 -0400 Message-ID: From: Jonathan Rosenberg To: "'???'" , sip@lists.bell-labs.com Subject: RE: [SIP] [SIP]When the proxy server send a CANCEL message?(Help) MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="windows-1252" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 20 Oct 2000 01:05:53 -0400 -----Original Message----- >From: hee7816@channeli.net [mailto:hee7816@channeli.net] >Sent: Thursday, October 19, 2000 11:12 PM >To: sip@lists.bell-labs.com >Subject: [SIP] [SIP]When the proxy server send a CANCEL message?(Help) > > > >I have a question about proxy server. help me please! > >A proxy B >| INVITE | | >|--------------->| | >| Trying | | >|<---------------| INVITE | >| |------------->| >| | RINGING | >| |<-------------| >| | | >| | | >| | | >| | CANCEL | When the proxy server send a CANCEL >message? >| |------------->| >| | | > >User B send a RINGING message but B is moved away temporarily. >so User B can't send a 200 OK message to the proxy server. Accordingly User B's phone is >ringing so long. > >When the proxy server send a CANCEL messge? How long the proxy server wait for 200 OK >message from User B? Generally, a proxy will send a CANCEL when: 1. It has forked, and receives a 200 or 600 response on one of the branches, in which case it CANCELs unanswered branches. 2. The time described in the Expires header of the request has elapsed 3. No response at all, even provisional, was ever received 4. Internal logic determines its time to end the call (a CPL, for example). > >In the draft-ietf-sip-rfc2543bis_00.ps Figure 13: State transition diagram of server for >INVITE method, > >After the server received 1XX message for INVITE(current state Call proceeding), when it >send a CANCEL messge and goes to Initial state? You should check out the most recent bis draft. -Jonathan R. Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Oct 20 01:17:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA18966 for ; Fri, 20 Oct 2000 01:17:03 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C47564434F; Fri, 20 Oct 2000 00:17:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 7FD5244344 for ; Fri, 20 Oct 2000 00:16:21 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA15162; Fri, 20 Oct 2000 01:18:25 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <4WS2XWGP>; Fri, 20 Oct 2000 01:12:24 -0400 Message-ID: From: Jonathan Rosenberg To: "'Piotr S. Kossowski'" , sip@lists.bell-labs.com Subject: RE: [SIP] Multi-message UDP datagrams MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 20 Oct 2000 01:12:24 -0400 It was my view that receiving multiple messages in a single datagram was the same as if they were received in separate datagrams. In other words, there was no requirements for ordering or completion. The result of that was a simplification in the implementation of handling this case; UDP works just like TCP. Imposing transactional requirements adds significant burden. I'd rather not do that unless there was serious requirements or needs here. In fact, I would argue that multiple messages per datagram might be something to consider for removal. I've never seen it used. I'm not sure what the benefit is, in reality. There is little byte savings, and its just more complexity that is really needless. Lets simplify, not complicate. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com > -----Original Message----- > From: Piotr S. Kossowski [mailto:P.Kossowski@elka.pw.edu.pl] > Sent: Thursday, October 19, 2000 4:31 PM > To: sip@lists.bell-labs.com > Subject: [SIP] Multi-message UDP datagrams > > > Hello, > > >From rfc-2543bis-02: > > "(...) > If there is additional data in the UDP packet after the last byte of > the body has been read, the server MUST treat the remaining data as > a separate message. This allows several messages to be placed in a > single UDP packet." > > This way of message servicing is to my mind data queueing issue. > I'm not sure of my interpretation. > Let's consider scenario: > > UAS receiving UDP datagram containing two correct messages: > INVITE and CANCEL (matched to this INVITE). Immediately, > it receiving also BYE (to INVITE). We can conisder it > as a FIFO queue of messages (1.INIVTE 2.CANCEL 3.BYE). > > Let's assume that UAS decide to send 200 response. > So, to my mind, sequence of message processing should look like: > > UAC UAS > INVITE -----> > <-----------200 (without earilier 18x repsonses) > CANCEL------> > "<----------" CANCEL has no impact because of 200 resp. to > INVITE (?) > BYE---------> (Without ACK for 200 resp. to INVITE) > <-----------200 (Cseq: xxx BYE) > > ... and call terminates > > To summarize: > UAS should service all the messages from one UDP datagram > BEFORE reading next portion of data from network. For each serviced > message should generate a response (or take up other appropriate > action) BEFORE processing next message from the datagram or network. > > It's rather correct, Is it ? > > > Piotr > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Oct 20 01:50:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA28605 for ; Fri, 20 Oct 2000 01:50:02 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0432744338; Fri, 20 Oct 2000 00:50:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 1359544336 for ; Fri, 20 Oct 2000 00:49:02 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA15247; Fri, 20 Oct 2000 01:47:23 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <4WS2XWHB>; Fri, 20 Oct 2000 01:41:22 -0400 Message-ID: From: Jonathan Rosenberg To: "'Sunitha Kumar'" , sip bell labs Subject: RE: [SIP] clarification on tags in the BYE request. MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 20 Oct 2000 01:41:22 -0400 -----Original Message----- >From: Sunitha Kumar [mailto:skumar@vovida.com] >Sent: Thursday, October 19, 2000 1:42 PM >To: sip bell labs >Subject: [SIP] clarification on tags in the BYE request. > > >With respect to section 11.3 and 11.4 in September 4, SIPbis, >It is given that all subsequent requests of the same callLeg contains the same To header >field, including the *tags*. >It is also given here, that a UAC copies the tag from the final response into the ACK, but >it *MUST NOT* copy the tag into any subsequent requests unless the response was a 200 class >response to an INVITE request. Correct. >Does this mean: >UAC -------send INVITE------------->UAS >UAC<------send 200 OK with tag in To----UAS >UAC-------send ACK, with same tag as in To of 200 OK-->UAS >UAC<-------RTP---------------------->UAS >Now , if BYE is sent from UAC to a UAS, should UAC tag the To field of the BYE , the same >as the 200 OK that it received. Of course. Isn't that exactly what is implied by the text? >If yes, why, isn't this another transaction? Huh?? Of course it is another transaction. >I agree that if the BYE were to be sent instead of the ACK( in order to cancel the call), You always send ACK, even if you want to hang up. >then it needs to be tagged in the To field. But, not if the BYE was sent independently, >after establishing the call. Wrong. The text here is clear, I think. All subsequent transactions after a successful INVITE carry the tag from the To field in the response to that initial INVITE. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Oct 20 05:27:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA06232 for ; Fri, 20 Oct 2000 05:27:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C621944338; Fri, 20 Oct 2000 04:27:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from drago1.ubiquity.net (unknown [194.202.146.92]) by lists.bell-labs.com (Postfix) with SMTP id 1157144336 for ; Fri, 20 Oct 2000 04:26:03 -0400 (EDT) Received: from gecko.ubiquity.co.uk by drago1.ubiquity.net via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 20 Oct 2000 09:26:32 UT Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id KAA03813; Fri, 20 Oct 2000 10:20:51 +0100 (BST) From: "Jo Hornsby" To: "Singh, Manish" , Subject: RE: [SIP] Multicast Registration Message-ID: <006501c03a77$09c8fce0$4e34c3c1@ubiquity.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 20 Oct 2000 10:20:50 +0100 Content-Transfer-Encoding: 7bit > Section 4.2.6 of the RFC2543 says : > > "It is RECOMMENDED that the UA registers via multicast and send a > registration to its "home" address, i.e, the server for the domain > that it uses as its From address in outgoing requests. > > Multicast reqistrations are addressed to the well known "all SIP > servers" multicast address "sip.mcast.net". > > RFC further adds : " SIP UAs MAY listen to that address......, however > they do not respond to the request". > > From this I understand that a UA will send a multicast REGISTER > request to "sip.mcast.net" as well as a unicast REGISTER request to > the domain Registrar server, that it uses as its From address. > > Pls clarify the following : > > - Does the term "all SIP servers" include standalone Registrar > servers? In this context, "all SIP servers" is just an address; it might represent no SIP servers if noone is listening. &:) If a "standalone Registrar" has joined the sip.mcast.net group, then yes, it is included. > - Should the Registrar server listen to the multicast address and > accept registrations? That's up to the implementor and administrator of the Registrar. > - If it should, then should registrar server respond to such REGISTER > requests? With a 2xx, or not at all, I would think. > - Should the UA which issues the REGISTER request, expect multiple 2xx > responses for it. It's certainly possible; particularly if redundancy is being employed. HTH, - Jo. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Oct 20 06:13:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA11188 for ; Fri, 20 Oct 2000 06:13:04 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C724844338; Fri, 20 Oct 2000 05:13:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lists.bell-labs.com (Postfix) with ESMTP id 9615B44336 for ; Fri, 20 Oct 2000 05:12:37 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id e9KACVt15593; Fri, 20 Oct 2000 12:12:31 +0200 (MEST) 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 NAA25748; Fri, 20 Oct 2000 13:12:29 +0300 (EET DST) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.73]) by greymse1.lmf.ericsson.se (8.9.3 (PHNE_18979)/8.8.6) with ESMTP id NAA07086; Fri, 20 Oct 2000 13:12:28 +0300 (EETDST) Message-ID: <39F01A83.2F17AAE2@lmf.ericsson.se> From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Cc: Brian Stucker , hammer michael Subject: Re: [SIP] Session-timer with INFO References: <36FA02BD7083D411BC9E0000F8073E43F31A06@crchy271.us.nortel.com> Content-Type: multipart/mixed; boundary="------------9641541722E744D58D56F56E" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 20 Oct 2000 13:12:19 +0300 This is a multi-part message in MIME format. --------------9641541722E744D58D56F56E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, I think this issue is also related to another thread, 'Source Routing/Route out of band'. If the reason for using re-INVITE is that booted stateful proxies can re-establish the session, but they don't support Routes in a new INVITE, I guess it will not work. Of course, an INFO would not pass that proxy either, so it is a general problem, and does not only affect the session-timer functionality. Christer Holmberg Ericsson Finland > Brian Stucker wrote: > > Your correct, I can't stop the UAC from sending the method again, but > I'd like to plead to as many implementors as I can that it would > definitely be preferable in any setting if you wouldn't. =) > > Brian > > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > Sent: Tuesday, October 17, 2000 9:00 AM > To: sip@lists.bell-labs.com > Cc: hammer michael > Subject: Re: [SIP] Session-timer with INFO > > Hi, > > If I send you an INFO, or any other method that you don't support, you > > can for example send a 501 Not Implemented response, and include an > Allow header with the methods you support. Of course, you can't stop > the > UAC of sending the method again, if he chooses to... > > You can not, however, tell an UAC not to send you re-INVITEs, because > then you would also forbid the UAC to send you INVITEs - and I don't > think you want to do that. Also, the specification says that a UA MUST > > be able to receive INVITEs (which included re-INVITEs), so... > > Regards, > > Christer Holmberg > Ericsson Finland > > hammer michael wrote: > > > > Is this the Internet version of "let them eat cake?" Signal-spam is > not > > more palatable than the normal variety. > > > > Is there a response code that can indicate the sentiment: I don't > support > > this method, don't try it again? It might also be good to make sure > that > > such undesirable sub-methods are indicated as "Unsupported." If > that > > sub-method is well-defined, then that header parameter should be > applicable. > > > > Mike > > > > At 12:30 AM 10/17/2000 +0300, Christer Holmberg wrote: > > > > >Hi, > > > > > > >Good points. Here's one more problem you may want to consider. > > > >Whenever you invoke a ping-style method of deciding if a session > is > > > >alive, you open up problems due to network jitter and bandwidth. > For > > > >instance, you could easily have a packet delayed at an endpoint > due to > > > >a large file transfer starting up, or some other bandwidth > consuming > > > >event. In this case, your ping could be delayed long enough to > cause > > > >the session to drop for no good reason. > > > > > >Well, this could be the case no matter which method (INVITE, INFO, > or > > >whatever...) you use in the heartbeat request... > > > > > > >You're also creating the potential for artificial problems in > wireless > > > >networks by using a ping-method to keep a session alive. During a > > > > >handover there may be a period where packets are in effect > "muted" for > > > >a short period of time. The mute period may not, by itself be > long > > > >enough to trigger a ping-timer to pop and kill the session, but > if the > > > >ping was near the edge of the time envelope to be accepted as > > > >"on-time" anyhow, once again, your session could very easily drop > when > > > >the media was operating just fine. > > > >Also, keep in mind, the longer you set the ping timer for, the > more > > > >network resources you will likely waste over time because of the > > > >additional latentcy in discovering a "dead" session. > > > > > >Just to clarify, this "ping-method" IS already defined for SIP > > >(draft-ietf-sip-session-timer-02.txt), and re-INVITEs are used to > ping. > > >My idea was about replacing the re-INVITE with INFO, which mean we > would > > >actually save resources since we don't have to send ACK every time. > > > > > > > >This method has one other nasty side-effect. You'd be wasting > network > > > >resources on an event that will likely not occur very often. > After > > > >all, every INFO exchange except the very last one that > invalidates the > > > >session could have very well not been sent without any negative > impact > > > >on the session (otherwise they would have been the last one). So > > > >you've got proxies and UAs, and other transport resources being > tied > > > >up processing packets that by and large are providing no value, > and > > > >they're chewing up bandwidth budget that other services could be > using > > > >instead. > > > > > >That is an interesting point, and it is valid also for a number of > other > > >SIP extensions where extra messages are sent (e.g. PRACK), but it > is > > >another discussion. > > > > > > >Please keep in mind that not everyone is looking at implementing > SIP > > > >on a 10Mbit+ hardwired LAN (or has to scale up to tremendous > numbers > > > >of users), pinging and triangle-routing can be the death-knell of > > > > >these sorts of networks. > > > > > >Who said "bandwidth is free"? :) > > > > > > >Because of all of this, I think it would be a very bad idea for a > UA > > > >to send an INFO to a client who repeatedly tells him "I don't > > > >understand INFO" to see if he's alive. > > > > > >The number of messages on the network will be the same no matter if > we > > >send an INVITE which he understands, or an INFO he may not > understand. > > >Also, when we receive the response for the INVITE we also have to > send > > >back an ACK, which is not the case when INFO is used. > > > > > > >He may not understand INFO because that particular network > doesn't > > > deem >the bandwidth required for this mechanism as being best used > for > > > that >purpose. If someone tells you "don't send me this method" > then > > > don't send >it to them. > > > > > >Again, this has nothing to do with the bandwith issue. Even if I > send > > >re-INVITEs, which the other party understands, he can not tell me > not to > > >send any more re-INVITEs. > > > > > > >Otherwise your implementation may be viewed as favorably as the > record > > > >clubs that used to require you to send them a card every month > telling > > > >them not to send you anything by some groups. > > > > > >Well, it's not up to me to decide when and if an operator will use > the > > >session-timer, as defined in the draft, or not - I am just trying > to > > >make it as good (and less resource consuming) if he choses to. > > > > > >Regards, > > > > > >Christer Holmberg > > >Ericsson Finland > > > > > > > > > > > > > > Brian Stucker > > > > Nortel Networks > > > > > > > > -----Original Message----- > > > > From: Culpepper, Bert > [mailto:bert.culpepper@intervoice-brite.com] > > > > Sent: Monday, October 16, 2000 3:38 PM > > > > To: Christer Holmberg; sip@lists.bell-labs.com > > > > Cc: Rohan Mahy > > > > Subject: RE: [SIP] Session-timer with INFO > > > > > > > > Some things to think about. > > > > > > > > I believe INFO is _not_ to be used to modify the state of a > session. > > > > I > > > > suppose a debate is possible about session-timer affecting > session > > > > state - present vs. future and if INFO is only restricted to > one. But > > > > it's > > > > probably best to leave it alone. Also, the INV-200-ACK exchange > > > > > allows multiple parties to agree on the duration of the > session. If > > > > the > > > > recipient of the INFO request wants a smaller value (because its > > > > > heartbeat interval is shorter) for the session timer it would > have to > > > > send its own INFO request (unless you plan to keep the proposed > > > > Session-expires header and its use in a 200 OK). Now four > > > > messages are needed. In addition, there may be proxy issues > when > > > > using INFO. There's other behavior described in the draft too. > > > > > > > > > -----Original Message----- > > > > > From: Christer Holmberg > [mailto:christer.holmberg@lmf.ericsson.se] > > > > > Sent: Monday, October 16, 2000 3:42 PM > > > > > To: sip@lists.bell-labs.com > > > > > Cc: Rohan Mahy > > > > > Subject: Re: [SIP] Session-timer with INFO > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > Thanks for the comments! > > > > > > > > > > >If the UA crashed and rebooted and forgot about the old > session, it > > > > > > > > > would > > > > > >respond with either a 481 call leg doesn't exist (you would > know > > > > the > > > > > call > > > > > >is down), or a 501 (you know the UA is up, but is the call?) > > > > > > > > > > > >thanks, > > > > > >-rohan > > > > > > > > > > I think that would be good, because then we could inform the > user > > > > that > > > > > the call doesn't exist anymore. > > > > > > > > > > Let's assume the UAS crashes, reboots and the UAC sends the > > > > > session-timer re-INVITE. If the UAS has forgotten about the > old > > > > > session > > > > > it would consider the re-INVITE as a new INVITE, for a new > session. > > > > It > > > > > would try to establish a new session - and we could suddenly > start > > > > > receiving provisional 18x responses (with or without SDP > bodies), > > > > > and/or > > > > > a 200 response with a SDP body, to the session-timer > re-INVITE. What > > > > > > > > > do > > > > > we do then? > > > > > > > > Well, you could ignore the provisional responses (you know the > other > > > > end > > > > is confused) and let the session get re-established or decide to > > > > > terminate > > > > the session with CANCEL/BYE. > > > > > > > > Regards, > > > > Bert > > > > > > > > > > > > > > Regards, > > > > > > > > > > Christer Holmberg > > > > > Ericsson Finland > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > At 10:55 AM 10/16/00 , Christer Holmberg wrote: > > > > > > > > > > > > > >Hi, > > > > > > > > > > > > > >First, this mail is NOT a proposal for a change. I would > just > > > > like > > > > > to > > > > > > >hear some opinions - or maybe it has already been discussed > on > > > > the > > > > > list? > > > > > > > > > > > > > >The INFO Method RFC says that for INFO requests without a > message > > > > > > > > > body, > > > > > > >a server supporting INFO MUST respond with response code > 200. So, > > > > > > > > > my > > > > > > >question is: why couldn't INFO be used for the > session-timer > > > > > > >functionality? Is the ACK the (re-)INVITE provides really > > > > necessary > > > > > for > > > > > > >the purpose? > > > > > > > > > > > > > >And, like the session-timer is defined now, the other party > would > > > > > > > > > not > > > > > > >even have to support the INFO method, because a 501 Not > > > > Implemented > > > > > > >would be sent, and the sender of the INFO would know the > session > > > > is > > > > > > >"alive". > > > > > > > > > > > > > >Just some thoughts... Please let me know if there is > something I > > > > > haven't > > > > > > >taken into consideration. > > > > > > > > > > > > > >Regards, > > > > > > > > > > > > > >Christer Holmberg > > > > > > >Ericsson Finland > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > SIP mailing list > > > > SIP@lists.bell-labs.com > > > > http://lists.bell-labs.com/mailman/listinfo/sip --------------9641541722E744D58D56F56E Content-Type: text/x-vcard; charset=us-ascii; name="christer.holmberg.vcf" Content-Description: Card for Christer Holmberg Content-Disposition: attachment; filename="christer.holmberg.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Holmberg;Christer tel;cell:+358-40-5604412 tel;work:+358-9-2992943 x-mozilla-html:FALSE org:Ericsson;Advanced Signalling Research Laboratory adr:;;;;;; version:2.1 email;internet:christer.holmberg@lmf.ericsson.se title:System Designer fn:Christer Holmberg end:vcard --------------9641541722E744D58D56F56E-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Oct 20 06:26:06 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA12555 for ; Fri, 20 Oct 2000 06:26:06 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6148844369; Fri, 20 Oct 2000 05:26:07 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id EE38B44367 for ; Fri, 20 Oct 2000 05:25:18 -0400 (EDT) Received: from dynamicsoft.com (ip28.honxr1.ras.tele.dk [195.249.119.28]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id GAA15736; Fri, 20 Oct 2000 06:27:19 -0400 (EDT) Message-ID: <39F01CE8.CA101D2B@dynamicsoft.com> From: Anders Kristensen Organization: dynamicsoft X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 To: Sean Olson Cc: Gonzalo Camarillo , Jo Hornsby , SIP Subject: Re: Source Routing WAS Re: [SIP] Route learnt out of band References: <004c01c039ce$0b1c1590$4e34c3c1@ubiquity.co.uk> <39EEF890.7D7360F9@lmf.ericsson.se> <39EF0442.F270B90D@dynamicsoft.com> <39F002E9.832D8431@ericsson.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 20 Oct 2000 12:22:32 +0200 Content-Transfer-Encoding: 7bit Sean Olson wrote: > > There is a potential issue with solution 1 depending on the scope of the > problem that you are trying to solve. Consider the situation below: > > UAC ---> Outbound ---> Arbitrary SIP network ---> Service Network > Proxy Entry Point > > If you are trying to define the Route: between the Outbound Proxy > and the Entry Point into your service network, then solution 1 works > fine. If, however, you are trying to specify the route to take *once > you reach the entry point*, then solution 1 does not help you. > That was the problem I was trying to solve by storing the Route: > headers in the Request-URI. The Request-URI would point to the > Entry Point. When the request arrived at the Entry Point, the > Entry Point could use the Route: headers in the Request-URI > to route the request within the service network. OK, I get it. > > Basically, the problem is that Route: headers are interpreted by > the first node that receives the SIP request, even if the Route: > headers are not intended for that node. Right, but I would still prefer correcting that behaviour rather than adding new syntax to URIs. So in the updated routing algorithm a proxy receiving a request with URI sip:user@X and some Route would pop the top Route element and route the request to it, ONLY if the host part of the request URI identifies itself, otherwise it would proxy to that request URI and leave both the request URI and Route intact. Would that work? This is all under the assumption that the problem is a real one and is worth solving. > > I realize this is an odd case, but I thought this was the problem > that was being looked at. The problem of specifying a Route: > from the outbound proxy onward is much simpler, I think. Maybe, but thinking that current proxies would actually work in that scenario is, IMHO, overly optimistic. Anders > > -- > Sean Olson > > Anders Kristensen wrote: > > > I thought 1) was what we'd been talking about all along. I see no point > > whatsoever of putting the Route header into the request-URL. My > > understanding is that the grammar for SIP URLs allow headers and body in > > URLs simply so that URLs can be passed around out-of-band, e.g. in an > > HTML page, with extra info, for example a Subject line. When the user > > clicks the URL, the UAC constructs a request adding headers and body > > from the selected URL. As of 3) it might be the cleaner approach but > > I'd rather see Route work in this case also. > > > > Anders > > > > Gonzalo Camarillo wrote: > > > > > > Hi, > > > > > > I see three possible choices here: > > > > > > 1) The UAC adds a Route header to the INVITE. This Route header is to be > > > used just by this first INVITE. The following transactions will follow > > > the path resulting from the Record-Route header coming in the 200 OK (or > > > in the first provisional response). The UAC knows that the first Route > > > header was built by him, so the Route header in subsequent requests will > > > be ellaborated with the RR information received. > > > > > > A proxy will receive a INVITE with a Route header. This proxy does not > > > have any state for this call-leg. It will add himself to the > > > Record-Route (this is already recommended for robustness in the bis > > > draft) and forward the INVITE based on the Route header. > > > > > > The weak point of this approach is the situation when the proxy is not > > > happy with receiving INVITEs with Route headers without having any state > > > for it. > > > Anyway, for robustness, any existing server will most likely perform the > > > same actions I have just described. When an existing implementation > > > crashes and goes up again, it should handle re-INVITEs with Route > > > headers for call legs whose state got lost when the server crashed. > > > > > > 2) The Route header is added to the Request-URI as Sean suggests in > > > http://lists.bell-labs.com/pipermail/sip/2000q3/002748.html > > > > > > This works if all the proxies in the path understand Request-URIs with > > > headers. If any proxy in the path does not it will remove them and go on > > > routing the call without taking into consideration the Route header in > > > the Request-URI. > > > > > > 3) Adding a new header called something like Source-Route. If a proxy > > > does not understand this new header it will ignore it. If the next proxy > > > does understand, it will route the call based on it. This can generate > > > loops. > > > Thus, a require header would be necessary if such a new header was > > > created. > > > > > > Solution number 1 seems to me to be the best. > > > Solution number 2 might break some implementations that use fix-length > > > arrays for storing the request-URI (request-URIs would become very big). > > > Solution number 3 does not look good. > > > > > > Any concerns with solution number 1? > > > > > > Regards, > > > > > > Gonzalo > > > > > > Jo Hornsby wrote: > > > > > > > > > > I'm not sure that this is necessarily true. If you look to bis02, > > > > > > we have: > > > > > > 6.34.3 Request Destination > > > > > > Unless this would cause a loop, any client, including > > > > > > the UAC, SHOULD send the next request for this call leg > > > > > > to the first Request-URI in the Route request header field. > > > > > > A client MAY forward the request to a designated proxy > > > > > > instead, for example, if it lacks DNS resolution capability. > > > > > > If a client uses the first Route entry to route the request, > > > > > > it removes it. > > > > > > > > > > > > Thus there is flexibility here. > > > > > > > > > > > > When is a proxy likely to ignore a Route directive? My initial > > > > > > thoughts are when there are networking issues (it knows it has > > > > > > to go via some ALG-proxy, for instance), or when there are > > > > > > billing issues. But there is nothing wrong with this. > > > > > > > > > > > > Thus I would say that as long as a proxy is happy to receive a > > > > > > request with Route headers in for an unknown call leg, things > > > > > > should work out okay; it will use other proxies as necessary, > > > > > > and any of these will Record-Route if they need to remain in > > > > > > the signalling path. > > > > > > > > > > The problem I was mentioning earlier is that things break down when a > > > > > proxi is NOT happy to proxy requests for unknown legs with Route headers > > > > > without being able to add itself to the Record-Route and stay on the > > > > > signaling path. OK, so it can always try and recourd-route, the question > > > > > is whether other proxies and the UAs play along, i.e. other proxies also > > > > > adds themselves to the RR even when they're already on the Route and > > > > > also whether UAs updates their routes. > > > > > > > > Since neither UA has seen a Record-Route yet, I would suggest that > > > > they should have no well-defined Route for this Call (Call Leg) > > > > yet. The originating UA may well supply an initial Route list, but > > > > it should be discarded for subsequent requests, and the "normal" > > > > behaviour used. > > > > > > > > Mostly it comes down to the "if their proxy/UA doesn't support it, > > > > don't buyfrom/routewith them" approach. It's unlikely that someone > > > > is going to require routing across a disparate set of proxies which > > > > have no real relation to each other (I would guess typically one is > > > > going to want to route through, say their "home" proxy, and their > > > > favourite ASP proxy, for instance). > > > > > > > > > Neither is assured by the current > > > > > draft, I think (haven't checked). > > > > > > > > UAs should not update their Routes (save noting new Contact > > > > addresses); the only thing that proxies continually reinserting > > > > Record-Route s buys is recovery after a crash. > > > > > > > > > The distinction between loose and strict source routing seems to me > > > > > useful in understanding the problem, but most of the time a UAC can't > > > > > know for sure whether what it's doing is loose or strict. > > > > > > > > Agreed. The question is: does this really matter if the request > > > > visits all the desired proxies in both cases? > > > > > > > > - Jo. > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip -- Anders Kristensen _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Oct 20 07:01:08 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA18667 for ; Fri, 20 Oct 2000 07:01:08 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9383D44367; Fri, 20 Oct 2000 06:01:07 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lists.bell-labs.com (Postfix) with ESMTP id B36A744336 for ; Fri, 20 Oct 2000 06:00:41 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id e9KB0WZ18536; Fri, 20 Oct 2000 13:00:32 +0200 (MEST) Received: from lmf.ericsson.se (E005004B57366.lmf.ericsson.se [131.160.30.12]) by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id OAA29667; Fri, 20 Oct 2000 14:00:30 +0300 (EET DST) Message-ID: <39F025C6.624233B6@lmf.ericsson.se> From: Gonzalo Camarillo X-Mailer: Mozilla 4.74 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Anders Kristensen Cc: sean.olson@ericsson.com, Jo Hornsby , SIP Subject: Re: Source Routing WAS Re: [SIP] Route learnt out of band References: <004c01c039ce$0b1c1590$4e34c3c1@ubiquity.co.uk> <39EEF890.7D7360F9@lmf.ericsson.se> <39EF0442.F270B90D@dynamicsoft.com> <39F002E9.832D8431@ericsson.com> <39F01CE8.CA101D2B@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 20 Oct 2000 14:00:22 +0300 Content-Transfer-Encoding: 7bit Hi, Yes, we have many possible problems, and probably many possible solutions. Anyway, let's start with the simplest case and then let's continue studying more complex problems (with probably more complex solutions). I would like to identify if there are issues with allowing the first request of a call-leg to carry a Route header. I believe SIP proxies should accept this type of requests for robustness. If a SIP proxy crashes it loses the state information. The next request (maybe a re-INVITE for the session timer) will carry a Route header and it will look to that proxy like the 1st request of a new call-leg. The proxy should not discard this request just because of this. Thefore, it seems to me that this would be the normal behavior of any current proxy. No changes in the protocol. We need just to explicitly say that the 1st request MAY carry a Route header (if we agree upon this). The behavior of the proxy upon reception of Route headers remains untouched. Besides robustness, this will enable services such as the ones previously described in this thread. Any issues that have not been identified so far? Regards, Gonzalo Anders Kristensen wrote: > > Sean Olson wrote: > > > > There is a potential issue with solution 1 depending on the scope of the > > problem that you are trying to solve. Consider the situation below: > > > > UAC ---> Outbound ---> Arbitrary SIP network ---> Service Network > > Proxy Entry Point > > > > If you are trying to define the Route: between the Outbound Proxy > > and the Entry Point into your service network, then solution 1 works > > fine. If, however, you are trying to specify the route to take *once > > you reach the entry point*, then solution 1 does not help you. > > That was the problem I was trying to solve by storing the Route: > > headers in the Request-URI. The Request-URI would point to the > > Entry Point. When the request arrived at the Entry Point, the > > Entry Point could use the Route: headers in the Request-URI > > to route the request within the service network. > > OK, I get it. > > > > > Basically, the problem is that Route: headers are interpreted by > > the first node that receives the SIP request, even if the Route: > > headers are not intended for that node. > > Right, but I would still prefer correcting that behaviour rather than > adding new syntax to URIs. So in the updated routing algorithm a proxy > receiving a request with URI sip:user@X and some Route would pop the top > Route element and route the request to it, ONLY if the host part of the > request URI identifies itself, otherwise it would proxy to that request > URI and leave both the request URI and Route intact. Would that work? > > This is all under the assumption that the problem is a real one and is > worth solving. > > > > > I realize this is an odd case, but I thought this was the problem > > that was being looked at. The problem of specifying a Route: > > from the outbound proxy onward is much simpler, I think. > > Maybe, but thinking that current proxies would actually work in that > scenario is, IMHO, overly optimistic. > > Anders > > > > > -- > > Sean Olson > > > > Anders Kristensen wrote: > > > > > I thought 1) was what we'd been talking about all along. I see no point > > > whatsoever of putting the Route header into the request-URL. My > > > understanding is that the grammar for SIP URLs allow headers and body in > > > URLs simply so that URLs can be passed around out-of-band, e.g. in an > > > HTML page, with extra info, for example a Subject line. When the user > > > clicks the URL, the UAC constructs a request adding headers and body > > > from the selected URL. As of 3) it might be the cleaner approach but > > > I'd rather see Route work in this case also. > > > > > > Anders > > > > > > Gonzalo Camarillo wrote: > > > > > > > > Hi, > > > > > > > > I see three possible choices here: > > > > > > > > 1) The UAC adds a Route header to the INVITE. This Route header is to be > > > > used just by this first INVITE. The following transactions will follow > > > > the path resulting from the Record-Route header coming in the 200 OK (or > > > > in the first provisional response). The UAC knows that the first Route > > > > header was built by him, so the Route header in subsequent requests will > > > > be ellaborated with the RR information received. > > > > > > > > A proxy will receive a INVITE with a Route header. This proxy does not > > > > have any state for this call-leg. It will add himself to the > > > > Record-Route (this is already recommended for robustness in the bis > > > > draft) and forward the INVITE based on the Route header. > > > > > > > > The weak point of this approach is the situation when the proxy is not > > > > happy with receiving INVITEs with Route headers without having any state > > > > for it. > > > > Anyway, for robustness, any existing server will most likely perform the > > > > same actions I have just described. When an existing implementation > > > > crashes and goes up again, it should handle re-INVITEs with Route > > > > headers for call legs whose state got lost when the server crashed. > > > > > > > > 2) The Route header is added to the Request-URI as Sean suggests in > > > > http://lists.bell-labs.com/pipermail/sip/2000q3/002748.html > > > > > > > > This works if all the proxies in the path understand Request-URIs with > > > > headers. If any proxy in the path does not it will remove them and go on > > > > routing the call without taking into consideration the Route header in > > > > the Request-URI. > > > > > > > > 3) Adding a new header called something like Source-Route. If a proxy > > > > does not understand this new header it will ignore it. If the next proxy > > > > does understand, it will route the call based on it. This can generate > > > > loops. > > > > Thus, a require header would be necessary if such a new header was > > > > created. > > > > > > > > Solution number 1 seems to me to be the best. > > > > Solution number 2 might break some implementations that use fix-length > > > > arrays for storing the request-URI (request-URIs would become very big). > > > > Solution number 3 does not look good. > > > > > > > > Any concerns with solution number 1? > > > > > > > > Regards, > > > > > > > > Gonzalo > > > > > > > > Jo Hornsby wrote: > > > > > > > > > > > > I'm not sure that this is necessarily true. If you look to bis02, > > > > > > > we have: > > > > > > > 6.34.3 Request Destination > > > > > > > Unless this would cause a loop, any client, including > > > > > > > the UAC, SHOULD send the next request for this call leg > > > > > > > to the first Request-URI in the Route request header field. > > > > > > > A client MAY forward the request to a designated proxy > > > > > > > instead, for example, if it lacks DNS resolution capability. > > > > > > > If a client uses the first Route entry to route the request, > > > > > > > it removes it. > > > > > > > > > > > > > > Thus there is flexibility here. > > > > > > > > > > > > > > When is a proxy likely to ignore a Route directive? My initial > > > > > > > thoughts are when there are networking issues (it knows it has > > > > > > > to go via some ALG-proxy, for instance), or when there are > > > > > > > billing issues. But there is nothing wrong with this. > > > > > > > > > > > > > > Thus I would say that as long as a proxy is happy to receive a > > > > > > > request with Route headers in for an unknown call leg, things > > > > > > > should work out okay; it will use other proxies as necessary, > > > > > > > and any of these will Record-Route if they need to remain in > > > > > > > the signalling path. > > > > > > > > > > > > The problem I was mentioning earlier is that things break down when a > > > > > > proxi is NOT happy to proxy requests for unknown legs with Route headers > > > > > > without being able to add itself to the Record-Route and stay on the > > > > > > signaling path. OK, so it can always try and recourd-route, the question > > > > > > is whether other proxies and the UAs play along, i.e. other proxies also > > > > > > adds themselves to the RR even when they're already on the Route and > > > > > > also whether UAs updates their routes. > > > > > > > > > > Since neither UA has seen a Record-Route yet, I would suggest that > > > > > they should have no well-defined Route for this Call (Call Leg) > > > > > yet. The originating UA may well supply an initial Route list, but > > > > > it should be discarded for subsequent requests, and the "normal" > > > > > behaviour used. > > > > > > > > > > Mostly it comes down to the "if their proxy/UA doesn't support it, > > > > > don't buyfrom/routewith them" approach. It's unlikely that someone > > > > > is going to require routing across a disparate set of proxies which > > > > > have no real relation to each other (I would guess typically one is > > > > > going to want to route through, say their "home" proxy, and their > > > > > favourite ASP proxy, for instance). > > > > > > > > > > > Neither is assured by the current > > > > > > draft, I think (haven't checked). > > > > > > > > > > UAs should not update their Routes (save noting new Contact > > > > > addresses); the only thing that proxies continually reinserting > > > > > Record-Route s buys is recovery after a crash. > > > > > > > > > > > The distinction between loose and strict source routing seems to me > > > > > > useful in understanding the problem, but most of the time a UAC can't > > > > > > know for sure whether what it's doing is loose or strict. > > > > > > > > > > Agreed. The question is: does this really matter if the request > > > > > visits all the desired proxies in both cases? > > > > > > > > > > - Jo. > > > > > > _______________________________________________ > > > SIP mailing list > > > SIP@lists.bell-labs.com > > > http://lists.bell-labs.com/mailman/listinfo/sip > > -- > Anders Kristensen > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Oct 20 07:31:06 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA22324 for ; Fri, 20 Oct 2000 07:31:05 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 36F9744338; Fri, 20 Oct 2000 06:31:08 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 67D3744336 for ; Fri, 20 Oct 2000 06:30:57 -0400 (EDT) Received: from dynamicsoft.com ([212.120.151.104]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id HAA15922; Fri, 20 Oct 2000 07:32:48 -0400 (EDT) Message-ID: <39F02CF4.95B8B9AB@dynamicsoft.com> From: Chris Harris Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: discussion@sipforum.org Cc: sip@lists.bell-labs.com, jainsip@sun.com, jaintech@sun.com Subject: Re: [SIPFORUM] Re: [SIP] JAIN SIP Specification References: <39EB464C.44254E5B@dynamicsoft.com> <00101814092004.10136@gethin> <39EDB3C4.282F1EFA@nist.gov> <39EDBC08.A51790EF@dynamicsoft.com> <39F02892.304F353B@ericsson.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 20 Oct 2000 12:31:00 +0100 Content-Transfer-Encoding: 7bit Hi Erik, That is indeed an excellent proposal, which addresses both the Java event model and not dictating the form of the implementation. I think we have a winner here! Chris Erik Nissen wrote: > Dear fellows, > Comment below... > > > "M. Ranganathan" wrote: > > > > > I am all for using interfaces as much as > > > possible and leaving class hierarchy definitions to implemeters. > > > Defining class > > > hierarchies almost lays out an implementation and involves > > > considerable rework for > > > those who have a working java-based stack, but have not used the > > > same classes. OK it > > > is just a matter of labor to map things to the JAIN-SIP class > > > hierarchy but it IS a dis-incentive. > > > > > > 1. Lets use interfaces for all messages rather than actually define > > > class hierarchies ( yes Chris has pointed out the historical > > > precedent behind actually > > > defining class hierarchies for messages. IMHO, there has to be a > > > more compelling reason than that.) > > > > > > Ranga. > > > Chris Harris wrote: > > > > I suppose all classes could be turned into interfaces, except for the > > Message classes which must extend java.util.EventObject to fit into > > the JAIN framework. > > > > I believe it is possible to decouple the "Message" hierarchy from > the EventObject. So that the JAIN-SIP API really is an interface > and not an implementation. > > A MessageEventObject could extend java.util.EventObject > and it could have a getMessage() method to return an instance > with Message interface. > > The code could look like this: > > interface Message { > // ... > } > > public class MessageEventObject extends java.util.EventObject { > > MessageEventObject(Object source, Message message) { > super(source); > this.message = message; > } > > public Message getMessage() { return message; } > > private Message message; > > // ... more about masks for different message types ? > } > > The reason to do a change like this is to *not force* a specific > implementation on the API provider. As M. Ranganathan pointed out > there could be existing stack implementations, to be mapped. > These might even be written in C/C++, in which case the mapping have > to be done over Java Native Interface (JNI). > > I have estimated the construction of a basic InviteMessage > to execute 14 JAIN-SIP API specific constructors, > and another 13 String constructors (counting the body Object as String). > To build a more complete InviteMessage, a number of 'set' methods > then need to be invoked. > > Suppose the you want to reuse objects already constructed by > your stack implementation, and/or use late construction of > most of these JAIN-SIP specific objects. > Thus having a stack which delay constructor execution > (and possibly also parsing parts of the SIP message) > until the data is requested the first time. > I can't see how such optimisations are possible > with the current proposal (version 0.6). > > --- > On the other hand, I very much appreciate the work being done in 0.6. > So I think we should keep this as a "default" implementation, > for example through renaming the current classes from X to X_Impl. > > The InviteMessage would then be defined as: > > interface InviteMessage extends Message { > // ... > } > > public final class InviteMessage_Impl implements InviteMessage > { > // current implementation of version 0.6 > // kept as a first default implementation > } > > --- > > By the way, I will not come to the JAIN meeting. > Someone else have to argue for interface instead of implementation :-) > > Best regards > /Erik Nissen _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Oct 20 08:44:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA01938 for ; Fri, 20 Oct 2000 08:44:02 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id AE7864437A; Fri, 20 Oct 2000 07:44:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from drago1.ubiquity.net (unknown [194.202.146.92]) by lists.bell-labs.com (Postfix) with SMTP id AC0DE44338 for ; Fri, 20 Oct 2000 07:43:45 -0400 (EDT) Received: from gecko.ubiquity.co.uk by drago1.ubiquity.net via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 20 Oct 2000 12:44:15 UT Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id NAA12860; Fri, 20 Oct 2000 13:38:43 +0100 (BST) From: "Jo Hornsby" To: "Jonathan Rosenberg" , "'Sunitha Kumar'" , "sip bell labs" Subject: RE: [SIP] clarification on tags in the BYE request. Message-ID: <006901c03a92$ae446cd0$4e34c3c1@ubiquity.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 20 Oct 2000 13:38:42 +0100 Content-Transfer-Encoding: 7bit > > With respect to section 11.3 and 11.4 in September 4, SIPbis, > > It is given that all subsequent requests of the same callLeg > > contains the same To header field, including the *tags*. > > > > It is also given here, that a UAC copies the tag from the > > final response into the ACK, but it *MUST NOT* copy the tag > > into any subsequent requests unless the response was a 200 > > class response to an INVITE request. > > Correct. > > >Does this mean: > >UAC -------send INVITE------------->UAS > >UAC<------send 200 OK with tag in To----UAS > >UAC-------send ACK, with same tag as in To of 200 OK-->UAS > >UAC<-------RTP---------------------->UAS > > > Now , if BYE is sent from UAC to a UAS, should UAC tag the To > > field of the BYE , the same as the 200 OK that it received. > > Of course. Isn't that exactly what is implied by the text? > > >If yes, why, isn't this another transaction? > > Huh?? Of course it is another transaction. > > >I agree that if the BYE were to be sent instead of the ACK > ( in order to cancel the call), > > You always send ACK, even if you want to hang up. I think this is confusing in the spec; 11.3 says: Multiple responses may arrive at the UAC for a single INVITE request, due to a forking proxy. Each response is distinguished by the "tag" parameter in the To header field, and each represents a distinct call leg. The caller MAY choose to acknowledge or terminate the call with each responding UAS. To acknowledge, it sends an ACK request, and to terminate it sends a BYE request. I interpret this as saying when I receive a 200 to an INVITE, I don't have to send an ACK if I want to "hang-up" the call. I'm glad to see that this is not the case, but I think that the text needs to be changed; perhaps: "...and to terminate it sends an ACK request followed by a BYE request." ? Cheers, - Jo. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Oct 20 10:38:12 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA24822 for ; Fri, 20 Oct 2000 10:38:11 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 476F044339; Fri, 20 Oct 2000 09:38:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103]) by lists.bell-labs.com (Postfix) with ESMTP id 5D73644336 for ; Fri, 20 Oct 2000 09:37:39 -0400 (EDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate3.mot.com (motgate3 2.1) with ESMTP id HAA10761 for ; Fri, 20 Oct 2000 07:34:49 -0700 (MST)] Received: [from il75exm02.cig.mot.com (IL75EXM02.cig.mot.com [136.182.110.102]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id HAA22357 for ; Fri, 20 Oct 2000 07:36:53 -0700 (MST)] Received: by IL75EXM02.cig.mot.com with Internet Mail Service (5.5.2651.58) id <4Q3SBPY1>; Fri, 20 Oct 2000 09:36:22 -0500 Message-ID: <0DF9920C9AD8D211AB0C0008C7CF1C9A04ED8555@il27exm02.cig.mot.com> From: Baniel Uri-CUB001 To: sip@lists.bell-labs.com MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] draft-ietf-sip-call-flows-01.txt Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 20 Oct 2000 09:36:19 -0500 Hi all My understanding is that draft-ietf-sip-call-flows-01.txt has some typos here and there. Can anyone direct me to a document, which summarize all/most of them? Is there any cleaner copy of the draft itself? Thanks Uri ===================== Uri Baniel Motorola Network solution Sector 1155 W. Dundee Rd Arlington Heights Tel: 847 632 4616 ===================== _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Oct 20 10:50:11 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA27197 for ; Fri, 20 Oct 2000 10:50:10 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B2DA744398; Fri, 20 Oct 2000 09:50:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from pmesmtp01.wcom.com (pmesmtp01.wcom.com [199.249.20.1]) by lists.bell-labs.com (Postfix) with ESMTP id C565E44336 for ; Fri, 20 Oct 2000 09:49:14 -0400 (EDT) Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-32 #42256) id <0G2Q00D01H4LKE@firewall.mcit.com> for sip@lists.bell-labs.com; Fri, 20 Oct 2000 14:48:21 +0000 (GMT) Received: from dgismtp04.wcomnet.com ([166.38.58.144]) by firewall.mcit.com (PMDF V5.2-32 #42256) with ESMTP id <0G2Q009JUH4LKW@firewall.mcit.com>; Fri, 20 Oct 2000 14:48:21 +0000 (GMT) Received: from CONVERSION-DAEMON by dgismtp04.wcomnet.com (PMDF V5.2-33 #42262) id <0G2Q00H01H6S1Y@dgismtp04.wcomnet.com>; Fri, 20 Oct 2000 14:49:40 +0000 (GMT) Received: from dgismtp04.wcomnet.com by dgismtp04.wcomnet.com (PMDF V5.2-33 #42262) with SMTP id <0G2Q00H01H6M0V@dgismtp04.wcomnet.com>; Fri, 20 Oct 2000 14:49:40 +0000 (GMT) Received: from wcom.com ([166.46.21.160]) by dgismtp04.wcomnet.com (PMDF V5.2-33 #42262) with ESMTP id <0G2Q00G2GH6BR9@dgismtp04.wcomnet.com>; Fri, 20 Oct 2000 14:49:24 +0000 (GMT) From: Alan Johnston Subject: Re: [SIP] draft-ietf-sip-call-flows-01.txt To: Baniel Uri-CUB001 Cc: sip@lists.bell-labs.com Message-id: <39F05BED.A470A35D@wcom.com> MIME-version: 1.0 X-Mailer: Mozilla 4.7 [en] (Win98; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en References: <0DF9920C9AD8D211AB0C0008C7CF1C9A04ED8555@il27exm02.cig.mot.com> Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 20 Oct 2000 09:51:25 -0500 Content-Transfer-Encoding: 7bit I will be submitting the next version shortly. Thanks, Alan Johnston Baniel Uri-CUB001 wrote: > Hi all > > My understanding is that draft-ietf-sip-call-flows-01.txt has some typos here and there. > Can anyone direct me to a document, which summarize all/most of them? > Is there any cleaner copy of the draft itself? > > Thanks > > Uri > ===================== > Uri Baniel > Motorola > Network solution Sector > 1155 W. Dundee Rd > Arlington Heights > Tel: 847 632 4616 > ===================== > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Oct 20 11:13:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA00324 for ; Fri, 20 Oct 2000 11:13:03 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 476C34438C; Fri, 20 Oct 2000 10:13:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from web10308.mail.yahoo.com (web10308.mail.yahoo.com [216.136.130.86]) by lists.bell-labs.com (Postfix) with SMTP id 70FCC44336 for ; Fri, 20 Oct 2000 01:49:54 -0400 (EDT) Message-ID: <20001020064949.34700.qmail@web10308.mail.yahoo.com> Received: from [203.197.179.26] by web10308.mail.yahoo.com; Thu, 19 Oct 2000 23:49:49 PDT From: james jack To: SIP@lists.bell-labs.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [SIP] Discussion Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 19 Oct 2000 23:49:49 -0700 (PDT) Hi,All: I have one question to consult, the question is that about the 481 Call Leg/Transaction Does Not Exist, on RFC2543bis02, which says "This status is returned under three conditions: The server received a BYE request that does not match any existing call leg, the server received a CANCEL request that does not match any existing transaction or the server received an INVITE with a To tag that does not match the local tag value. (A server simply discards an ACK referring to an unknown transaction.)" . I can't understand the words "or the server received an INVITE with a To tag that does not match the local tag value", could someone give me some example? According to my known,To tag is inserted by UAS or redirect server. which means To tag is used in response, how can a INVITE request with a To tag? Maybe I am wrong, I want to consult with every expert? Thanks! Yours:james __________________________________________________ Do You Yahoo!? Yahoo! Messenger - Talk while you surf! It's FREE. http://im.yahoo.com/ _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Oct 20 11:14:31 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA00512 for ; Fri, 20 Oct 2000 11:14:31 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 92DF3443A4; Fri, 20 Oct 2000 10:13:16 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by lists.bell-labs.com (Postfix) with ESMTP id D5A2544336 for ; Fri, 20 Oct 2000 03:31:49 -0400 (EDT) Received: from mr5.exu.ericsson.se (mr5u3.ericy.com [208.237.135.124]) by imr1.ericy.com (8.9.3/8.9.3) with ESMTP id DAA15972; Fri, 20 Oct 2000 03:31:42 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr5.exu.ericsson.se (8.10.2/8.10.2) with ESMTP id e9K8U2k26767; Fri, 20 Oct 2000 03:30:02 -0500 (CDT) Received: from ericsson.com ([147.214.68.17]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id DAA29305; Fri, 20 Oct 2000 03:31:40 -0500 (CDT) Message-ID: <39F002E9.832D8431@ericsson.com> From: Sean Olson Organization: Ericsson Inc. X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Anders Kristensen Cc: Gonzalo Camarillo , Jo Hornsby , SIP Subject: Re: Source Routing WAS Re: [SIP] Route learnt out of band References: <004c01c039ce$0b1c1590$4e34c3c1@ubiquity.co.uk> <39EEF890.7D7360F9@lmf.ericsson.se> <39EF0442.F270B90D@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 20 Oct 2000 10:31:37 +0200 Content-Transfer-Encoding: 7bit There is a potential issue with solution 1 depending on the scope of the problem that you are trying to solve. Consider the situation below: UAC ---> Outbound ---> Arbitrary SIP network ---> Service Network Proxy Entry Point If you are trying to define the Route: between the Outbound Proxy and the Entry Point into your service network, then solution 1 works fine. If, however, you are trying to specify the route to take *once you reach the entry point*, then solution 1 does not help you. That was the problem I was trying to solve by storing the Route: headers in the Request-URI. The Request-URI would point to the Entry Point. When the request arrived at the Entry Point, the Entry Point could use the Route: headers in the Request-URI to route the request within the service network. Basically, the problem is that Route: headers are interpreted by the first node that receives the SIP request, even if the Route: headers are not intended for that node. I realize this is an odd case, but I thought this was the problem that was being looked at. The problem of specifying a Route: from the outbound proxy onward is much simpler, I think. -- Sean Olson Anders Kristensen wrote: > I thought 1) was what we'd been talking about all along. I see no point > whatsoever of putting the Route header into the request-URL. My > understanding is that the grammar for SIP URLs allow headers and body in > URLs simply so that URLs can be passed around out-of-band, e.g. in an > HTML page, with extra info, for example a Subject line. When the user > clicks the URL, the UAC constructs a request adding headers and body > from the selected URL. As of 3) it might be the cleaner approach but > I'd rather see Route work in this case also. > > Anders > > Gonzalo Camarillo wrote: > > > > Hi, > > > > I see three possible choices here: > > > > 1) The UAC adds a Route header to the INVITE. This Route header is to be > > used just by this first INVITE. The following transactions will follow > > the path resulting from the Record-Route header coming in the 200 OK (or > > in the first provisional response). The UAC knows that the first Route > > header was built by him, so the Route header in subsequent requests will > > be ellaborated with the RR information received. > > > > A proxy will receive a INVITE with a Route header. This proxy does not > > have any state for this call-leg. It will add himself to the > > Record-Route (this is already recommended for robustness in the bis > > draft) and forward the INVITE based on the Route header. > > > > The weak point of this approach is the situation when the proxy is not > > happy with receiving INVITEs with Route headers without having any state > > for it. > > Anyway, for robustness, any existing server will most likely perform the > > same actions I have just described. When an existing implementation > > crashes and goes up again, it should handle re-INVITEs with Route > > headers for call legs whose state got lost when the server crashed. > > > > 2) The Route header is added to the Request-URI as Sean suggests in > > http://lists.bell-labs.com/pipermail/sip/2000q3/002748.html > > > > This works if all the proxies in the path understand Request-URIs with > > headers. If any proxy in the path does not it will remove them and go on > > routing the call without taking into consideration the Route header in > > the Request-URI. > > > > 3) Adding a new header called something like Source-Route. If a proxy > > does not understand this new header it will ignore it. If the next proxy > > does understand, it will route the call based on it. This can generate > > loops. > > Thus, a require header would be necessary if such a new header was > > created. > > > > Solution number 1 seems to me to be the best. > > Solution number 2 might break some implementations that use fix-length > > arrays for storing the request-URI (request-URIs would become very big). > > Solution number 3 does not look good. > > > > Any concerns with solution number 1? > > > > Regards, > > > > Gonzalo > > > > Jo Hornsby wrote: > > > > > > > > I'm not sure that this is necessarily true. If you look to bis02, > > > > > we have: > > > > > 6.34.3 Request Destination > > > > > Unless this would cause a loop, any client, including > > > > > the UAC, SHOULD send the next request for this call leg > > > > > to the first Request-URI in the Route request header field. > > > > > A client MAY forward the request to a designated proxy > > > > > instead, for example, if it lacks DNS resolution capability. > > > > > If a client uses the first Route entry to route the request, > > > > > it removes it. > > > > > > > > > > Thus there is flexibility here. > > > > > > > > > > When is a proxy likely to ignore a Route directive? My initial > > > > > thoughts are when there are networking issues (it knows it has > > > > > to go via some ALG-proxy, for instance), or when there are > > > > > billing issues. But there is nothing wrong with this. > > > > > > > > > > Thus I would say that as long as a proxy is happy to receive a > > > > > request with Route headers in for an unknown call leg, things > > > > > should work out okay; it will use other proxies as necessary, > > > > > and any of these will Record-Route if they need to remain in > > > > > the signalling path. > > > > > > > > The problem I was mentioning earlier is that things break down when a > > > > proxi is NOT happy to proxy requests for unknown legs with Route headers > > > > without being able to add itself to the Record-Route and stay on the > > > > signaling path. OK, so it can always try and recourd-route, the question > > > > is whether other proxies and the UAs play along, i.e. other proxies also > > > > adds themselves to the RR even when they're already on the Route and > > > > also whether UAs updates their routes. > > > > > > Since neither UA has seen a Record-Route yet, I would suggest that > > > they should have no well-defined Route for this Call (Call Leg) > > > yet. The originating UA may well supply an initial Route list, but > > > it should be discarded for subsequent requests, and the "normal" > > > behaviour used. > > > > > > Mostly it comes down to the "if their proxy/UA doesn't support it, > > > don't buyfrom/routewith them" approach. It's unlikely that someone > > > is going to require routing across a disparate set of proxies which > > > have no real relation to each other (I would guess typically one is > > > going to want to route through, say their "home" proxy, and their > > > favourite ASP proxy, for instance). > > > > > > > Neither is assured by the current > > > > draft, I think (haven't checked). > > > > > > UAs should not update their Routes (save noting new Contact > > > addresses); the only thing that proxies continually reinserting > > > Record-Route s buys is recovery after a crash. > > > > > > > The distinction between loose and strict source routing seems to me > > > > useful in understanding the problem, but most of the time a UAC can't > > > > know for sure whether what it's doing is loose or strict. > > > > > > Agreed. The question is: does this really matter if the request > > > visits all the desired proxies in both cases? > > > > > > - Jo. > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Oct 20 11:18:21 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA01042 for ; Fri, 20 Oct 2000 11:18:21 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4C6AE443A9; Fri, 20 Oct 2000 10:13:25 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from drago1.ubiquity.net (unknown [194.202.146.92]) by lists.bell-labs.com (Postfix) with SMTP id C1C2844336 for ; Fri, 20 Oct 2000 04:51:43 -0400 (EDT) Received: from gecko.ubiquity.co.uk by drago1.ubiquity.net via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 20 Oct 2000 09:52:13 UT Received: from phoffer by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id KAA13331; Fri, 20 Oct 2000 10:49:59 +0100 (BST) Message-ID: <003c01c03a7b$01c4b170$5334c3c1@ubiquity.co.uk> From: "Phil Hoffer" To: "Emami-Nouri, Mohsen" Cc: References: <350860CC5B2AD311991D0008C7F7EEAAA02662@exchange.sj.nuera.com> Subject: Re: [SIP] Repost: Use of Record-Route and Contact Headers 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: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 20 Oct 2000 10:49:14 +0100 Content-Transfer-Encoding: 7bit > > Hi, > > > > Table 4 of bis02 states that a Contact header can occur in the following > > response types: > > > > 1xx > > 2xx > > 3xx > > 485 (Ambiguous) > > > > However, Table 5 states that Record-Route can occur in the following > > response types: > > > > 2xx > > 401 (Unauthorized) > > 484 (Address Incomplete) > > > > I don't see how a response can include a Record-Route, if it can't > > contain a Contact. > > I believe that 401 and 484 should be added to the list of response type for > > a Contact header. > > > the following text from bis 6.33 might help better understanding: > > "the UAS copies the record-route request header field unchanged into the > response. (record-route is only relevant for 2xx responses and responses > where the server can expect the client to retry the same call -id as in 401 > or 484" Hi Moshen, Yes I'm aware of the paragraph. My perception is that Record-Route is used to override short cuts in the routing provided by the Contact header. Therefore, if you can expect to receive a Record-Route header in a 401 and a 484 as defined by Table 5 and the stated paragraph, then I'd expect to be able to receive a Contact in a 401 and 484. That is why I'm asking if table 4 needs to be updated. Regards Phil http://www.ubiquity.net _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Oct 20 11:21:33 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA01414 for ; Fri, 20 Oct 2000 11:21:33 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5B60C443AE; Fri, 20 Oct 2000 10:13:39 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lists.bell-labs.com (Postfix) with ESMTP id A92DA44338 for ; Fri, 20 Oct 2000 06:12:32 -0400 (EDT) Received: from ms.uab.ericsson.se (ms.uab.ericsson.se [134.138.201.16]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id e9KBCLt27572; Fri, 20 Oct 2000 13:12:21 +0200 (MEST) Received: from uabs28 (uabs28 [134.138.228.5]) by ms.uab.ericsson.se (8.10.0/8.10.0/uab-2.26) with ESMTP id e9KBCKn07009; Fri, 20 Oct 2000 13:12:20 +0200 (MET DST) Received: from ericsson.com by uabs28 (8.8.8+Sun/client-1.3uab2) id NAA00677; Fri, 20 Oct 2000 13:12:20 +0200 (MET DST) Message-ID: <39F02892.304F353B@ericsson.com> From: Erik Nissen X-Mailer: Mozilla 4.7 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: Chris Harris Cc: mranga@nist.gov, sip@lists.bell-labs.com, discussion@sipforum.org, jainsip@sun.com, jaintech@sun.com Subject: Re: [SIP] JAIN SIP Specification References: <39EB464C.44254E5B@dynamicsoft.com> <00101814092004.10136@gethin> <39EDB3C4.282F1EFA@nist.gov> <39EDBC08.A51790EF@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 20 Oct 2000 13:12:18 +0200 Content-Transfer-Encoding: 7bit Dear fellows, Comment below... > "M. Ranganathan" wrote: > > > I am all for using interfaces as much as > > possible and leaving class hierarchy definitions to implemeters. > > Defining class > > hierarchies almost lays out an implementation and involves > > considerable rework for > > those who have a working java-based stack, but have not used the > > same classes. OK it > > is just a matter of labor to map things to the JAIN-SIP class > > hierarchy but it IS a dis-incentive. > > > > 1. Lets use interfaces for all messages rather than actually define > > class hierarchies ( yes Chris has pointed out the historical > > precedent behind actually > > defining class hierarchies for messages. IMHO, there has to be a > > more compelling reason than that.) > > > > Ranga. > Chris Harris wrote: > > I suppose all classes could be turned into interfaces, except for the > Message classes which must extend java.util.EventObject to fit into > the JAIN framework. > I believe it is possible to decouple the "Message" hierarchy from the EventObject. So that the JAIN-SIP API really is an interface and not an implementation. A MessageEventObject could extend java.util.EventObject and it could have a getMessage() method to return an instance with Message interface. The code could look like this: interface Message { // ... } public class MessageEventObject extends java.util.EventObject { MessageEventObject(Object source, Message message) { super(source); this.message = message; } public Message getMessage() { return message; } private Message message; // ... more about masks for different message types ? } The reason to do a change like this is to *not force* a specific implementation on the API provider. As M. Ranganathan pointed out there could be existing stack implementations, to be mapped. These might even be written in C/C++, in which case the mapping have to be done over Java Native Interface (JNI). I have estimated the construction of a basic InviteMessage to execute 14 JAIN-SIP API specific constructors, and another 13 String constructors (counting the body Object as String). To build a more complete InviteMessage, a number of 'set' methods then need to be invoked. Suppose the you want to reuse objects already constructed by your stack implementation, and/or use late construction of most of these JAIN-SIP specific objects. Thus having a stack which delay constructor execution (and possibly also parsing parts of the SIP message) until the data is requested the first time. I can't see how such optimisations are possible with the current proposal (version 0.6). --- On the other hand, I very much appreciate the work being done in 0.6. So I think we should keep this as a "default" implementation, for example through renaming the current classes from X to X_Impl. The InviteMessage would then be defined as: interface InviteMessage extends Message { // ... } public final class InviteMessage_Impl implements InviteMessage { // current implementation of version 0.6 // kept as a first default implementation } --- By the way, I will not come to the JAIN meeting. Someone else have to argue for interface instead of implementation :-) Best regards /Erik Nissen _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Oct 20 11:56:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA05711 for ; Fri, 20 Oct 2000 11:56:05 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 240064437C; Fri, 20 Oct 2000 10:56:08 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from is1-55.antd.nist.gov (is1-60.antd.nist.gov [129.6.60.251]) by lists.bell-labs.com (Postfix) with ESMTP id 1299F44339 for ; Fri, 20 Oct 2000 10:55:40 -0400 (EDT) Received: from nist.gov (IDENT:mranga@stinkbug.antd.nist.gov [129.6.55.9]) by is1-55.antd.nist.gov (8.9.3/8.9.3) with ESMTP id LAA12390; Fri, 20 Oct 2000 11:51:00 -0400 (EDT) Message-ID: <39F06AF6.267F8F8E@nist.gov> From: "M. Ranganathan" Reply-To: mranga@nist.gov Organization: NIST advanced networking technologies group X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Cc: discussion@sipforum.org, jainsip@sun.com, jaintech@sun.com Subject: Re: [SIPFORUM] Re: [SIP] JAIN SIP Specification References: <39EB464C.44254E5B@dynamicsoft.com> <00101814092004.10136@gethin> <39EDB3C4.282F1EFA@nist.gov> <39EDBC08.A51790EF@dynamicsoft.com> <39F02892.304F353B@ericsson.com> <39F02CF4.95B8B9AB@dynamicsoft.com> Content-Type: multipart/alternative; boundary="------------00E32646DA0796CDB34D02B5" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 20 Oct 2000 11:55:34 -0400 --------------00E32646DA0796CDB34D02B5 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: base64 Hi Chris and Erik, I think Erik's design is elegant and addresses the concern I had so I vote thumbs up for it. Unfortunately, I cannot attend next week either ( could not get the Java Specification Participation Agreement signed as yet (keeping my fingers crossed on that count) ). It appears that Chris is on the same wavelength so there need not be an "argument" anyway :-). Would have enjoyed meeting with you all and hashing out a few issues (such as transaction support) but we have our own stately pace (all puns intended) and I cannot convince anyone at JavaSoft to let me attend without an agreement signed :-( . Ranga. Chris Harris wrote: > Hi Erik, > > That is indeed an excellent proposal, which addresses both the Java event > model and not dictating the form of the implementation. I think we have a > winner here! > > Chris > > Erik Nissen wrote: > > > Dear fellows, > > Comment below... > > > > > "M. Ranganathan" wrote: > > > > > > > I am all for using interfaces as much as > > > > possible and leaving class hierarchy definitions to implemeters. > > > > Defining class > > > > hierarchies almost lays out an implementation and involves > > > > considerable rework for > > > > those who have a working java-based stack, but have not used the > > > > same classes. OK it > > > > is just a matter of labor to map things to the JAIN-SIP class > > > > hierarchy but it IS a dis-incentive. > > > > > > > > 1. Lets use interfaces for all messages rather than actually define > > > > class hierarchies ( yes Chris has pointed out the historical > > > > precedent behind actually > > > > defining class hierarchies for messages. IMHO, there has to be a > > > > more compelling reason than that.) > > > > > > > > Ranga. > > > > > Chris Harris wrote: > > > > > > I suppose all classes could be turned into interfaces, except for the > > > Message classes which must extend java.util.EventObject to fit into > > > the JAIN framework. > > > > > > > I believe it is possible to decouple the "Message" hierarchy from > > the EventObject. So that the JAIN-SIP API really is an interface > > and not an implementation. > > > > A MessageEventObject could extend java.util.EventObject > > and it could have a getMessage() method to return an instance > > with Message interface. > > > > The code could look like this: > > > > interface Message { > > // ... > > } > > > > public class MessageEventObject extends java.util.EventObject { > > > > MessageEventObject(Object source, Message message) { > > super(source); > > this.message = message; > > } > > > > public Message getMessage() { return message; } > > > > private Message message; > > > > // ... more about masks for different message types ? > > } > > > > The reason to do a change like this is to *not force* a specific > > implementation on the API provider. As M. Ranganathan pointed out > > there could be existing stack implementations, to be mapped. > > These might even be written in C/C++, in which case the mapping have > > to be done over Java Native Interface (JNI). > > > > I have estimated the construction of a basic InviteMessage > > to execute 14 JAIN-SIP API specific constructors, > > and another 13 String constructors (counting the body Object as String). > > To build a more complete InviteMessage, a number of 'set' methods > > then need to be invoked. > > > > Suppose the you want to reuse objects already constructed by > > your stack implementation, and/or use late construction of > > most of these JAIN-SIP specific objects. > > Thus having a stack which delay constructor execution > > (and possibly also parsing parts of the SIP message) > > until the data is requested the first time. > > I can't see how such optimisations are possible > > with the current proposal (version 0.6). > > > > --- > > On the other hand, I very much appreciate the work being done in 0.6. > > So I think we should keep this as a "default" implementation, > > for example through renaming the current classes from X to X_Impl. > > > > The InviteMessage would then be defined as: > > > > interface InviteMessage extends Message { > > // ... > > } > > > > public final class InviteMessage_Impl implements InviteMessage > > { > > // current implementation of version 0.6 > > // kept as a first default implementation > > } > > > > --- > > > > By the way, I will not come to the JAIN meeting. > > Someone else have to argue for interface instead of implementation :-) > > > > Best regards > > /Erik Nissen > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip -- M.Ranganathan NIST Advanced Networking Technologies Group, 100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899. Tel: 301 975 3664 Fax: 301 590 0932 --------------00E32646DA0796CDB34D02B5 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit  
Hi  Chris and Erik,

I think Erik's design is elegant and addresses the concern I had so  I vote thumbs up  for it.

Unfortunately, I cannot attend next week either  ( could not get the Java Specification  Participation Agreement signed as yet  (keeping my fingers crossed  on that count) ).  It appears that Chris is on the same wavelength so there need not be an "argument"  anyway :-).   Would have  enjoyed meeting with you all  and hashing out a few issues (such as transaction support)  but we have our own stately pace (all puns intended)   and I cannot convince anyone at JavaSoft to let me attend  without an agreement  signed :-(  .

Ranga.
 

Chris Harris wrote:

Hi Erik,

That is indeed an excellent proposal, which addresses both the Java event
model and not dictating the form of the implementation. I think we have a
winner here!

Chris

Erik Nissen wrote:

> Dear fellows,
> Comment below...
>
> > "M. Ranganathan" wrote:
> >
> > > I am all for using interfaces as much as
> > > possible and leaving class hierarchy definitions to implemeters.
> > > Defining class
> > > hierarchies almost lays out an implementation and involves
> > > considerable rework for
> > > those who have a working java-based stack, but have not used the
> > > same classes. OK it
> > > is just a matter of labor to map things to the JAIN-SIP class
> > > hierarchy but it  IS a dis-incentive.
> > >
> > > 1. Lets use interfaces for all messages rather than actually define
> > > class hierarchies  ( yes Chris has pointed out the historical
> > > precedent behind actually
> > > defining class hierarchies for messages. IMHO,  there has to be a
> > > more compelling reason than that.)
> > >
> > > Ranga.
>
> > Chris Harris wrote:
> >
> > I suppose all classes could be turned into interfaces, except for the
> > Message classes which must extend java.util.EventObject to fit into
> > the JAIN framework.
> >
>
> I believe it is possible to decouple the "Message" hierarchy from
> the EventObject. So that the JAIN-SIP API really is an interface
> and not an implementation.
>
> A MessageEventObject could extend java.util.EventObject
> and it could have a getMessage() method to return an instance
> with Message interface.
>
> The code could look like this:
>
>    interface Message {
>       // ...
>    }
>
>    public class MessageEventObject extends java.util.EventObject {
>
>       MessageEventObject(Object source, Message message) {
>          super(source);
>          this.message = message;
>       }
>
>       public Message getMessage() { return message; }
>
>       private Message message;
>
>       // ... more about masks for different message types ?
>    }
>
> The reason to do a change like this is to *not force* a specific
> implementation on the API provider. As M. Ranganathan pointed out
> there could be existing stack implementations, to be mapped.
> These might even be written in C/C++, in which case the mapping have
> to be done over Java Native Interface (JNI).
>
> I have estimated the construction of a basic InviteMessage
> to execute 14 JAIN-SIP API specific constructors,
> and another 13 String constructors (counting the body Object as String).
> To build a more complete InviteMessage, a number of 'set' methods
> then need to be invoked.
>
> Suppose the you want to reuse objects already constructed by
> your stack implementation, and/or use late construction of
> most of these JAIN-SIP specific objects.
> Thus having a stack which delay constructor execution
> (and possibly also parsing parts of the SIP message)
> until the data is requested the first time.
> I can't see how such optimisations are possible
> with the current proposal (version 0.6).
>
> ---
> On the other hand, I very much appreciate the work being done in 0.6.
> So I think we should keep this as a "default" implementation,
> for example through renaming the current classes from X to X_Impl.
>
> The InviteMessage would then be defined as:
>
> interface InviteMessage extends Message {
>    // ...
> }
>
> public final class InviteMessage_Impl implements InviteMessage
> {
>    // current implementation of version 0.6
>    // kept as a first default implementation
> }
>
> ---
>
> By the way, I will not come to the JAIN meeting.
> Someone else have to argue for interface instead of implementation :-)
>
> Best regards
> /Erik Nissen

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip

-- 
M.Ranganathan
NIST Advanced Networking Technologies Group,
100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899. 
Tel: 301 975 3664 Fax: 301 590 0932
  --------------00E32646DA0796CDB34D02B5-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Oct 20 12:49:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA12619 for ; Fri, 20 Oct 2000 12:49:02 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 593AA4433A; Fri, 20 Oct 2000 11:49:04 -0400 (EDT) Delivered-To: sip@share.research.bell-labs.com Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by lists.bell-labs.com (Postfix) with SMTP id 15119443B4 for ; Fri, 20 Oct 2000 10:28:08 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Fri Oct 20 11:26:42 EDT 2000 Received: by lists.bell-labs.com (Postfix) id D22F844380; Fri, 20 Oct 2000 11:13:33 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ans.ih.lucent.com (ans.ih.lucent.com [135.2.78.5]) by lists.bell-labs.com (Postfix) with SMTP id 85B134437D for ; Fri, 20 Oct 2000 11:13:33 -0400 (EDT) Received: by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id KAA10394; Fri, 20 Oct 2000 10:13:29 -0500 Cc: "'Piotr S. Kossowski'" , sip@lists.bell-labs.com Received: from lucent.com by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id KAA10361; Fri, 20 Oct 2000 10:13:25 -0500 Message-ID: <39F0629B.2D56031B@lucent.com> From: "Vijay K. Gurbani" Organization: Intelligent Network and Internet Software Group X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-6.1.1 i686) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Original-CC: "'Piotr S. Kossowski'" , sip@lists.bell-labs.com Subject: Re: [SIP] Multi-message UDP datagrams References: Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 20 Oct 2000 10:19:55 -0500 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > It was my view that receiving multiple messages in a single datagram was the > same as if they were received in separate datagrams. In other words, there > was no requirements for ordering or completion. The result of that was a > simplification in the implementation of handling this case; UDP works just > like TCP. Imposing transactional requirements adds significant burden. I'd > rather not do that unless there was serious requirements or needs here. > > In fact, I would argue that multiple messages per datagram might be > something to consider for removal. I've never seen it used. I'm not sure > what the benefit is, in reality. There is little byte savings, and its just > more complexity that is really needless. > > Lets simplify, not complicate. [...] For whatever it is worth, I agree. In the bakeoff scenarios, I have never seen a SIP entity send multiple messages in the same datagram. Regards, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Internet Software/IN Architecture Group Lucent Technologies/Bell Labs Innovations 263 Shuman Blvd., Rm 1A-413 Naperville, Illinois 60566 Voice: +1 630 224 0216 Fax: +1 630 713 0184 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Oct 20 12:51:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA12943 for ; Fri, 20 Oct 2000 12:51:03 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id AF1AA44344; Fri, 20 Oct 2000 11:51:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from elektron.elka.pw.edu.pl (elektron.elka.pw.edu.pl [194.29.160.2]) by lists.bell-labs.com (Postfix) with ESMTP id B0C0E44339 for ; Fri, 20 Oct 2000 11:50:46 -0400 (EDT) Received: from po129.warszawa.cvx.ppp.tpnet.pl ([213.76.110.129]:4170 "EHLO elka.pw.edu.pl") by elektron.elka.pw.edu.pl with ESMTP id ; Fri, 20 Oct 2000 18:50:24 +0200 Message-ID: <39F077DF.8DE6E15F@elka.pw.edu.pl> From: "Piotr S. Kossowski" Organization: Warsaw University of Technology - Institute of Telecommunications X-Mailer: Mozilla 4.7 [pl] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "Vijay K. Gurbani" Cc: Jonathan Rosenberg , sip@lists.bell-labs.com Subject: Re: [SIP] Multi-message UDP datagrams References: <39F0629B.2D56031B@lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 20 Oct 2000 18:50:39 +0200 Content-Transfer-Encoding: 7bit "Vijay K. Gurbani" wrote: > > For whatever it is worth, I agree. In the bakeoff scenarios, I have > never > seen a SIP entity send multiple messages in the same datagram. > To be honest, I also don't see an important reason for sending multiple messages in the same datagram. But I wasn't interested in client side. I only wondered what would happen if a server got these messages in the same datagram, somehow. And RFC foresee such situation, because says: "process everything" instead of "truncate after first processed message from datagram"... Regards, Piotr _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Oct 20 13:10:06 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA15195 for ; Fri, 20 Oct 2000 13:10:06 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id AAD2D44352; Fri, 20 Oct 2000 12:10:08 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 363ED44352 for ; Fri, 20 Oct 2000 12:09:17 -0400 (EDT) Received: from dynamicsoft.com (userac22.ie.uudial.com [212.120.133.221]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id NAA20010; Fri, 20 Oct 2000 13:11:18 -0400 (EDT) Message-ID: <39F07C4A.B41E997B@dynamicsoft.com> From: Chris Harris Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: mranga@nist.gov Cc: sip@lists.bell-labs.com, discussion@sipforum.org, jainsip@sun.com, jaintech@sun.com Subject: Re: [SIPFORUM] Re: [SIP] JAIN SIP Specification References: <39EB464C.44254E5B@dynamicsoft.com> <00101814092004.10136@gethin> <39EDB3C4.282F1EFA@nist.gov> <39EDBC08.A51790EF@dynamicsoft.com> <39F02892.304F353B@ericsson.com> <39F02CF4.95B8B9AB@dynamicsoft.com> <39F06AF6.267F8F8E@nist.gov> Content-Type: multipart/alternative; boundary="------------D2DBCBA22D49CDBE5C9AD7E8" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 20 Oct 2000 18:09:30 +0100 --------------D2DBCBA22D49CDBE5C9AD7E8 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Ranga, I've already started on a version with interfaces instead of classes - it is making inheritance based on the content of headers easier, and the need for interfaces for each type of request has vanished (since there are no constructors defined). It's looking good so far - thanks Erik! I would definitely like to see you at the meeting - but if you can't attend I will do my utmost to represent your views on Tuesday! Chris "M. Ranganathan" wrote: > > Hi Chris and Erik, > > I think Erik's design is elegant and addresses the concern I had so I > vote thumbs up for it. > > Unfortunately, I cannot attend next week either ( could not get the > Java Specification Participation Agreement signed as yet (keeping my > fingers crossed on that count) ). It appears that Chris is on the > same wavelength so there need not be an "argument" anyway :-). > Would have enjoyed meeting with you all and hashing out a few issues > (such as transaction support) but we have our own stately pace (all > puns intended) and I cannot convince anyone at JavaSoft to let me > attend without an agreement signed :-( . > > Ranga. > > > Chris Harris wrote: > >> Hi Erik, >> >> That is indeed an excellent proposal, which addresses both the Java >> event >> model and not dictating the form of the implementation. I think we >> have a >> winner here! >> >> Chris >> >> Erik Nissen wrote: >> >> > Dear fellows, >> > Comment below... >> > >> > > "M. Ranganathan" wrote: >> > > >> > > > I am all for using interfaces as much as >> > > > possible and leaving class hierarchy definitions to >> implemeters. >> > > > Defining class >> > > > hierarchies almost lays out an implementation and involves >> > > > considerable rework for >> > > > those who have a working java-based stack, but have not used >> the >> > > > same classes. OK it >> > > > is just a matter of labor to map things to the JAIN-SIP class >> > > > hierarchy but it IS a dis-incentive. >> > > > >> > > > 1. Lets use interfaces for all messages rather than actually >> define >> > > > class hierarchies ( yes Chris has pointed out the historical >> > > > precedent behind actually >> > > > defining class hierarchies for messages. IMHO, there has to >> be a >> > > > more compelling reason than that.) >> > > > >> > > > Ranga. >> > >> > > Chris Harris wrote: >> > > >> > > I suppose all classes could be turned into interfaces, except >> for the >> > > Message classes which must extend java.util.EventObject to fit >> into >> > > the JAIN framework. >> > > >> > >> > I believe it is possible to decouple the "Message" hierarchy from >> > the EventObject. So that the JAIN-SIP API really is an interface >> > and not an implementation. >> > >> > A MessageEventObject could extend java.util.EventObject >> > and it could have a getMessage() method to return an instance >> > with Message interface. >> > >> > The code could look like this: >> > >> > interface Message { >> > // ... >> > } >> > >> > public class MessageEventObject extends java.util.EventObject { >> >> > >> > MessageEventObject(Object source, Message message) { >> > super(source); >> > this.message = message; >> > } >> > >> > public Message getMessage() { return message; } >> > >> > private Message message; >> > >> > // ... more about masks for different message types ? >> > } >> > >> > The reason to do a change like this is to *not force* a specific >> > implementation on the API provider. As M. Ranganathan pointed out >> > there could be existing stack implementations, to be mapped. >> > These might even be written in C/C++, in which case the mapping >> have >> > to be done over Java Native Interface (JNI). >> > >> > I have estimated the construction of a basic InviteMessage >> > to execute 14 JAIN-SIP API specific constructors, >> > and another 13 String constructors (counting the body Object as >> String). >> > To build a more complete InviteMessage, a number of 'set' methods >> > then need to be invoked. >> > >> > Suppose the you want to reuse objects already constructed by >> > your stack implementation, and/or use late construction of >> > most of these JAIN-SIP specific objects. >> > Thus having a stack which delay constructor execution >> > (and possibly also parsing parts of the SIP message) >> > until the data is requested the first time. >> > I can't see how such optimisations are possible >> > with the current proposal (version 0.6). >> > >> > --- >> > On the other hand, I very much appreciate the work being done in >> 0.6. >> > So I think we should keep this as a "default" implementation, >> > for example through renaming the current classes from X to X_Impl. >> >> > >> > The InviteMessage would then be defined as: >> > >> > interface InviteMessage extends Message { >> > // ... >> > } >> > >> > public final class InviteMessage_Impl implements InviteMessage >> > { >> > // current implementation of version 0.6 >> > // kept as a first default implementation >> > } >> > >> > --- >> > >> > By the way, I will not come to the JAIN meeting. >> > Someone else have to argue for interface instead of implementation >> :-) >> > >> > Best regards >> > /Erik Nissen >> >> _______________________________________________ >> SIP mailing list >> SIP@lists.bell-labs.com >> http://lists.bell-labs.com/mailman/listinfo/sip > > -- > M.Ranganathan > NIST Advanced Networking Technologies Group, > 100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899. > Tel: 301 975 3664 Fax: 301 590 0932 > > --------------D2DBCBA22D49CDBE5C9AD7E8 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Ranga,

I've already started on a version with interfaces instead of classes - it is making inheritance based on the content of headers easier, and the need for interfaces for each type of request has vanished (since there are no constructors defined). It's looking good so far - thanks Erik!

I would definitely like to see you at the meeting - but if you can't attend I will do my utmost to represent your views on Tuesday!

Chris
 

"M. Ranganathan" wrote:

 
Hi  Chris and Erik,

I think Erik's design is elegant and addresses the concern I had so  I vote thumbs up  for it.

Unfortunately, I cannot attend next week either  ( could not get the Java Specification  Participation Agreement signed as yet  (keeping my fingers crossed  on that count) ).  It appears that Chris is on the same wavelength so there need not be an "argument"  anyway :-).   Would have  enjoyed meeting with you all  and hashing out a few issues (such as transaction support)  but we have our own stately pace (all puns intended)   and I cannot convince anyone at JavaSoft to let me attend  without an agreement  signed :-(  .

Ranga.
 

Chris Harris wrote:

Hi Erik,

That is indeed an excellent proposal, which addresses both the Java event
model and not dictating the form of the implementation. I think we have a
winner here!

Chris

Erik Nissen wrote:

> Dear fellows,
> Comment below...
>
> > "M. Ranganathan" wrote:
> >
> > > I am all for using interfaces as much as
> > > possible and leaving class hierarchy definitions to implemeters.
> > > Defining class
> > > hierarchies almost lays out an implementation and involves
> > > considerable rework for
> > > those who have a working java-based stack, but have not used the
> > > same classes. OK it
> > > is just a matter of labor to map things to the JAIN-SIP class
> > > hierarchy but it  IS a dis-incentive.
> > >
> > > 1. Lets use interfaces for all messages rather than actually define
> > > class hierarchies  ( yes Chris has pointed out the historical
> > > precedent behind actually
> > > defining class hierarchies for messages. IMHO,  there has to be a
> > > more compelling reason than that.)
> > >
> > > Ranga.
>
> > Chris Harris wrote:
> >
> > I suppose all classes could be turned into interfaces, except for the
> > Message classes which must extend java.util.EventObject to fit into
> > the JAIN framework.
> >
>
> I believe it is possible to decouple the "Message" hierarchy from
> the EventObject. So that the JAIN-SIP API really is an interface
> and not an implementation.
>
> A MessageEventObject could extend java.util.EventObject
> and it could have a getMessage() method to return an instance
> with Message interface.
>
> The code could look like this:
>
>    interface Message {
>       // ...
>    }
>
>    public class MessageEventObject extends java.util.EventObject {
>
>       MessageEventObject(Object source, Message message) {
>          super(source);
>          this.message = message;
>       }
>
>       public Message getMessage() { return message; }
>
>       private Message message;
>
>       // ... more about masks for different message types ?
>    }
>
> The reason to do a change like this is to *not force* a specific
> implementation on the API provider. As M. Ranganathan pointed out
> there could be existing stack implementations, to be mapped.
> These might even be written in C/C++, in which case the mapping have
> to be done over Java Native Interface (JNI).
>
> I have estimated the construction of a basic InviteMessage
> to execute 14 JAIN-SIP API specific constructors,
> and another 13 String constructors (counting the body Object as String).
> To build a more complete InviteMessage, a number of 'set' methods
> then need to be invoked.
>
> Suppose the you want to reuse objects already constructed by
> your stack implementation, and/or use late construction of
> most of these JAIN-SIP specific objects.
> Thus having a stack which delay constructor execution
> (and possibly also parsing parts of the SIP message)
> until the data is requested the first time.
> I can't see how such optimisations are possible
> with the current proposal (version 0.6).
>
> ---
> On the other hand, I very much appreciate the work being done in 0.6.
> So I think we should keep this as a "default" implementation,
> for example through renaming the current classes from X to X_Impl.
>
> The InviteMessage would then be defined as:
>
> interface InviteMessage extends Message {
>    // ...
> }
>
> public final class InviteMessage_Impl implements InviteMessage
> {
>    // current implementation of version 0.6
>    // kept as a first default implementation
> }
>
> ---
>
> By the way, I will not come to the JAIN meeting.
> Someone else have to argue for interface instead of implementation :-)
>
> Best regards
> /Erik Nissen

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip

-- 
M.Ranganathan
NIST Advanced Networking Technologies Group,
100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899. 
Tel: 301 975 3664 Fax: 301 590 0932
 
--------------D2DBCBA22D49CDBE5C9AD7E8-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Oct 20 13:55:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA20353 for ; Fri, 20 Oct 2000 13:55:03 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 87DA14433A; Fri, 20 Oct 2000 12:55:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from pigeon.vovida.com (a98.vovida.com [209.237.8.98]) by lists.bell-labs.com (Postfix) with ESMTP id 6EC7244339 for ; Fri, 20 Oct 2000 12:54:41 -0400 (EDT) Received: from vovida.com ([209.237.8.113]) by pigeon.vovida.com (Netscape Messaging Server 4.15) with ESMTP id G2QPDF00.E5F; Fri, 20 Oct 2000 10:46:27 -0700 Message-ID: <39F086D0.380F6B7D@vovida.com> From: Sunitha Kumar Organization: Vovida Networks X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14 i686) X-Accept-Language: en MIME-Version: 1.0 To: Mark Wisdom Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Digest Authentication References: Content-Type: multipart/alternative; boundary="------------87D7D996E3F4A412391233A4" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 20 Oct 2000 10:54:24 -0700 --------------87D7D996E3F4A412391233A4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mark: With respect to your question about mutual authentication, maybe PGP could be considered as the way to go. Using PGP, the server can authenticate the client, and the client could verify that this is the server. Using Digest for mutual authentication may require 2 independent msgs to go from the server to client and client to server, each sending each other their generated nonces, and the other forming the digest with that nonce. Just my 2c. sunitha Mark Wisdom wrote: > I need some clarification on, and help with, digest authentication. > > rfc2617, section 3.2.1 states: > > > A nonce might, for example, be constructed as the base 64 > > encoding of > > > > time-stamp H(time-stamp ":" ETag ":" private-key) > > Then in section 4.5 it states: > > > The server created "nonce" value is implementation dependent, > > but if it contains a digest of the client IP, a time-stamp, > > the resource ETag, and a private server key (as recommended > > above) then a replay attack is not simple. > > rfc2543bis-02, section 14.3 states: > > > 4. The example procedure for choosing a nonce based on Etag > > does not work for SIP. > > It would be nice if rfc2543 provided an alternate example for > creating a nonce. Can this be added to the rfc2543? > > Does anyone have any guidelines on creating a nonce for use > with digest authentication? > > rfc2543bis-02, section 14.3 also states: > > > 5. The Authentication-Info and Proxy-Authentication-Info > > fields are not used in SIP. > > If I understand correctly, not allowing the Authentication-Info > header eliminates support for mutual authenication (i.e. > allowing the server to also authenticate itself to the client > by proving to the client that it knows the client's secret). > > Does SIP allow for mutual authentication when using digest > authentication? > > If not, can we modify rfc2543 so that mutual authentication is > possible? > > Thanks, > Mark Wisdom > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip -- Sunitha Kumar http://www.vovida.com --------------87D7D996E3F4A412391233A4 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Mark:

With respect to your question about mutual authentication, maybe PGP could be considered as the way to go.
Using PGP, the server can authenticate the client, and the client could verify that this is the server.

Using Digest for mutual authentication may require 2 independent msgs to go from the server to client and client to server,
each sending each other their generated nonces, and the other forming the digest with that nonce.

Just my 2c.

sunitha
 
 
 

Mark Wisdom wrote:

I need some clarification on, and help with, digest authentication.

rfc2617, section 3.2.1 states:

> A nonce might, for example, be constructed as the base 64
> encoding of
>
>     time-stamp H(time-stamp ":" ETag ":" private-key)

Then in section 4.5 it states:

> The server created "nonce" value is implementation dependent,
> but if it contains a digest of the client IP, a time-stamp,
> the resource ETag, and a private server key (as recommended
> above) then a replay attack is not simple.

rfc2543bis-02, section 14.3 states:

> 4. The example procedure for choosing a nonce based on Etag
>    does not work for SIP.

It would be nice if rfc2543 provided an alternate example for
creating a nonce. Can this be added to the rfc2543?

Does anyone have any guidelines on creating a nonce for use
with digest authentication?

rfc2543bis-02, section 14.3 also states:

> 5. The Authentication-Info and Proxy-Authentication-Info
>    fields are not used in SIP.

If I understand correctly, not allowing the Authentication-Info
header eliminates support for mutual authenication (i.e.
allowing the server to also authenticate itself to the client
by proving to the client that it knows the client's secret).

Does SIP allow for mutual authentication when using digest
authentication?

If not, can we modify rfc2543 so that mutual authentication is
possible?

Thanks,
Mark Wisdom

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip

-- 
Sunitha Kumar
http://www.vovida.com
  --------------87D7D996E3F4A412391233A4-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Oct 20 15:55:08 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA08593 for ; Fri, 20 Oct 2000 15:55:07 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8FB834433C; Fri, 20 Oct 2000 14:55:07 -0400 (EDT) Delivered-To: sip@share.research.bell-labs.com Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by lists.bell-labs.com (Postfix) with SMTP id 2BCC144342 for ; Fri, 20 Oct 2000 13:18:13 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by dirty; Fri Oct 20 14:17:37 EDT 2000 Received: by lists.bell-labs.com (Postfix) id A33F044380; Fri, 20 Oct 2000 14:04:28 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ans.ih.lucent.com (ans.ih.lucent.com [135.2.78.5]) by lists.bell-labs.com (Postfix) with SMTP id 615FF4437D for ; Fri, 20 Oct 2000 14:04:28 -0400 (EDT) Received: by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id NAA13064; Fri, 20 Oct 2000 13:04:24 -0500 Cc: sip@lists.bell-labs.com, schulzrinne@cs.columbia.edu Received: from lucent.com by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id NAA13021; Fri, 20 Oct 2000 13:04:22 -0500 Message-ID: <39F08922.CA56A0ED@lucent.com> From: "Vijay K. Gurbani" Reply-To: vkg@lucent.com Organization: Intelligent Network/Messaging Systems & Internet Software Group X-Mailer: Mozilla 4.61 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Original-CC: sip@lists.bell-labs.com, schulzrinne@cs.columbia.edu References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] Re: CANCEL - response sequence issue (again) Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 20 Oct 2000 13:04:18 -0500 Content-Transfer-Encoding: 7bit Dr. Schulzrinne: Would it be possible to add what Jonathan Rosenberg suggests below for backward compatibility in a CANCEL/200 OK/487 Request Terminated scenario. This appears to be the cleanest solution. I had thought that we could get something better by NOT having the UAS respond with a 200 OK when it gets a CANCEL cancelling a request for which it has already send a final response. However, on closer inspection, this may not buy us much (I can share the analysis with whoever is interested). I was trying to avoid choosing a timeout value for X (see attachment below) -- but no avail, the timeout will be needed to clean up transaction state. Thanks, - vijay Jonathan Rosenberg wrote: > > > -----Original Message----- > > From: Vijay K. Gurbani [mailto:vkg@lucent.com] > > Sent: Tuesday, October 17, 2000 7:49 PM > > Subject: CANCEL - response sequence issue (again) > > > > Now, if we have a UAC (actual UAC or a virtual UAC branch on a proxy) > > that's coded according to the new bis but dealing with a UAS that's > > coded according to the original RFC, the order of delivery suddenly > > becomes important if the UAC wants to clean state correctly. > > > > Consider a UAC coded to the bis spec dealing with an old UAS coded to > > the RFC 2543 spec. If the UAC sends a CANCEL, it will only > > get the 200 > > OK (CSeq: xxx CANCEL). So, it is done with the CANCEL/200 OK > > transaction. But it will never get the 487 Request > > Terminated response > > for it's original INVITE. The UAC will not retransmit the > > INVITE (since > > it got the provisional responses), leading to inconsistent > > call state in > > the UAC. > > > > I think the bis should, in section 4.2.5 stress that, "...If > > the server > > has not issued a final response for the original request, it > > immediately > > sends a 487 Request Terminated for the original request. The UAC > > confirms receipt of any final response for the original request as > > normal with an ACK request. CANCEL request is answered with a 200 OK > > response in either case after the original transaction has completed." > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > My suggested wordings; please re-word > > if needed > > No. Counting on order is a dangerous thing. Lets say a real final response > was sent, and then a CANCEL is received (crossing the final response on the > wire). The CANCEL is received, and responded to with a 200 OK. This 200 OK, > and the final response to the request, are received in the opposite order at > the client. The result is that the client thinks there won't be a response > to the original request, even though there is. > > The correct solution is that you cannot *depend* on the receipt of 487 to > terminate the original transaction. You need to have a timeout which, after > sending CANCEL, terminates the transaction if no final response is received > before some X seconds. X can be fairly small, since either you will get a > final response right away (modulo some packet loss), in the case of bis > proxies, or never. We have this timer set to something like 5 or 6 seconds. > > I do think the spec needs to talk about this. In fact, I recall that it was > raised on the list previously. > > I would rather say: > > For backwards compatibility with RFC2543, UACs and proxies which generate > \CANCEL \MUSTNOT assume that a 487 response to the original transaction will > be received. Instead, they \SHOULD set a timer upon sending \CANCEL, and > terminate the transaction if not response to the original request is > received after X seconds. > > Now, the question is: what value for X? To deal with worst case network > losses, it could be as large as 32 seconds, but that results in very slow > timeouts. > > -Jonathan R. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Oct 20 17:12:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA01074 for ; Fri, 20 Oct 2000 17:12:02 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 389104433A; Fri, 20 Oct 2000 16:12:05 -0400 (EDT) Delivered-To: sip@share.research.bell-labs.com Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by lists.bell-labs.com (Postfix) with SMTP id 2FBF544339 for ; Fri, 20 Oct 2000 15:58:06 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Fri Oct 20 16:57:22 EDT 2000 Received: by lists.bell-labs.com (Postfix) id E57AE44380; Fri, 20 Oct 2000 16:44:12 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by lists.bell-labs.com (Postfix) with ESMTP id C1FD74437D for ; Fri, 20 Oct 2000 16:44:12 -0400 (EDT) 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 QAA18716 for ; Fri, 20 Oct 2000 16:44:12 -0400 (EDT) Message-ID: <39F0AEC1.7CC0D107@cs.columbia.edu> From: Henning Schulzrinne X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] SIP web page Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 20 Oct 2000 16:44:49 -0400 Content-Transfer-Encoding: 7bit Just a minor SIP popularity statistic: The SIP front page today passed the 100,000 hit mark (since I started counting in June 2000). Daily average is 736 visitors. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Oct 20 18:12:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA17146 for ; Fri, 20 Oct 2000 18:12:05 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E1CF244342; Fri, 20 Oct 2000 17:12:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cvis29.marconicomms.com (cvis29.marconicomms.com [195.99.244.61]) by lists.bell-labs.com (Postfix) with ESMTP id 3156F44339 for ; Fri, 20 Oct 2000 17:11:59 -0400 (EDT) Received: from cvis01.gpt.co.uk (unverified) by cvis29.marconicomms.com (Content Technologies SMTPRS 4.1.5) with ESMTP id ; Fri, 20 Oct 2000 17:21:47 +0100 Received: from marconicomms.com by cvis01.gpt.co.uk with SMTP (8.8.8+Sun/cvms-28) id RAA15720; Fri, 20 Oct 2000 17:21:47 +0100 (BST) Received: by marconicomms.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 8025697E.0059D7A3 ; Fri, 20 Oct 2000 17:21:19 +0100 X-Lotus-FromDomain: MCMAIN@MCEXT From: "Keith Robinson" To: Gonzalo Camarillo Cc: Anders Kristensen , sean.olson@ericsson.com, Jo Hornsby , SIP Message-ID: <8025697E.004E196D.00@marconicomms.com> Subject: Re: Source Routing WAS Re: [SIP] Route learnt out of band Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 20 Oct 2000 15:12:58 +0100 One issue I can think. In an initial INVITE, the TO: tag will be blank (no call leg set up yet), in a re-INVITE the TO: tag will not be blank. As a re-INVITE therefore appears to be distinguishable from an initial INVITE a strict proxy may well accept the ROUTE: header on a re-INVITE but not on an initial INVITE. Thanks K. Robinson _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Oct 20 18:17:20 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA18259 for ; Fri, 20 Oct 2000 18:17:20 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3704544362; Fri, 20 Oct 2000 17:14:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from illyana.qualcomm.com (illyana.qualcomm.com [129.46.2.83]) by lists.bell-labs.com (Postfix) with ESMTP id 8092B4436F for ; Fri, 20 Oct 2000 17:13:19 -0400 (EDT) Received: from localhost (mwisdom@localhost) by illyana.qualcomm.com (8.9.3/8.9.3/1.0) with ESMTP id PAA02092; Fri, 20 Oct 2000 15:13:14 -0700 (PDT) From: Mark Wisdom To: sip@lists.bell-labs.com, Sunitha Kumar In-Reply-To: <39F086D0.380F6B7D@vovida.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [SIP] Mutual Authentication (was: Digest Authentication) Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 20 Oct 2000 15:13:14 -0700 (PDT) On Fri, 20 Oct 2000, Sunitha Kumar wrote: > With respect to your question about mutual authentication, maybe > PGP could be considered as the way to go. > Using PGP, the server can authenticate the client, and the client > could verify that this is the server. I think that PGP authentication is great. However I am not aware that it simplifies mutual authentication. From my understanding, in order to accomplish mutual authentication with PGP, the server would need to know the client's public PGP key, and the client would need to know the server's PGP key. Having said this, I am not aware of a standardized mechanism within SIP to authenicate the server to the client using PGP. > Using Digest for mutual authentication may require 2 independent > msgs to go from the server to client and client to server, each > sending each other their generated nonces, and the other forming > the digest with that nonce. *If* SIP allows for mutual authentication using digest, then the number of messages needed to be exchanged to accomplish mutual authenication would be no different than the number of messages needed to accomplish only client authentication to the server. Here is the message flow: Client Server INVITE ----------------> 401 Unauthorized (includes WWW-Authenticate header with a nonce field) <---------------- ACK ----------------> INVITE (includes Authorization header with a cnonce field) ----------------> 200 OK (includes Authentication-Info header a rspauth field) <---------------- ACK (includes Authorization header) ----------------> Currently SIP does not allow for the Authentication-Info header (see rfc2543bis-02, section 14.3, bullet 5) thus the above example is not possible (at least as I understand it), but that is how I envision that it would be done. In the above example the server would compute the rspauth digest value using the client's secret and the client supplied nonce (cnonce), thus proving to the client that it knows its secret. Mark Wisdom _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Oct 20 20:18:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA16482 for ; Fri, 20 Oct 2000 20:18:03 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 02C3C4433A; Fri, 20 Oct 2000 19:18:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from elektron.elka.pw.edu.pl (elektron.elka.pw.edu.pl [194.29.160.2]) by lists.bell-labs.com (Postfix) with ESMTP id 3CE7544339 for ; Fri, 20 Oct 2000 19:17:23 -0400 (EDT) Received: from dial-barska24.warman.com.pl ([195.164.232.25]:1038 "EHLO elka.pw.edu.pl") by elektron.elka.pw.edu.pl with ESMTP id ; Sat, 21 Oct 2000 02:16:59 +0200 Message-ID: <39F0E026.D182AAA8@elka.pw.edu.pl> From: "Piotr S. Kossowski" Organization: Warsaw University of Technology - Institute of Telecommunications X-Mailer: Mozilla 4.7 [pl] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] Multiple responses for single INVITE Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sat, 21 Oct 2000 02:15:34 +0200 Content-Transfer-Encoding: 7bit Hello, Section 11.3 of rfc2543bis-02 says: "Multiple responses may arrive at the UAC for a single INVITE request, (...) The caller MAY choose to acknowledge or terminate the call with each responding UAS. To acknowledge, it sends an ACK request, and to terminate it sends a BYE request." Section 4.2.5 says: "The BYE request cannot be used to cancel branches of a parallel search, since several branches may, through intermediate proxies, find the same user agent server and then terminate the call.(...)" There are two issues that are not clear for me: 1. Aren't there any discrepancy in these two sections (I mean BYE usage)? 2. If the spec says that multiple response can arrive at the UAC for a single INVITE, there should be at least two ways of behaviour, to my mind: a. UAC wait a while (e.g. 5 second) after getting first final response to INVITE. If there is no next response (from other UAS), UAC sends ACK to this INVITE and desctructs its socket. If there are responses during this time, UAC shows to user a list of servers that replied and allows to decide what to do with them (either accept (ACK) or not (BYE)) The question is: how much time should it wait for reponses from network ? b. UAC sends ACK imediately after getting first 200 resp, destructs its port and there is no chance for getting other responses at all (destructed port was put in Via, of course). We lost responses from other servers, but we are happy, beacuse our callee accepted a call. a. and b. situations are completly different. Which one is correct (if any is) ? Regards, Piotr _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sat Oct 21 05:35:07 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA25917 for ; Sat, 21 Oct 2000 05:35:06 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D78104433A; Sat, 21 Oct 2000 04:35:06 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lists.bell-labs.com (Postfix) with ESMTP id DA20544339 for ; Sat, 21 Oct 2000 04:34:19 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id e9L9YCZ27603; Sat, 21 Oct 2000 11:34:12 +0200 (MEST) Received: from lmf.ericsson.se (E005004B57366.lmf.ericsson.se [131.160.30.12]) by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id MAA14672; Sat, 21 Oct 2000 12:34:11 +0300 (EET DST) Message-ID: <39F16305.5297FEC4@lmf.ericsson.se> From: Gonzalo Camarillo X-Mailer: Mozilla 4.74 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Keith Robinson Cc: Anders Kristensen , sean.olson@ericsson.com, Jo Hornsby , SIP Subject: Re: Source Routing WAS Re: [SIP] Route learnt out of band References: <8025697E.004E196D.00@marconicomms.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sat, 21 Oct 2000 12:33:57 +0300 Content-Transfer-Encoding: 7bit Hi, A general advice given in the bake-offs is that implementing this kind of "picky" or strict proxy is a bad idea. If the proxy has all the necessary information to route the INVITE, why should it lose its time double-checking the message grammar trying to discover odd combination of events (e.g. This message has a Route but no a tag in the To... let's discard the message instead of route it)? A proxy should be concern with the headers that it has to use in order to perform its task. Once it has the information needed to route the message, the best approach is routing the message straight away. This is one of the good things of SIP, and that's why proxies do not parse the message body, for instance. "Be strict when sending and tolerant when receiving." Thanks for your feedback, Gonzalo Keith Robinson wrote: > > One issue I can think. In an initial INVITE, the TO: tag will be blank (no call > leg set up yet), in a re-INVITE the TO: tag will not be blank. As a re-INVITE > therefore appears to be distinguishable from an initial INVITE a strict proxy > may well accept the ROUTE: header on a re-INVITE but not on an initial INVITE. > > Thanks > K. Robinson > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sun Oct 22 11:23:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA04326 for ; Sun, 22 Oct 2000 11:23:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1C0D84433A; Sun, 22 Oct 2000 10:23:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from guardian1.tlv.radvision.com (unknown [212.143.185.30]) by lists.bell-labs.com (Postfix) with ESMTP id 9997344339 for ; Sun, 22 Oct 2000 10:22:35 -0400 (EDT) Received: from nt-mail.tlv.radvision.com ([172.20.2.100]) by guardian1.tlv.radvision.com (Post.Office MTA v3.5.3 release 223 ID# 0-0U10L2S100V35) with ESMTP id com; Sun, 22 Oct 2000 18:21:14 +0200 Received: by NT-MAIL with Internet Mail Service (5.5.2650.21) id ; Sun, 22 Oct 2000 17:22:54 +0200 Message-ID: From: Itamar Gilad To: "'james jack'" , SIP@lists.bell-labs.com Subject: RE: [SIP] Discussion MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sun, 22 Oct 2000 17:22:53 +0200 Hello James, You are correct that a UAS is responsible for adding a unique tag to the To: header in it's responses. Once it does this in a final response the tag becomes a permanent part of the Call-Leg id, which is basically composed of {Call-ID, To [+ tag], From [+tag]}. This means that any future requests and responses sent in the context of this Call-Leg should must this tag in the To/From header (depending on which side is initiating the request). However, if a server receives an INVITE message which already has a tag in its To: header and this does not match any of its existing Call-Legs it should reject this request with a 481 since the message was sent in the context of some Call-Leg which only the caller is aware of. Example: A is inviting B with a regular INVITE. B excepts with a 200 + To tag, A sends ACK and the Call-Leg is established. B crushes and reboots. A, unaware of this, sends a re-INVITE to B (carrying the To tag). B must reject to avoid inconsistency. Regards Itamar > -----Original Message----- > From: james jack [mailto:sipjames@yahoo.com] > Sent: Fri, October 20, 2000 8:50 AM > To: SIP@lists.bell-labs.com > Subject: [SIP] Discussion > > > Hi,All: > I have one question to consult, the question is that > about the 481 Call Leg/Transaction Does Not Exist, on > RFC2543bis02, which says "This status is returned > under three conditions: The server received a BYE > request that does not match any existing call leg, the > server received a CANCEL request that does not match > any existing transaction or the server received an > INVITE with a To tag that does not match the local tag > value. (A server simply discards an ACK referring to > an unknown transaction.)" . I can't understand the > words "or the server received an INVITE with a To tag > that does not match the local tag value", could > someone give me some example? According to my known,To > tag is inserted by UAS or redirect server. which means > To tag is used in response, how can a INVITE request > with a To tag? > Maybe I am wrong, I want to consult with every > expert? > Thanks! > Yours:james > > > __________________________________________________ > Do You Yahoo!? > Yahoo! Messenger - Talk while you surf! It's FREE. > http://im.yahoo.com/ > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sun Oct 22 11:37:00 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA05970 for ; Sun, 22 Oct 2000 11:37:00 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 18B9E44342; Sun, 22 Oct 2000 10:37:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id E4CC14433A for ; Sun, 22 Oct 2000 10:36:42 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id LAA00417; Sun, 22 Oct 2000 11:38:32 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <4WS2XYJM>; Sun, 22 Oct 2000 11:32:27 -0400 Message-ID: From: Jonathan Rosenberg To: "'Jo Hornsby'" , "'Sunitha Kumar'" , sip bell labs Subject: RE: [SIP] clarification on tags in the BYE request. MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sun, 22 Oct 2000 11:32:22 -0400 > -----Original Message----- > From: Jo Hornsby [mailto:jhornsby@ubiquity.net] > Sent: Friday, October 20, 2000 8:39 AM > To: Jonathan Rosenberg; 'Sunitha Kumar'; sip bell labs > Subject: RE: [SIP] clarification on tags in the BYE request. > > > > > With respect to section 11.3 and 11.4 in September 4, SIPbis, > > > It is given that all subsequent requests of the same callLeg > > > contains the same To header field, including the *tags*. > > > > > > It is also given here, that a UAC copies the tag from the > > > final response into the ACK, but it *MUST NOT* copy the tag > > > into any subsequent requests unless the response was a 200 > > > class response to an INVITE request. > > > > Correct. > > > > >Does this mean: > > >UAC -------send INVITE------------->UAS > > >UAC<------send 200 OK with tag in To----UAS > > >UAC-------send ACK, with same tag as in To of 200 OK-->UAS > > >UAC<-------RTP---------------------->UAS > > > > > Now , if BYE is sent from UAC to a UAS, should UAC tag the To > > > field of the BYE , the same as the 200 OK that it received. > > > > Of course. Isn't that exactly what is implied by the text? > > > > >If yes, why, isn't this another transaction? > > > > Huh?? Of course it is another transaction. > > > > >I agree that if the BYE were to be sent instead of the ACK > > ( in order to cancel the call), > > > > You always send ACK, even if you want to hang up. > > I think this is confusing in the spec; 11.3 says: > > Multiple responses may arrive at the UAC for a > single INVITE request, due to a forking proxy. > Each response is distinguished by the "tag" > parameter in the To header field, and each > represents a distinct call leg. The caller MAY > choose to acknowledge or terminate the call > with each responding UAS. To acknowledge, it > sends an ACK request, and to terminate it sends > a BYE request. > > I interpret this as saying when I receive a 200 to an INVITE, > I don't have to send an ACK if I want to "hang-up" the call. I agree this is really confusing. > > I'm glad to see that this is not the case, but I think that > the text needs to be changed; perhaps: > "...and to terminate it sends an ACK request > followed by a BYE request." Yes, we will add this. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sun Oct 22 11:56:00 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA09917 for ; Sun, 22 Oct 2000 11:56:00 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7DD9A4434A; Sun, 22 Oct 2000 10:56:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from elektron.elka.pw.edu.pl (elektron.elka.pw.edu.pl [194.29.160.2]) by lists.bell-labs.com (Postfix) with ESMTP id 0FA7C44339 for ; Sun, 22 Oct 2000 10:55:31 -0400 (EDT) Received: from dial-barska31.warman.com.pl ([195.164.232.32]:1055 "EHLO elka.pw.edu.pl") by elektron.elka.pw.edu.pl with ESMTP id ; Sun, 22 Oct 2000 17:55:15 +0200 Message-ID: <39F30DFB.27AD4198@elka.pw.edu.pl> From: "Piotr S. Kossowski" Organization: Warsaw University of Technology - Institute of Telecommunications X-Mailer: Mozilla 4.7 [pl] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Billy Biggs Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Multiple responses for single INVITE References: <39F0E026.D182AAA8@elka.pw.edu.pl> <20001021002506.B7425@div8.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sun, 22 Oct 2000 17:55:39 +0200 Content-Transfer-Encoding: 7bit Billy Biggs wrote: > > Piotr S. Kossowski (P.Kossowski@elka.pw.edu.pl): > No. The UAC must ACK each response to the INVITE immediately to stop > the far-end from retransmitting. When you get a 200 response to an > INVITE, the call is by definition already set up. > > Your implementation can do whatever it likes to indicate these > multiple calls to the user. That's an implementation decision. (...) > I would caution against using different ports for each request. It's > polite to make sure that those unfortunate enough to answer the call can I agree, that this is a matter of implementation. However, a port (assigned dynamically by OS) for INVITE purpose at caller must be ready for accepting final reponses from UASes, even if call was established. Is it true ? So we can say that the second, third etc. final responses from UASes are received asynchronusly, because "main" 200 was already received and ACKed. On the other hand, Caller send to Callee in Contact header port, where is able to accept Callee's Req (e.g. BYE). So for me, it's a kind of redundancy beacause at present, two ports are used for one call (first- invoked by OS, second - from Connect header, usually 5060). Isn't it ? If it's true (i'm not sure of it), port inovked for INITE purpuse will be maintained till the end of the call. BYE from caller will be send from this port. Please comment it. Thanks Piotr _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sun Oct 22 23:38:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA06995 for ; Sun, 22 Oct 2000 23:38:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 698CE4433A; Sun, 22 Oct 2000 22:38:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mars.hss.co.in (unknown [202.54.26.197]) by lists.bell-labs.com (Postfix) with ESMTP id B1E7744339 for ; Sun, 22 Oct 2000 22:37:40 -0400 (EDT) Received: from sampark.hss.hns.com (sampark [139.85.229.22]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id e9N3bZC25678; Mon, 23 Oct 2000 09:07:35 +0530 (IST) Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 65256981.00143396 ; Mon, 23 Oct 2000 09:10:39 +0530 X-Lotus-FromDomain: HSSBLR From: archow@hss.hns.com To: sip@lists.bell-labs.com, sip-implementors@cs.columbia.edu Message-ID: <65256981.001431DD.00@sampark.hss.hns.com> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [SIP] implementation inconsistentices of Supported and Date - a note to Implementors Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 23 Oct 2000 09:10:34 +0530 Hi, while testing with various vendor SIP entities we noted the following grammar discrepencies. Mostly stacks are lenient towards such incoming mistakes, but small as they may be, it might be worthwhile for the respective vendors to fix their code. 1. Some vendors still use UTC format in the Date: header. SIP mandates it to be GMT. Therefore a construct like Date: Sat, 01 Jan 2000 06:32:29 UTC is wrong. 2. Supported header is defined as 1#(option-tag) where option-tag is a token. Therefore constructs such as Supported:aa bb cc is wrong. It should be separated by "," not " " Regds Arjun _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 23 01:30:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA08406 for ; Mon, 23 Oct 2000 01:30:03 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 58A964433A; Mon, 23 Oct 2000 00:30:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id C0FAE44339 for ; Mon, 23 Oct 2000 00:29:45 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA01568; Mon, 23 Oct 2000 01:31:36 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <4WS2XYPR>; Mon, 23 Oct 2000 01:25:29 -0400 Message-ID: From: Jonathan Rosenberg To: "'Henning Schulzrinne'" , vkg@lucent.com Cc: Jonathan Rosenberg , sip@lists.bell-labs.com MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] RE: CANCEL - response sequence issue (again) Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 23 Oct 2000 01:25:22 -0400 > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Friday, October 20, 2000 6:02 PM > To: vkg@lucent.com > Cc: Jonathan Rosenberg; sip@lists.bell-labs.com > Subject: Re: CANCEL - response sequence issue (again) > > > > > Would it be possible to add what Jonathan Rosenberg > suggests below for > > backward compatibility in a CANCEL/200 OK/487 Request Terminated > > scenario. This appears to be the cleanest solution. > > Let me see if I can summarize the cases here: > > - if call *was* established before CANCEL arrived (call exists) > 200 (INVITE) is returned within 32s in RFC 2543 or bis > 200 (CANCEL) is returned > > - call failed before CANCEL arrived (no call in progress) > 4xx/5xx (INVITE) is returned > 200 (CANCEL) is returned > > - if call was *not* yet established before CANCEL arrived (i.e., call > does not exist) > 200 (CANCEL) is returned > 487 (INVITE) is returned if -bis, nothing if RFC2543 > (arriving in either order) > > This is presumably the case that is of concern. The UAC or proxy can't > tell whether the 200 (INVITE) is just late (first case) or will never > show up (third case, RFC2543). > > For a proxy, would any state be needed, as long as the ACK can be > generated for any late 487? You can't generate an ACK statelessly. Thats because the request URI has to be the same as the original request, so you need to remember it. Thus, the proxy will need state, and this timer helps destroy that state when its talking to a pure 2543 UAS or proxy which won't send 487. > > For a UAC, may it have to wait the 32s just in case the call was > established after all? Waiting the full 32s is needed only in the extremely unlikely case of a complete network outage lasting at least 32s, and recovering just before the last final response is sent. Whilst one can argue that waiting this full amount is more important for a UA than a proxy, I would much prefer to keep these state machines the same in each case, and so use the same timer. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 23 09:06:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA24303 for ; Mon, 23 Oct 2000 09:06:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C5C5644342; Mon, 23 Oct 2000 08:06:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from drago1.ubiquity.net (unknown [194.202.146.92]) by lists.bell-labs.com (Postfix) with SMTP id 6F12544339 for ; Mon, 23 Oct 2000 08:05:46 -0400 (EDT) Received: from gecko.ubiquity.co.uk by drago1.ubiquity.net via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 23 Oct 2000 13:06:17 UT Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id OAA10787; Mon, 23 Oct 2000 14:04:06 +0100 (BST) Message-ID: <39F43746.920A36BB@ubiquity.net> From: Neil Deason Organization: Ubiquity Software Corporation Limited X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] Registrar - Require or Proxy-Require Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 23 Oct 2000 14:04:06 +0100 Content-Transfer-Encoding: 7bit Is there a general consensus whether the Require or Proxy-Require header should be used by clients to request features of a Registrar? Require seems more correct as the Registrar is the terminating server. However, a Registar is typically co-located with a proxy. Maybe a clear statement in the spec would remove any scope for confusion. Cheers, Neil. -- Ubiquity Software Corporation, UK http://www.ubiquity.net _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 23 10:14:08 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12449 for ; Mon, 23 Oct 2000 10:14:06 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0383844363; Mon, 23 Oct 2000 09:14:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 3644244356 for ; Mon, 23 Oct 2000 09:13:15 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id KAA03306; Mon, 23 Oct 2000 10:15:21 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <4WS2XY5M>; Mon, 23 Oct 2000 10:09:14 -0400 Message-ID: From: Jonathan Rosenberg To: "'Neil Deason'" , sip@lists.bell-labs.com Subject: RE: [SIP] Registrar - Require or Proxy-Require MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 23 Oct 2000 10:09:13 -0400 Its Require. Remember, registrar, proxy, UA are *logical* roles. If it answers a REGISTER, its a registrar for that transaction. Require applies to entities that actually answer a request, and thus, is appropriate for a registrar. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com > -----Original Message----- > From: Neil Deason [mailto:ndeason@ubiquity.net] > Sent: Monday, October 23, 2000 9:04 AM > To: sip@lists.bell-labs.com > Subject: [SIP] Registrar - Require or Proxy-Require > > > Is there a general consensus whether the Require or > Proxy-Require header should be used by clients to request > features of a Registrar? Require seems more correct as the > Registrar is the terminating server. However, a Registar > is typically co-located with a proxy. Maybe a clear > statement in the spec would remove any scope for confusion. > > Cheers, > Neil. > -- > Ubiquity Software Corporation, UK http://www.ubiquity.net > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 23 10:17:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA13172 for ; Mon, 23 Oct 2000 10:17:05 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id AEFC744356; Mon, 23 Oct 2000 09:17:08 -0400 (EDT) Delivered-To: sip@share.research.bell-labs.com Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by lists.bell-labs.com (Postfix) with SMTP id 3A84B44375 for ; Fri, 20 Oct 2000 17:16:06 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Fri Oct 20 18:14:34 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 56C2244384; Fri, 20 Oct 2000 18:01:25 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by lists.bell-labs.com (Postfix) with ESMTP id 308E54437D for ; Fri, 20 Oct 2000 18:01:25 -0400 (EDT) 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 SAA24426; Fri, 20 Oct 2000 18:01:23 -0400 (EDT) Message-ID: <39F0C0D8.E74AFF27@cs.columbia.edu> From: Henning Schulzrinne X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: vkg@lucent.com Cc: Jonathan Rosenberg , sip@lists.bell-labs.com References: <39F08922.CA56A0ED@lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] Re: CANCEL - response sequence issue (again) Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 20 Oct 2000 18:02:00 -0400 Content-Transfer-Encoding: 7bit > Would it be possible to add what Jonathan Rosenberg suggests below for > backward compatibility in a CANCEL/200 OK/487 Request Terminated > scenario. This appears to be the cleanest solution. Let me see if I can summarize the cases here: - if call *was* established before CANCEL arrived (call exists) 200 (INVITE) is returned within 32s in RFC 2543 or bis 200 (CANCEL) is returned - call failed before CANCEL arrived (no call in progress) 4xx/5xx (INVITE) is returned 200 (CANCEL) is returned - if call was *not* yet established before CANCEL arrived (i.e., call does not exist) 200 (CANCEL) is returned 487 (INVITE) is returned if -bis, nothing if RFC2543 (arriving in either order) This is presumably the case that is of concern. The UAC or proxy can't tell whether the 200 (INVITE) is just late (first case) or will never show up (third case, RFC2543). For a proxy, would any state be needed, as long as the ACK can be generated for any late 487? For a UAC, may it have to wait the 32s just in case the call was established after all? I'm sure I missed something (coming in on the tail end of this discussion). > > For backwards compatibility with RFC2543, UACs and proxies which generate > > \CANCEL \MUSTNOT assume that a 487 response to the original transaction will > > be received. Instead, they \SHOULD set a timer upon sending \CANCEL, and > > terminate the transaction if not response to the original request is > > received after X seconds. > > > > Now, the question is: what value for X? To deal with worst case network > > losses, it could be as large as 32 seconds, but that results in very slow > > timeouts. > > > > -Jonathan R. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 23 10:23:06 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA14573 for ; Mon, 23 Oct 2000 10:23:06 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A597444375; Mon, 23 Oct 2000 09:17:21 -0400 (EDT) Delivered-To: sip@share.research.bell-labs.com Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by lists.bell-labs.com (Postfix) with SMTP id 0E98F44339 for ; Fri, 20 Oct 2000 18:08:07 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Fri Oct 20 19:08:01 EDT 2000 Received: by lists.bell-labs.com (Postfix) id C073844380; Fri, 20 Oct 2000 18:54:51 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by lists.bell-labs.com (Postfix) with ESMTP id 9A39F4437D for ; Fri, 20 Oct 2000 18:54:51 -0400 (EDT) Received: from attglobal.net (liscio [135.180.240.41]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id SAA27113; Fri, 20 Oct 2000 18:54:50 -0400 (EDT) Message-ID: <39F0F855.DE894A79@attglobal.net> From: Henning Schulzrinne Reply-To: hgschul@attglobal.net X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: fordtrueman@china.com Cc: SIP@lists.bell-labs.com Subject: Re: [SIP] Some discussions References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 20 Oct 2000 18:58:45 -0700 Content-Transfer-Encoding: 8bit fordtrueman@china.com wrote: > > Dear All: > I have some questions to discuss. > For RFC2543Bis02, I have some doubts, for examples. On page 23, Authorization belongs to request header, But on page 36,it is said it can be used in R & r. Is this contradiction? Yes, now fixed. Authorization can, rarely, also appear in responses, with PGP. > What's more, the same matter happens on WWW-Authentication, first, on page 23,it belongs to response header, But on page 37,it is said it can be used in R & r. Also fixed. Again, this probably escaped attention since few people are having requests provide challenges. > On Page 45 on content-length, it says "If a server receives a UDP request with a Content-Length, but the value is larger than the size of the body sent in the request, the client SHOULD generate a 400 class response." I want to know > which 400 class response can act as this response code, please give me a detailed response code, according to the 4xx response code listed, none can > act as this situation.Perhelps this code is under the consideration. The response code is 400 (not just class), a "Bad Request". As usual, it is advisable to provide verbal details of why the request was bad, so that the request can see the errors of its ways, improve and sin no more. But there are too many ways for requests to be bad, so providing a response code for all of them is probably not warranted. I also adjusted the section to indicate that *any* discrepancy between remaining bytes in a datagram and the Content-Length is to be flagged, pursuant the recent discussion on not having multiple messages in a datagram. Thanks for catching these. > Thanks a lot! > Yours: Ford > > ---------------------------------------------- > ÖлªÍø»ýÉÍÖ®ÂÃ,´ó½±ÈÎÄúÓ®£¡ > http://points4u.china.com > ²Î¼ÓÍøÉÏÅÄÂô£¬ÃûÈËÇ©ÃûÎïÆ·ÈÎÄãÕù! > http://auction4u.china.com > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 23 10:27:35 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA15615 for ; Mon, 23 Oct 2000 10:27:34 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 82D144437D; Mon, 23 Oct 2000 09:17:39 -0400 (EDT) Delivered-To: sip@share.research.bell-labs.com Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by lists.bell-labs.com (Postfix) with SMTP id 4490044339 for ; Fri, 20 Oct 2000 20:18:06 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Fri Oct 20 21:17:23 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 4106244380; Fri, 20 Oct 2000 21:04:14 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by lists.bell-labs.com (Postfix) with ESMTP id DA1444437D for ; Fri, 20 Oct 2000 21:04:13 -0400 (EDT) Received: from attglobal.net (liscio [135.180.240.41]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id VAA00328; Fri, 20 Oct 2000 21:04:11 -0400 (EDT) Message-ID: <39F116A8.E793D006@attglobal.net> From: Henning Schulzrinne Reply-To: hgschul@attglobal.net X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Thys Nel Cc: sip@lists.bell-labs.com Subject: Re: [SIP] ipv4 addresses in sip bnf References: <004b01c02e12$99a329b0$2d0511ac@thys> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 20 Oct 2000 21:08:08 -0700 Content-Transfer-Encoding: 7bit Because this is inherited from HTTP (which inherits it from rfc2396). Since everything else in RFC 2543 comes from there, it would be truly confusing to have divergent definitions. As has been pointed out a few times in different contexts, ABNF is not sufficient to specify semantics. There are lots of syntactically valid IPv4address strings that won't work for one reason or another, such as 0.0.0.0, 0.1.2.3, or 254.255.255.255. An interesting issue is that this and the HTTP/URL syntax allows 010.001.001.002 I wonder how many implementations handle this correctly and don't interpret this as octal, say (which is what some strtol-style functions will do). For ttl, this could be changed, but the definition in rfc2327 is rather unwieldy. Thys Nel wrote: > > Some time ago there was a discussion in this list about the correct bnf for > ipv4 addresses in rfc2327 (sdp). > > Currently in sip an ipv4 address is defined as: > IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT > > which of course allows invalid ipv4 addresses to pass the parser. > > Is there any specific reason why this definition is different to the one > used in rfc2327? > > IP4-address = decimal-uchar "." decimal-uchar "." decimal-uchar "." > decimal-uchar > where decimal-uchar can be 0-255. > > The same applies to the "ttl" definition. > > -- > Thys Nel > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 23 10:33:19 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA17183 for ; Mon, 23 Oct 2000 10:33:16 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id CEE5B44386; Mon, 23 Oct 2000 09:17:46 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cybertron.div8.net (el05-24-131-150-91.ce.mediaone.net [24.131.150.91]) by lists.bell-labs.com (Postfix) with ESMTP id 7357C44339 for ; Sat, 21 Oct 2000 00:25:21 -0400 (EDT) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for sip@lists.bell-labs.com; Sat, 21 Oct 2000 00:25:06 -0500 (CDT) From: Billy Biggs To: "Piotr S. Kossowski" Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Multiple responses for single INVITE Message-ID: <20001021002506.B7425@div8.net> References: <39F0E026.D182AAA8@elka.pw.edu.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i In-Reply-To: <39F0E026.D182AAA8@elka.pw.edu.pl>; from P.Kossowski@elka.pw.edu.pl on Sat, Oct 21, 2000 at 02:15:34AM +0200 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sat, 21 Oct 2000 00:25:06 -0500 Piotr S. Kossowski (P.Kossowski@elka.pw.edu.pl): > Section 11.3 of rfc2543bis-02 says: > > "Multiple responses may arrive at the UAC for a single INVITE request, > (...) The caller MAY choose to acknowledge or terminate the call with > each responding UAS. To acknowledge, it sends an ACK request, and to > terminate it sends a BYE request." > > Section 4.2.5 says: > > "The BYE request cannot be used to cancel branches of a parallel search, > since several branches may, through intermediate proxies, find the same > user agent server and then terminate the call.(...)" > > There are two issues that are not clear for me: > > 1. Aren't there any discrepancy in these two sections (I mean BYE usage)? I don't think so. > 2. If the spec says that multiple response can arrive at the UAC > for a single INVITE, there should be at least two ways of > behaviour, to my mind: > > a. UAC wait a while (e.g. 5 second) after getting first final > response to INVITE. If there is no next response (from other UAS), > UAC sends ACK to this INVITE and desctructs its socket. If there > are responses during this time, UAC shows to user a list of servers > that replied and allows to decide what to do with them (either > accept (ACK) or not (BYE)) The question is: how much time should it > wait for reponses from network ? No. The UAC must ACK each response to the INVITE immediately to stop the far-end from retransmitting. When you get a 200 response to an INVITE, the call is by definition already set up. Your implementation can do whatever it likes to indicate these multiple calls to the user. That's an implementation decision. You must ACK all responses to the INVITE. BYE is no substitute for an ACK. > b. UAC sends ACK imediately after getting first 200 resp, destructs > its port and there is no chance for getting other responses at all > (destructed port was put in Via, of course). We lost responses > from other servers, but we are happy, beacuse our callee accepted a > call. I would caution against using different ports for each request. It's polite to make sure that those unfortunate enough to answer the call can at least get ACK'ed and then a BYE instead of having to wait for their retransmission timer to expire. -- Billy Biggs, 3Com Email: Billy_Biggs@3com.com http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 23 10:37:15 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA18162 for ; Mon, 23 Oct 2000 10:37:11 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B16DE44394; Mon, 23 Oct 2000 09:17:54 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by lists.bell-labs.com (Postfix) with ESMTP id B516744354 for ; Mon, 23 Oct 2000 02:35:18 -0400 (EDT) Received: from mr4u3.ericy.com (mr4u3.ericy.com [208.237.135.127]) by imr1.ericy.com (8.9.3/8.9.3) with ESMTP id CAA06880; Mon, 23 Oct 2000 02:31:12 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr4u3.ericy.com (8.9.3/8.9.3) with ESMTP id CAA21186; Mon, 23 Oct 2000 02:31:12 -0500 (CDT) Received: from ericsson.com ([147.214.68.17]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id CAA19979; Mon, 23 Oct 2000 02:31:10 -0500 (CDT) Message-ID: <39F3E93C.15FFD1A5@ericsson.com> From: Sean Olson Organization: Ericsson Inc. X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Vijay K. Gurbani" Cc: Jonathan Rosenberg , "'Piotr S. Kossowski'" , sip@lists.bell-labs.com Subject: Re: [SIP] Multi-message UDP datagrams References: <39F0629B.2D56031B@lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 23 Oct 2000 09:31:08 +0200 Content-Transfer-Encoding: 7bit I would strongly disagree with the complexity issue. You need to know where the end of a SIP message is. What happens if you receive garbage at the end of a UDP datagram? If you are going to take the time to deal with Content-Length: or multipart/*, then you've gone 99% of the way to supporting multiple messages in a single UDP datagram. Easy cheesy! This is not that complex. I would remove line folding before I messed with this. (Not that I'm suggesting we do this) -- Sean Olson "Vijay K. Gurbani" wrote: > Jonathan Rosenberg wrote: > > > > It was my view that receiving multiple messages in a single datagram was the > > same as if they were received in separate datagrams. In other words, there > > was no requirements for ordering or completion. The result of that was a > > simplification in the implementation of handling this case; UDP works just > > like TCP. Imposing transactional requirements adds significant burden. I'd > > rather not do that unless there was serious requirements or needs here. > > > > In fact, I would argue that multiple messages per datagram might be > > something to consider for removal. I've never seen it used. I'm not sure > > what the benefit is, in reality. There is little byte savings, and its just > > more complexity that is really needless. > > > > Lets simplify, not complicate. > [...] > > For whatever it is worth, I agree. In the bakeoff scenarios, I have > never > seen a SIP entity send multiple messages in the same datagram. > > Regards, > > - vijay > -- > Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} > Internet Software/IN Architecture Group > Lucent Technologies/Bell Labs Innovations 263 Shuman Blvd., Rm 1A-413 > Naperville, Illinois 60566 Voice: +1 630 224 0216 Fax: +1 630 713 > 0184 > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 23 10:45:21 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA20049 for ; Mon, 23 Oct 2000 10:45:19 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id DEA6A4439C; Mon, 23 Oct 2000 09:18:01 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lists.bell-labs.com (Postfix) with ESMTP id 1F93A44339 for ; Mon, 23 Oct 2000 07:23:50 -0400 (EDT) Received: from ms.uab.ericsson.se (ms.uab.ericsson.se [134.138.201.16]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id e9NCNiZ01325 for ; Mon, 23 Oct 2000 14:23:44 +0200 (MEST) Received: from uabx04c384.uab.ericsson.se.uab.ericsson.se (uabx04c384 [134.138.229.144]) by ms.uab.ericsson.se (8.10.0/8.10.0/uab-2.26) with ESMTP id e9NCNin03375 for ; Mon, 23 Oct 2000 14:23:44 +0200 (MET DST) Received: from uab.ericsson.se by uabx04c384.uab.ericsson.se.uab.ericsson.se (8.8.7/client-1.3uab1) id OAA05901; Mon, 23 Oct 2000 14:23:43 +0200 (MET DST) Message-ID: <39F42DCE.339EAFCB@uab.ericsson.se> From: Bertil Engelholm Organization: Ericsson Utvecklings AB X-Mailer: Mozilla 4.74C-CCK-MCD [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: sv,en-US MIME-Version: 1.0 To: sip@lists.bell-labs.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] Transaction identification, again Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 23 Oct 2000 14:23:42 +0200 Content-Transfer-Encoding: 7bit Hi, I think there are still a few question marks regarding transaction identification in SIP. I'll try and describe how I understand the specification and what problems I see. Here is an example call chain : ------ ------ ------ ------ | |----->| P2 |----->| | | | | | ------ | | | | ------ Ca ---->| P1 | | P4 |----->| P5 |----->| Cb | | | ------ | | | | ------ | |----->| P3 |----->| | | | ------ ------ ------ ------ Ca INVITEs Cb at P1. P1 forks two bransches, one to P2 and the other to P3. Both P2 and P3 proxy the INVITE to P4 with the same requestURI (Cb@P4). The first problem is for P4 to realize the the two INVITEs coming from P2 and P3 is not the same. They will have the same Call-Leg, Cseq and requestURI. If I understand the specification correct this is solved by having P4 look in the topmost via header. In this way P4 will detect that one comes from P2 and the other from P3 therefore they are two different INVITEs and not a retransmission. The next problem arises when the two INVITEs arrives at P5 because now the topmost via will be the same (P4). The specification seems to handle this problem by letting each proxy ad a global unique identifier as one of the branch values in it's via header (a hash of a sequence number, own IP address and requestURI). In this way P5 will now be able to detect that the two INVITEs are different because P4 will use different sequence numbers for the two INVITEs. The problems I can't see a solution for is : How will P5 be able to detect a retransmission if it gets a global unique identifier in each request ? If P4 is stateful it could save the sequence number it used the last time and use it again in the retransmission but if P4 is stateless that's not possible. So if P4 is stateless it has to go on generating new sequence numbers for each request. This means that P5 can't detect a retransmission. Or have I missed something ? If P1 CANCEL one of the branches, how will P5 be able to detect which INVITE transaction it relates to ? It only has Call-Leg + Cseq to use and they are the same for both INVITEs. -- Bertil Engelholm Ericsson Research and Development voice : +46 8 727 3499 SIP Security Fax : +46 8 647 8276 S-126 25 Stockholm Sweden E-mail: Bertil.Engelholm@uab.ericsson.se _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 23 10:50:54 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA21561 for ; Mon, 23 Oct 2000 10:50:54 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0D9DC443A4; Mon, 23 Oct 2000 09:18:09 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by lists.bell-labs.com (Postfix) with ESMTP id 2398444362 for ; Mon, 23 Oct 2000 08:17:19 -0400 (EDT) Received: from mr4u3.ericy.com (mr4u3.ericy.com [208.237.135.127]) by imr1.ericy.com (8.9.3/8.9.3) with ESMTP id IAA02092; Mon, 23 Oct 2000 08:15:24 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr4u3.ericy.com (8.9.3/8.9.3) with ESMTP id IAA15785; Mon, 23 Oct 2000 08:15:23 -0500 (CDT) Received: from ericsson.com ([147.214.68.17]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id IAA00453; Mon, 23 Oct 2000 08:15:22 -0500 (CDT) Message-ID: <39F439E5.C623EEE0@ericsson.com> From: Sean Olson Organization: Ericsson Inc. X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Neil Deason Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Registrar - Require or Proxy-Require References: <39F43746.920A36BB@ubiquity.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 23 Oct 2000 15:15:18 +0200 Content-Transfer-Encoding: 7bit I think this would depend on the feature you are trying to request and whether you want the Registar to support the feature as a proxy, server, or both. It seems clear to me. Maybe you could give an example that would clarify the problem you have. /sean -- Sean Olson Neil Deason wrote: > Is there a general consensus whether the Require or > Proxy-Require header should be used by clients to request > features of a Registrar? Require seems more correct as the > Registrar is the terminating server. However, a Registar > is typically co-located with a proxy. Maybe a clear > statement in the spec would remove any scope for confusion. > > Cheers, > Neil. > -- > Ubiquity Software Corporation, UK http://www.ubiquity.net > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 23 10:54:52 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA22135 for ; Mon, 23 Oct 2000 10:54:51 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C8324443BC; Mon, 23 Oct 2000 09:34:07 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from drago1.ubiquity.net (unknown [194.202.146.92]) by lists.bell-labs.com (Postfix) with SMTP id 68B7C443BA for ; Mon, 23 Oct 2000 09:33:05 -0400 (EDT) Received: from gecko.ubiquity.co.uk by drago1.ubiquity.net via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 23 Oct 2000 14:33:36 UT Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id PAA14779; Mon, 23 Oct 2000 15:31:26 +0100 (BST) Message-ID: <39F44BBD.6041464B@ubiquity.net> From: Neil Deason Organization: Ubiquity Software Corporation Limited X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Registrar - Require or Proxy-Require References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 23 Oct 2000 15:31:25 +0100 Content-Transfer-Encoding: 7bit I agree that Require is the right choice. Section 6.35 Require only refers to User Agent Servers using the header though not Registrars. Cheers, Neil. -- Ubiquity Software Corporation, UK http://www.ubiquity.net Jonathan Rosenberg wrote: > > Its Require. > > Remember, registrar, proxy, UA are *logical* roles. If it answers a > REGISTER, its a registrar for that transaction. Require applies to entities > that actually answer a request, and thus, is appropriate for a registrar. > > -Jonathan R. > > --- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > > > -----Original Message----- > > From: Neil Deason [mailto:ndeason@ubiquity.net] > > Sent: Monday, October 23, 2000 9:04 AM > > To: sip@lists.bell-labs.com > > Subject: [SIP] Registrar - Require or Proxy-Require > > > > > > Is there a general consensus whether the Require or > > Proxy-Require header should be used by clients to request > > features of a Registrar? Require seems more correct as the > > Registrar is the terminating server. However, a Registar > > is typically co-located with a proxy. Maybe a clear > > statement in the spec would remove any scope for confusion. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 23 11:10:44 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA24494 for ; Mon, 23 Oct 2000 11:10:42 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id F39C9443CB; Mon, 23 Oct 2000 09:42:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from dgesmtp01.wcom.com (dgesmtp01.wcom.com [199.249.16.16]) by lists.bell-labs.com (Postfix) with ESMTP id 6650D443CB for ; Mon, 23 Oct 2000 09:41:03 -0400 (EDT) Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-33 #42260) id <0G2W00E010R5AZ@firewall.mcit.com> for sip@lists.bell-labs.com; Mon, 23 Oct 2000 14:40:17 +0000 (GMT) Received: from dgismtp02.wcomnet.com ([166.38.58.142]) by firewall.mcit.com (PMDF V5.2-33 #42260) with ESMTP id <0G2W00E1P0R59O@firewall.mcit.com> for sip@lists.bell-labs.com; Mon, 23 Oct 2000 14:40:17 +0000 (GMT) Received: from CONVERSION-DAEMON by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) id <0G2W00H010R5V9@dgismtp02.wcomnet.com> for sip@lists.bell-labs.com; Mon, 23 Oct 2000 14:40:17 +0000 (GMT) Received: from dgismtp02.wcomnet.com by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) with SMTP id <0G2W00H010QVTE@dgismtp02.wcomnet.com> for sip@lists.bell-labs.com; Mon, 23 Oct 2000 14:40:17 +0000 (GMT) Received: from Steveb1 ([166.35.227.169]) by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) with ESMTP id <0G2W00EMM0QS9J@dgismtp02.wcomnet.com> for sip@lists.bell-labs.com; Mon, 23 Oct 2000 14:40:05 +0000 (GMT) From: "Christopher A. Martin" In-reply-to: To: sip@lists.bell-labs.com Reply-To: christopher.a.martin@wcom.com Message-id: <000b01c03cff$18a57ec0$a9e323a6@mcit.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 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 Subject: [SIP] Question regarding hop-by-hop encryption and SIP Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 23 Oct 2000 09:39:48 -0500 Content-Transfer-Encoding: 7bit I have a question regarding IPSec as a hop-by-hop authentication soultion. In SIP bis 02 (section 13.2), an example is stated: "If required, hop-by-hop authentication can be provided, for example, by the IPSEC Authentication Header". Since the application of hop-by-hop authentication in one of my scenarios will be IPSec protection between WAN routers only, would it really matter if it were AH or ESP, besides the cost of CPU cycles? Example: UA/UAS---Gateway---WAN ROUTER---(IPSec Authenticated and perhaps encrypted Link)---WAN ROUTER---Gateway---UA/UAS As long as the Gateways recieve the original data from the WAN Routers, the original data should be untouched, correct? This line of thought is aimed at the KISS way of thinking. Thanks in advance, Chris Martin -----Original Message----- From: sip-admin@lists.bell-labs.com [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Jonathan Rosenberg Sent: Monday, October 23, 2000 9:09 AM To: 'Neil Deason'; sip@lists.bell-labs.com Subject: RE: [SIP] Registrar - Require or Proxy-Require Its Require. Remember, registrar, proxy, UA are *logical* roles. If it answers a REGISTER, its a registrar for that transaction. Require applies to entities that actually answer a request, and thus, is appropriate for a registrar. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com > -----Original Message----- > From: Neil Deason [mailto:ndeason@ubiquity.net] > Sent: Monday, October 23, 2000 9:04 AM > To: sip@lists.bell-labs.com > Subject: [SIP] Registrar - Require or Proxy-Require > > > Is there a general consensus whether the Require or > Proxy-Require header should be used by clients to request > features of a Registrar? Require seems more correct as the > Registrar is the terminating server. However, a Registar > is typically co-located with a proxy. Maybe a clear > statement in the spec would remove any scope for confusion. > > Cheers, > Neil. > -- > Ubiquity Software Corporation, UK http://www.ubiquity.net > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 23 11:22:58 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA27197 for ; Mon, 23 Oct 2000 11:22:57 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D8C52443D8; Mon, 23 Oct 2000 10:06:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from drago1.ubiquity.net (unknown [194.202.146.92]) by lists.bell-labs.com (Postfix) with SMTP id 11AB2443D7 for ; Mon, 23 Oct 2000 10:05:30 -0400 (EDT) Received: from gecko.ubiquity.co.uk by drago1.ubiquity.net via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 23 Oct 2000 15:06:01 UT Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id QAA27584; Mon, 23 Oct 2000 16:03:51 +0100 (BST) From: "Jo Hornsby" To: "Bertil Engelholm" , Subject: RE: [SIP] Transaction identification, again Message-ID: <001401c03d02$748cd730$4e34c3c1@ubiquity.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 In-Reply-To: <39F42DCE.339EAFCB@uab.ericsson.se> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 23 Oct 2000 16:03:52 +0100 Content-Transfer-Encoding: 7bit > I think there are still a few question marks regarding > transaction identification in SIP. I'll try and describe > how I understand the specification and what problems I > see. > > Here is an example call chain : > > ------ ------ ------ ------ > | |----->| P2 |----->| | | | > | | ------ | | | | ------ > Ca ---->| P1 | | P4 |----->| P5 |----->| Cb | > | | ------ | | | | ------ > | |----->| P3 |----->| | | | > ------ ------ ------ ------ > > Ca INVITEs Cb at P1. P1 forks two bransches, one to P2 and > the other to P3. Both P2 and P3 proxy the INVITE to P4 with > the same requestURI (Cb@P4). > > The first problem is for P4 to realize the the two INVITEs > coming from P2 and P3 is not the same. They will have the > same Call-Leg, Cseq and requestURI. If I understand the > specification correct this is solved by having P4 look in > the topmost via header. In this way P4 will detect that one > comes from P2 and the other from P3 therefore they are > two different INVITEs and not a retransmission. > > The next problem arises when the two INVITEs arrives at P5 > because now the topmost via will be the same (P4). The > specification seems to handle this problem by letting each > proxy ad a global unique identifier as one of the branch > values in it's via header (a hash of a sequence number, > own IP address and requestURI). In this way P5 will now > be able to detect that the two INVITEs are different because > P4 will use different sequence numbers for the two INVITEs. No. The moment that P4 detects it has seen two requests which are isomorphic if one _does not consider_ the topmost Via, then P4 knows it is at the tip of a request merge, and thus should take appropriate action. I would recommend returning a 4xx (say 482 with reason "Request Merge", or something) to all secondary requests. For more information, look at: http://www.cs.columbia.edu/~jdrosen/sip/multiple_requests.txt > The problems I can't see a solution for is : > > How will P5 be able to detect a retransmission if it gets > a global unique identifier in each request ? If P4 is > stateful it could save the sequence number it used the > last time and use it again in the retransmission but > if P4 is stateless that's not possible. So if P4 is > stateless it has to go on generating new sequence > numbers for each request. This means that P5 can't > detect a retransmission. Or have I missed something ? If P4 is behaving statelessly, it can ensure that it generates the same branch parameter for retransmitted requests by making it a hash of [Request-URI, From, To, Call-ID, CSeq, topmost-Via (including branch parameter)], for example. > If P1 CANCEL one of the branches, how will P5 be able > to detect which INVITE transaction it relates to ? > It only has Call-Leg + Cseq to use and they are the > same for both INVITEs. The CANCEL requests should still have different topmost-Vias which correspond to the topmost-Vias in the original INVITEs. HTH, - Jo. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 23 13:10:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA15721 for ; Mon, 23 Oct 2000 13:10:03 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6E0C44433A; Mon, 23 Oct 2000 12:10:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lists.bell-labs.com (Postfix) with ESMTP id 4FD23443D0 for ; Mon, 23 Oct 2000 09:42:32 -0400 (EDT) Received: from ms.uab.ericsson.se (ms.uab.ericsson.se [134.138.201.16]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id e9NEgRZ19439 for ; Mon, 23 Oct 2000 16:42:27 +0200 (MEST) Received: from uabx04c384.uab.ericsson.se.uab.ericsson.se (uabx04c384 [134.138.229.144]) by ms.uab.ericsson.se (8.10.0/8.10.0/uab-2.26) with ESMTP id e9NEgQn27699 for ; Mon, 23 Oct 2000 16:42:27 +0200 (MET DST) Received: from uab.ericsson.se by uabx04c384.uab.ericsson.se.uab.ericsson.se (8.8.7/client-1.3uab1) id QAA06077; Mon, 23 Oct 2000 16:42:23 +0200 (MET DST) Message-ID: <39F44E4B.51E649@uab.ericsson.se> From: Bertil Engelholm Organization: Ericsson Utvecklings AB X-Mailer: Mozilla 4.74C-CCK-MCD [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: sv,en-US MIME-Version: 1.0 To: sip@lists.bell-labs.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] loop detection ?? Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 23 Oct 2000 16:42:19 +0200 Content-Transfer-Encoding: 7bit Hi, I have a question regarding loop detection. In the description of VIA-headers it says that the loop detection value MAY be a hash of TO,FROM,CALL-ID,CSEQ and REQUEST-URI. So I wonder if it's not enough to only use the REQUEST-URI. Can there exist cases where someone changes any of the other fields (and thereby change CALL-LEG) and continues with the VIA-list that existed before the change ? Is this allowed ? If someone does this I guess they have to be prepared to change the values back when the response is sent back. Otherwise the caller will not be able to recognise the CALL-LEG ? -- Bertil Engelholm AXE Research and Development voice : +46 8 727 3499 SIP Security Fax : +46 8 647 8276 S-126 25 Stockholm Sweden E-mail: Bertil.Engelholm@uab.ericsson.se _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 23 13:11:44 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA15944 for ; Mon, 23 Oct 2000 13:11:43 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7049B44394; Mon, 23 Oct 2000 12:10:13 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 6165C443C1 for ; Mon, 23 Oct 2000 09:49:14 -0400 (EDT) Received: from attglobal.net (cta.cs.columbia.edu [128.59.19.46]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id KAA17883; Mon, 23 Oct 2000 10:49:06 -0400 (EDT) Message-ID: <39F1E436.4B8B276F@attglobal.net> From: Henning Schulzrinne Reply-To: hgschul@attglobal.net X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jo Hornsby Cc: sip@lists.bell-labs.com Subject: Re: [SIP] question on receiving multiple invites References: <000401c02a30$3260dee0$4e34c3c1@ubiquity.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sat, 21 Oct 2000 11:45:10 -0700 Content-Transfer-Encoding: 7bit Changed to tentative wording ... Each of these copies bears the same \header{Call-ID}, but a different topmost \header{Via} header branch parameter (see Section~\ref{sec:Via}). The user agent {\MAY} choose which final response to return for each such request, typically returning a 200 (OK) for only one of them. Jo Hornsby wrote: > > > > > If a UAS receives multiple invites (due to an intermediate > > > > forking proxy), should it respond with 200 for the second invite. > > > > And if it does respond with 200, should the TAG added in the TO: > > > > for this be different than the one sent on the first invite? > > > > > > This is known as "request merging". Have a look at the > > > following discussion: > > > http://www.cs.columbia.edu/~jdrosen/sip/multiple_requests.txt > > > > > > Note that with the new rules about proxies having to make > > > branch parameters "globally unique", things are probably a > > > little easier. Thus I prefer the UAS-errors-secondary-requests > > > approach (and don't use different tags), since you should be > > > able to match ACKs up to their respective INVITEs pretty easily > > > (if an ACK including the topmost-Via doesn't match any other > > > transaction, it must have been for the 200). > > > > Should the wording in the draft section 1.4.5 below be changed? > > > > "Each of these copies bears the same Call-ID. The > > user agent MUST return the same status response returned in the > > first > > response. Duplicate requests are not an error" > > > > Since this seems to require sending only 200 for the > > subsequent requests? > > I concur -- I think this text should change. > > - Jo. > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 23 13:14:39 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA16324 for ; Mon, 23 Oct 2000 13:14:38 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D2347443AA; Mon, 23 Oct 2000 12:10:21 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lists.bell-labs.com (Postfix) with ESMTP id 1AF4F44386 for ; Mon, 23 Oct 2000 10:52:05 -0400 (EDT) Received: from ms.uab.ericsson.se (ms.uab.ericsson.se [134.138.201.16]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id e9NFq0Z01322; Mon, 23 Oct 2000 17:52:00 +0200 (MEST) Received: from uabx04c384.uab.ericsson.se.uab.ericsson.se (uabx04c384 [134.138.229.144]) by ms.uab.ericsson.se (8.10.0/8.10.0/uab-2.26) with ESMTP id e9NFpxn06671; Mon, 23 Oct 2000 17:51:59 +0200 (MET DST) Received: from uab.ericsson.se by uabx04c384.uab.ericsson.se.uab.ericsson.se (8.8.7/client-1.3uab1) id RAA06127; Mon, 23 Oct 2000 17:51:55 +0200 (MET DST) Message-ID: <39F45E97.81E003C8@uab.ericsson.se> From: Bertil Engelholm Organization: Ericsson Utvecklings AB X-Mailer: Mozilla 4.74C-CCK-MCD [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: sv,en-US MIME-Version: 1.0 To: SIP@lists.bell-labs.com Cc: Jo Hornsby Subject: Re: [SIP] Transaction identification, again References: <8t20bm$3ku$1@lux2.datacom-lab.uab.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 23 Oct 2000 17:51:51 +0200 Content-Transfer-Encoding: 7bit Jo Hornsby wrote: > > > I think there are still a few question marks regarding > > transaction identification in SIP. I'll try and describe > > how I understand the specification and what problems I > > see. > > > > Here is an example call chain : > > > > ------ ------ ------ ------ > > | |----->| P2 |----->| | | | > > | | ------ | | | | ------ > > Ca ---->| P1 | | P4 |----->| P5 |----->| Cb | > > | | ------ | | | | ------ > > | |----->| P3 |----->| | | | > > ------ ------ ------ ------ > > > > Ca INVITEs Cb at P1. P1 forks two bransches, one to P2 and > > the other to P3. Both P2 and P3 proxy the INVITE to P4 with > > the same requestURI (Cb@P4). > > > > The first problem is for P4 to realize the the two INVITEs > > coming from P2 and P3 is not the same. They will have the > > same Call-Leg, Cseq and requestURI. If I understand the > > specification correct this is solved by having P4 look in > > the topmost via header. In this way P4 will detect that one > > comes from P2 and the other from P3 therefore they are > > two different INVITEs and not a retransmission. > > > > The next problem arises when the two INVITEs arrives at P5 > > because now the topmost via will be the same (P4). The > > specification seems to handle this problem by letting each > > proxy ad a global unique identifier as one of the branch > > values in it's via header (a hash of a sequence number, > > own IP address and requestURI). In this way P5 will now > > be able to detect that the two INVITEs are different because > > P4 will use different sequence numbers for the two INVITEs. > > No. The moment that P4 detects it has seen two requests > which are isomorphic if one _does not consider_ the topmost > Via, then P4 knows it is at the tip of a request merge, > and thus should take appropriate action. > > I would recommend returning a 4xx (say 482 with reason > "Request Merge", or something) to all secondary requests. OK, that's makes sence even though I can't read that out from the specification. Where is request merging described ? > > For more information, look at: > http://www.cs.columbia.edu/~jdrosen/sip/multiple_requests.txt > > > The problems I can't see a solution for is : > > > > How will P5 be able to detect a retransmission if it gets > > a global unique identifier in each request ? If P4 is > > stateful it could save the sequence number it used the > > last time and use it again in the retransmission but > > if P4 is stateless that's not possible. So if P4 is > > stateless it has to go on generating new sequence > > numbers for each request. This means that P5 can't > > detect a retransmission. Or have I missed something ? > > If P4 is behaving statelessly, it can ensure that it > generates the same branch parameter for retransmitted > requests by making it a hash of [Request-URI, From, To, > Call-ID, CSeq, topmost-Via (including branch parameter)], > for example. This also makes sence since we came up with the same solution 8-). But the specification does not say anything about that this is what you need to do. So the VIA chapter maybe needs an update on this part. > > > If P1 CANCEL one of the branches, how will P5 be able > > to detect which INVITE transaction it relates to ? > > It only has Call-Leg + Cseq to use and they are the > > same for both INVITEs. > > The CANCEL requests should still have different topmost-Vias > which correspond to the topmost-Vias in the original INVITEs. > > HTH, > > - Jo. > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip -- Bertil Engelholm AXE Research and Development voice : +46 8 727 3499 SIP Security Fax : +46 8 647 8276 S-126 25 Stockholm Sweden E-mail: Bertil.Engelholm@uab.ericsson.se _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 23 13:18:12 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA16819 for ; Mon, 23 Oct 2000 13:18:12 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C64B8443B5; Mon, 23 Oct 2000 12:10:32 -0400 (EDT) Delivered-To: sip@share.research.bell-labs.com Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by lists.bell-labs.com (Postfix) with SMTP id 27E5E44339 for ; Mon, 23 Oct 2000 11:08:08 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Mon Oct 23 12:07:10 EDT 2000 Received: by lists.bell-labs.com (Postfix) id B00B444384; Mon, 23 Oct 2000 11:54:01 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ans.ih.lucent.com (ans.ih.lucent.com [135.2.78.5]) by lists.bell-labs.com (Postfix) with SMTP id 69F2D4437D for ; Mon, 23 Oct 2000 11:54:01 -0400 (EDT) Received: by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id KAA26992; Mon, 23 Oct 2000 10:53:58 -0500 Cc: Jonathan Rosenberg , sip@lists.bell-labs.com, Vijay Gurbani Received: from lucent.com by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id KAA26958; Mon, 23 Oct 2000 10:53:54 -0500 Message-ID: <39F45F0A.7BAE2923@lucent.com> From: "Vijay K. Gurbani" Reply-To: vkg@lucent.com Organization: Intelligent Network/Messaging Systems & Internet Software Group X-Mailer: Mozilla 4.61 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Henning Schulzrinne Original-CC: Jonathan Rosenberg , sip@lists.bell-labs.com, Vijay Gurbani Subject: Re: [SIP] Re: CANCEL - response sequence issue (again) References: <39F08922.CA56A0ED@lucent.com> <39F0C0D8.E74AFF27@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 23 Oct 2000 10:53:46 -0500 Content-Transfer-Encoding: 7bit Dr. Schulzrinne: Please see embedded comments: Henning Schulzrinne wrote: > > > Would it be possible to add what Jonathan Rosenberg suggests below > > for > > backward compatibility in a CANCEL/200 OK/487 Request Terminated > > scenario. This appears to be the cleanest solution. > > Let me see if I can summarize the cases here: > > - if call *was* established before CANCEL arrived (call exists) > 200 (INVITE) is returned within 32s in RFC 2543 or bis > 200 (CANCEL) is returned > > - call failed before CANCEL arrived (no call in progress) > 4xx/5xx (INVITE) is returned > 200 (CANCEL) is returned > > - if call was *not* yet established before CANCEL arrived (i.e., call > does not exist) > 200 (CANCEL) is returned > 487 (INVITE) is returned if -bis, nothing if RFC2543 > (arriving in either order) > > This is presumably the case that is of concern. The UAC or proxy can't > tell whether the 200 (INVITE) is just late (first case) or will never > show up (third case, RFC2543). Right. > For a proxy, would any state be needed, as long as the ACK can be > generated for any late 487? Unless I am mistaken, state for the original transaction would be needed if the proxy forked an INVITE request into n branches going downstream. When it gets a 200 OK (INVITE) on one of its branches, it may forward it upstream and send CANCEL downstream to n-1 branches. It will need to maintain state for these n-1 branches so it may respond with an ACK if a 487 response gets to one of these branches (or kill the branch after X seconds if all it got was a 200 OK (CANCEL) -- RFC 2543 behavior). > For a UAC, may it have to wait the 32s just in case the call was > established after all? Setting X to 32 is one solution; but as Jonathan points out, it will lead to slow timeouts. I wonder if UACs may *have* to wait 32 seconds, just to be sure, and proxies, having sent a final response upstream to a forked INVITE, may get by with waiting < 32 seconds (10, 20?) on the rest of their branches. In the worst case, the UAS will retransmit 487 until it gives up due to the non-receipt of an ACK (not terribly elegant, but any other suggestions?). > I'm sure I missed something (coming in on the tail end of this > discussion). > > > > For backwards compatibility with RFC2543, UACs and proxies which > > > generate \CANCEL \MUSTNOT assume that a 487 response to the > > > original transaction will be received. Instead, they \SHOULD set a > > > timer upon sending \CANCEL, and terminate the transaction if not > > > response to the original request is received after X seconds. > > > > > > Now, the question is: what value for X? To deal with worst case > > > network losses, it could be as large as 32 seconds, but that > > > results in very slow timeouts. > > > > > > -Jonathan R. - vijay -- Vijay K. Gurbani vkg@lucent.com vkg@research.bell-labs.com vkg@acm.org Internet Software Group/Intelligent Network and Messaging Systems Lucent Technologies/Bell Labs Innovations, 263 Shuman Blvd, Rm 1A-413 Naperville, Illinois 60566 Voice: +1 630 224 0216 Fax: +1 630 713 0184 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 23 13:22:37 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA17336 for ; Mon, 23 Oct 2000 13:22:36 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4CF7D443C0; Mon, 23 Oct 2000 12:10:41 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from jindo.cisco.com (jindo.cisco.com [171.69.11.73]) by lists.bell-labs.com (Postfix) with ESMTP id 423844433A for ; Mon, 23 Oct 2000 11:29:52 -0400 (EDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [171.71.147.106]) by jindo.cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id JAA09709; Mon, 23 Oct 2000 09:29:47 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA13424; Mon, 23 Oct 2000 09:29:47 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14836.26490.987960.79816@thomasm-u1.cisco.com> To: christopher.a.martin@wcom.com Cc: sip@lists.bell-labs.com Subject: [SIP] Question regarding hop-by-hop encryption and SIP In-Reply-To: <000b01c03cff$18a57ec0$a9e323a6@mcit.com> References: <000b01c03cff$18a57ec0$a9e323a6@mcit.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: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 23 Oct 2000 09:29:46 -0700 (PDT) Content-Transfer-Encoding: 7bit Christopher A. Martin writes: > I have a question regarding IPSec as a hop-by-hop authentication soultion. > > In SIP bis 02 (section 13.2), an example is stated: "If required, hop-by-hop > authentication can be provided, for example, by the IPSEC Authentication > Header". Since the application of hop-by-hop authentication in one of my > scenarios will be IPSec protection between WAN routers only, would it really > matter if it were AH or ESP, besides the cost of CPU cycles? No. ESP with message integrity would be just fine. > > Example: > > UA/UAS---Gateway---WAN ROUTER---(IPSec Authenticated and perhaps encrypted > Link)---WAN ROUTER---Gateway---UA/UAS > > As long as the Gateways recieve the original data from the WAN Routers, the > original data should be untouched, correct? So long as none of the hosts behind the two security gateways are bad guys, of course :-) Mike _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 23 13:25:15 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA17673 for ; Mon, 23 Oct 2000 13:25:15 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id AD06E443C6; Mon, 23 Oct 2000 12:10:48 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lists.bell-labs.com (Postfix) with ESMTP id 2852A44339 for ; Mon, 23 Oct 2000 11:48:17 -0400 (EDT) Received: from ms.uab.ericsson.se (ms.uab.ericsson.se [134.138.201.16]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id e9NGmBt14514 for ; Mon, 23 Oct 2000 18:48:11 +0200 (MEST) Received: from uabx04c384.uab.ericsson.se.uab.ericsson.se (uabx04c384 [134.138.229.144]) by ms.uab.ericsson.se (8.10.0/8.10.0/uab-2.26) with ESMTP id e9NGJln10833 for ; Mon, 23 Oct 2000 18:19:48 +0200 (MET DST) Received: from uab.ericsson.se by uabx04c384.uab.ericsson.se.uab.ericsson.se (8.8.7/client-1.3uab1) id SAA06148; Mon, 23 Oct 2000 18:19:43 +0200 (MET DST) Message-ID: <39F4651B.72624396@uab.ericsson.se> From: Bertil Engelholm Organization: Ericsson Utvecklings AB X-Mailer: Mozilla 4.74C-CCK-MCD [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: sv,en-US MIME-Version: 1.0 To: sip@lists.bell-labs.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] multiple responses ?? Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 23 Oct 2000 18:19:39 +0200 Content-Transfer-Encoding: 7bit Hi, I have some questions regarding the possibility to forward best vs. forward all responses. First of all I wonder if this is not a function that should be decided by the UA e.g. by setting a special header ? It's the UA (the User) that knows if he like to get all responses and choose himself or let the network choose the best response. Why should each server take this decision ? Secondly I have a question regarding the proxy behaviour in the following case. ------ ------ | |----->| P2 |---->???? ------ | | ------ | Ca |----->| P1 | ------ | | ------ | |----->| P3 |---->???? ------ ------ If Ca calls someone at P1 which forks the call to P2 and P3 how should P1 behave in the following cases if it has the policy to fork the best response. If P2 (or someone behind P2) have the policy to fork all responses it means that P1 can get several final responses. Which of these reponses should be used in the best choice by P1 ? Only the first one that happens to arrive ? Everyone that arrives before you get a response from P3 ? What should be done with the rest of the responses that might drop in after you have sent your best response back ? You could actually have received an ACK back from Ca when another response drops in from P2. What to do in this case ? Is it allowed for P1 to terminate "extra" responses that drops in instead of forwarding them ? I becomes quite complicated in P1 if it e.g. controls a firewall. Suddenly a response arrives for a new CALL-LEG (the TO tag differs) which has no corresponding Request (the original request belongs to another CALL-LEG). This new response have to set up a path in the firewall so that Ca gets RTP addresses for this specific response. It can probably be done but you have to be careful so you don't open up holes in the firewall when you shouldn't. If would be much simplier if P1 could terminate any extra responses that might drop in. -- Bertil Engelholm AXE Research and Development voice : +46 8 727 3499 SIP Security Fax : +46 8 647 8276 S-126 25 Stockholm Sweden E-mail: Bertil.Engelholm@uab.ericsson.se _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 23 13:47:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA20512 for ; Mon, 23 Oct 2000 13:47:02 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E50254433A; Mon, 23 Oct 2000 12:47:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from elektron.elka.pw.edu.pl (elektron.elka.pw.edu.pl [194.29.160.2]) by lists.bell-labs.com (Postfix) with ESMTP id 76D7E44339 for ; Mon, 23 Oct 2000 12:46:28 -0400 (EDT) Received: from dial-barska11.warman.com.pl ([195.164.232.12]:1054 "EHLO elka.pw.edu.pl") by elektron.elka.pw.edu.pl with ESMTP id ; Mon, 23 Oct 2000 19:46:06 +0200 Message-ID: <39F47879.A40745F2@elka.pw.edu.pl> From: "Piotr S. Kossowski" Organization: Warsaw University of Technology - Institute of Telecommunications X-Mailer: Mozilla 4.7 [pl] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 Cc: sip@lists.bell-labs.com References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: unlisted-recipients: ; (no To-header on input) Subject: [SIP] Multi-message UDP datagrams (probably not specified behaviour) Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 23 Oct 2000 19:42:17 +0200 Content-Transfer-Encoding: 7bit Hello, After further studying of Multiple response per UDP datagram issue, and Content-Length header, I suppose that inaccuracy may appear. Scenario: first let's forget about single UAC that sends many messages in one datagram. Let's assume that in UDP datagram received by UAS there are two messages, however (perhaps, because of unique implementation of proxy that multiplexes messages to one datagram...). These messages may be not correlated and both did NOT contatin Content-Length, and both have correct syntax (and semantics, as well). Their orginators assumed that UAS would distinguish body from message according to section 6.18 of the spec: "(...)If a server receives a UDP request without Content-Length, it MUST assume that the request encompasses the remainder of the packet." So UAS starts parsing of message and it assumes that the body is to the end of the packet. And this is not true because such body will contain body from the first message and all the remainder: headers from the second message plus the second body etc. If behaviour of UAS would be different, please someone to explain it. I have also another question: Table 4 from section 6.4 of the spec. assumes for Content-Length in Methods to be "m*", what indicates that the header SHOULD be sent, but servers need to be prepared to receive requests without that header field. Is there any important reason for "m*" instead of "m" for this header ? Or this is only for avoiding of redundancy during sending messages that usually don't contatin body. If this header had status "mandatory always" we would avoid inaccuracy that I described above (if I'm right) Regards, Piotr _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 23 13:51:30 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA21511 for ; Mon, 23 Oct 2000 13:51:28 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E079D4437F; Mon, 23 Oct 2000 12:48:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id DB2FF44339 for ; Mon, 23 Oct 2000 12:47:24 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id NAA06171; Mon, 23 Oct 2000 13:49:29 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <4WS2XZMB>; Mon, 23 Oct 2000 13:43:22 -0400 Message-ID: From: Jonathan Rosenberg To: "'Bertil Engelholm'" , sip@lists.bell-labs.com Subject: RE: [SIP] multiple responses ?? MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 23 Oct 2000 13:43:21 -0400 > -----Original Message----- > From: Bertil Engelholm [mailto:Bertil.Engelholm@uab.ericsson.se] > Sent: Monday, October 23, 2000 12:20 PM > To: sip@lists.bell-labs.com > Subject: [SIP] multiple responses ?? > > > Hi, > > I have some questions regarding the possibility to forward > best vs. forward all responses. Forward all simply does not work. A proxy can forward one or more 200 responses (and indeed, really must forward all of them), since those are ACKed end to end. Non-200s are ACKed hop by hop. A proxy or client receiving multiple non-200 responses to the same request will have no way to distinguish them, and the state machines currently defined would not work. > > First of all I wonder if this is not a function that should > be decided by the UA e.g. by setting a special header ? Caller preferences addresses some simple cases where a UAC can request specific service from proxies. But, since forward-all-responses doesn't work, having a caller prefs value for it doesn't seem that useful. > It's the UA (the User) that knows if he like to get all > responses and choose himself or let the network choose the > best response. Why should each server take this decision ? We did it this way (forwarding only the best response) so that it would scale and work in a reasonable fashion. > > Secondly I have a question regarding the proxy behaviour in > the following case. > > ------ ------ > | |----->| P2 |---->???? > ------ | | ------ > | Ca |----->| P1 | > ------ | | ------ > | |----->| P3 |---->???? > ------ ------ > > If Ca calls someone at P1 which forks the call to P2 and P3 how > should P1 behave in the following cases if it has the policy to > fork the best response. > > If P2 (or someone behind P2) have the policy to fork all responses > it means that P1 can get several final responses. Only multiple 200. > Which of these > reponses should be used in the best choice by P1 ? > Only the first one that happens to arrive ? > Everyone that arrives before you get a response from P3 ? Beyond 200s, picking which is the best of the non-200 responses is defined by the spec (600, then 300, then 400, then 500 in that order). However, a proxy could choose an alternate definition of best amongst the non-200 final responses it gets, since there are no interoperability issues which choosing an alternate algorithm. > > What should be done with the rest of the responses that might drop > in after you have sent your best response back ? There should only ever be 200s, which are forwarded upstream. Anything else would be an error. > > You could actually have received an ACK back from Ca when another > response drops in from P2. What to do in this case ? Won't happen under correct operating conditions. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 23 13:59:14 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA23195 for ; Mon, 23 Oct 2000 13:59:14 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4461A443B8; Mon, 23 Oct 2000 12:55:06 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 35729443B5 for ; Mon, 23 Oct 2000 12:54:27 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id NAA06248; Mon, 23 Oct 2000 13:56:26 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <4WS2XZMR>; Mon, 23 Oct 2000 13:50:18 -0400 Message-ID: From: Jonathan Rosenberg To: "'Piotr S. Kossowski'" , unlisted-recipients Cc: sip@lists.bell-labs.com Subject: RE: [SIP] Multi-message UDP datagrams (probably not specified beh aviour) MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 23 Oct 2000 13:50:17 -0400 > -----Original Message----- > From: Piotr S. Kossowski [mailto:P.Kossowski@elka.pw.edu.pl] > Sent: Monday, October 23, 2000 1:42 PM > To: unlisted-recipients > Cc: sip@lists.bell-labs.com > Subject: [SIP] Multi-message UDP datagrams (probably not specified > behaviour) > > > > Hello, > > After further studying of Multiple response per UDP datagram issue, > and Content-Length header, I suppose that inaccuracy may appear. > > Scenario: first let's forget about single UAC that sends > many messages in one datagram. > Let's assume that in UDP datagram received by UAS there are > two messages, > however (perhaps, because of unique implementation of proxy that > multiplexes messages to one datagram...). These messages may > be not correlated and both did NOT contatin Content-Length, > and both have correct syntax (and semantics, as well). > Their orginators assumed that UAS would distinguish body > from message according to section 6.18 of the spec: > > "(...)If a server receives a UDP request without Content-Length, > it MUST assume that the request encompasses the remainder of > the packet." > > So UAS starts parsing of message and it assumes that the body > is to the end of the packet. And this is not true because > such body will contain body from the first message and all the > remainder: headers from the second message plus the second > body etc. Well, thats because the implementation that has sent multiple responses has erred. If it puts multiple responses in a packet it has to use Content-Length, else what you have described will happen. > I have also another question: > > Table 4 from section 6.4 of the spec. assumes for Content-Length > in Methods to be "m*", what indicates that the header SHOULD be sent, > but servers need to be prepared to receive requests without > that header > field. > > Is there any important reason for "m*" instead of "m" for > this header ? Yes. It was not mandatory in rfc2543. So, for backwards compatibility, you must be prepared to deal with that (of course, an rfc2543 implementation would still need to put CL in the response if it were sending multiple messages per datagram). --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 23 14:56:10 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA04597 for ; Mon, 23 Oct 2000 14:56:10 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 55E1B44369; Mon, 23 Oct 2000 13:56:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from thalia.fm.intel.com (thalia.fm.intel.com [132.233.247.11]) by lists.bell-labs.com (Postfix) with ESMTP id BF52044340 for ; Mon, 23 Oct 2000 13:55:48 -0400 (EDT) Received: from SMTP (fmsmsxvs04-1.fm.intel.com [132.233.42.204]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.32 2000/10/12 22:57:04 dmccart Exp $) with SMTP id SAA07880; Mon, 23 Oct 2000 18:56:28 GMT Received: from fmsmsx26.fm.intel.com ([132.233.48.26]) by 132.233.48.204 (Norton AntiVirus for Internet Email Gateways 1.0) ; Mon, 23 Oct 2000 18:55:12 0000 (GMT) Received: by fmsmsx26.fm.intel.com with Internet Mail Service (5.5.2650.21) id ; Mon, 23 Oct 2000 11:55:00 -0700 Message-ID: From: "Agarwal, Aseem" To: "'Jonathan Rosenberg'" , "'Piotr S. Kossowski'" , unlisted-recipients Cc: sip@lists.bell-labs.com Subject: RE: [SIP] Multi-message UDP datagrams (probably not specified beh aviour) MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 23 Oct 2000 11:54:51 -0700 Hi all, Is there a realistic situation where some implementation will send multiple messages in a single datagram ? If NOT, then is it not better to remove this source of confusion from the new version of the draft. Another related point is about transport of SIP messages using TCP. Since it is possible to receive partial or more than one SIP message in one TCP-recv() call, an implementation has to put in extra logic to determine the end of the message, e.g. find out the CRLF CRLF sequence, then check for Content-Length header, wait for the remaining bytes and so on.. One option may be to have an application level framing mechanism (something similar to TPKT -rfc 1006) to simplify things. What is the general opinion about this issue ? -regards, aseem -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Monday, October 23, 2000 10:50 AM To: 'Piotr S. Kossowski'; unlisted-recipients Cc: sip@lists.bell-labs.com Subject: RE: [SIP] Multi-message UDP datagrams (probably not specified beh aviour) > -----Original Message----- > From: Piotr S. Kossowski [mailto:P.Kossowski@elka.pw.edu.pl] > Sent: Monday, October 23, 2000 1:42 PM > To: unlisted-recipients > Cc: sip@lists.bell-labs.com > Subject: [SIP] Multi-message UDP datagrams (probably not specified > behaviour) > > > > Hello, > > After further studying of Multiple response per UDP datagram issue, > and Content-Length header, I suppose that inaccuracy may appear. > > Scenario: first let's forget about single UAC that sends > many messages in one datagram. > Let's assume that in UDP datagram received by UAS there are > two messages, > however (perhaps, because of unique implementation of proxy that > multiplexes messages to one datagram...). These messages may > be not correlated and both did NOT contatin Content-Length, > and both have correct syntax (and semantics, as well). > Their orginators assumed that UAS would distinguish body > from message according to section 6.18 of the spec: > > "(...)If a server receives a UDP request without Content-Length, > it MUST assume that the request encompasses the remainder of > the packet." > > So UAS starts parsing of message and it assumes that the body > is to the end of the packet. And this is not true because > such body will contain body from the first message and all the > remainder: headers from the second message plus the second > body etc. Well, thats because the implementation that has sent multiple responses has erred. If it puts multiple responses in a packet it has to use Content-Length, else what you have described will happen. > I have also another question: > > Table 4 from section 6.4 of the spec. assumes for Content-Length > in Methods to be "m*", what indicates that the header SHOULD be sent, > but servers need to be prepared to receive requests without > that header > field. > > Is there any important reason for "m*" instead of "m" for > this header ? Yes. It was not mandatory in rfc2543. So, for backwards compatibility, you must be prepared to deal with that (of course, an rfc2543 implementation would still need to put CL in the response if it were sending multiple messages per datagram). --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 23 15:05:09 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA06655 for ; Mon, 23 Oct 2000 15:05:08 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id DF1B244340; Mon, 23 Oct 2000 14:05:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from elektron.elka.pw.edu.pl (elektron.elka.pw.edu.pl [194.29.160.2]) by lists.bell-labs.com (Postfix) with ESMTP id 9FE3D44339 for ; Mon, 23 Oct 2000 14:04:55 -0400 (EDT) Received: from pm83.warszawa.cvx.ppp.tpnet.pl ([213.76.108.83]:1042 "EHLO elka.pw.edu.pl") by elektron.elka.pw.edu.pl with ESMTP id ; Mon, 23 Oct 2000 21:04:39 +0200 Message-ID: <39F48BE0.756CC279@elka.pw.edu.pl> From: "Piotr S. Kossowski" Organization: Warsaw University of Technology - Institute of Telecommunications X-Mailer: Mozilla 4.7 [pl] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Multi-message UDP datagrams (probably not specified behaviour) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 23 Oct 2000 21:05:04 +0200 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > > Well, thats because the implementation that has sent multiple responses has > erred. If it puts multiple responses in a packet it has to use > Content-Length, else what you have > described will happen. If an orginator of multiple messages was rfc2543-compatibile entity, not using of C-L was allowed, as you wrote. Saying "erred" did you mean "not according to rfc2543BIS recommendation"? Piotr _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 23 17:15:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA25333 for ; Mon, 23 Oct 2000 17:15:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1EE494433A; Mon, 23 Oct 2000 16:15:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from localhost.localdomain (unknown [205.181.177.150]) by lists.bell-labs.com (Postfix) with ESMTP id C51D244339 for ; Mon, 23 Oct 2000 15:44:32 -0400 (EDT) Received: (from kaz@localhost) by localhost.localdomain (8.9.3/8.9.3) id QAA20062 for sip@lists.bell-labs.com; Mon, 23 Oct 2000 16:44:28 -0400 From: Pete Kazmier To: sip@lists.bell-labs.com Message-ID: <20001023164428.B19549@ibasis.net> Reply-To: pkazmier@ibasis.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i Followup-To: pkazmier@ibasis.net Subject: [SIP] The 'Allow' entity header in rfc2543bis-02 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 23 Oct 2000 16:44:28 -0400 Section 4.2.1 (INVITE), 3rd paragraph from the end, states: The initial INVITE from the UAC SHOULD contain the Allow and Supported header fields, and MAY contain the Accept header field. Then, section 6.10 (Allow) states: An Allow header field MUST be present in a 405 (Method Not Allowed) response, SHOULD be present in an OPTIONS response SHOULD be present in the 200 (OK) response to the initial INVITE for a call and MAY be present in final responses for other methods. Its unclear to me if the 'Allow' entity header SHOULD be in the initial INVITE. Section 4.2.1 states that it should be, but section 6.10 doesn't mention it. Could someone please clarify? Thanks, Pete -- Pete Kazmier (781) 505-7590 Senior Network Systems Engineer pkazmier@ibasis.net iBasis http://www.ibasis.net _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 23 17:32:08 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA27281 for ; Mon, 23 Oct 2000 17:32:02 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6D8264433B; Mon, 23 Oct 2000 16:32:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from broadsoft.com (broadsoft.com [161.58.239.68]) by lists.bell-labs.com (Postfix) with ESMTP id CBE3144339 for ; Mon, 23 Oct 2000 16:31:47 -0400 (EDT) Received: from tate ([216.181.56.35]) by broadsoft.com (8.8.8) id RAA10220; Mon, 23 Oct 2000 17:31:42 -0400 (EDT) Message-ID: <004401c03d38$d4cb73a0$3202a8c0@broadsoft.com> From: "Brett Tate" To: , References: <20001023164428.B19549@ibasis.net> Subject: Re: [SIP] The 'Allow' entity header in rfc2543bis-02 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: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 23 Oct 2000 17:33:05 -0400 Content-Transfer-Encoding: 7bit See thread "rfc2543bis-02 table 4 comment". Henning mentions that the "Allow" can be included in all requests. ----- Original Message ----- From: Pete Kazmier To: Sent: Monday, October 23, 2000 4:44 PM Subject: [SIP] The 'Allow' entity header in rfc2543bis-02 > Section 4.2.1 (INVITE), 3rd paragraph from the end, states: > > The initial INVITE from the UAC SHOULD contain the Allow and > Supported header fields, and MAY contain the Accept header > field. > > Then, section 6.10 (Allow) states: > > An Allow header field MUST be present in a 405 (Method Not > Allowed) response, SHOULD be present in an OPTIONS response > SHOULD be present in the 200 (OK) response to the initial INVITE > for a call and MAY be present in final responses for other > methods. > > Its unclear to me if the 'Allow' entity header SHOULD be in the > initial INVITE. Section 4.2.1 states that it should be, but section > 6.10 doesn't mention it. Could someone please clarify? > > Thanks, > Pete > > -- > Pete Kazmier (781) 505-7590 > Senior Network Systems Engineer pkazmier@ibasis.net > iBasis http://www.ibasis.net > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 23 17:48:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA29119 for ; Mon, 23 Oct 2000 17:48:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1AA534433A; Mon, 23 Oct 2000 16:48:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by lists.bell-labs.com (Postfix) with ESMTP id 0825044339 for ; Mon, 23 Oct 2000 16:47:30 -0400 (EDT) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id C865D4CE14 for ; Mon, 23 Oct 2000 17:47:23 -0400 (EDT) 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 RAA27023 for ; Mon, 23 Oct 2000 17:47:23 -0400 (EDT) From: William Marshall Received: (from wtm@localhost) by fish-ha.research.att.com (980427.SGI.8.8.8/8.8.5) id RAA27966 for sip@lists.bell-labs.com; Mon, 23 Oct 2000 17:47:23 -0400 (EDT) Message-Id: <200010232147.RAA27966@fish-ha.research.att.com> To: gonzalo.camarillo@lmf.ericsson.se, jdrosen@dynamicsoft.com Cc: sip@lists.bell-labs.com Subject: FW: [SIP] Feedback on manyfolks Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 23 Oct 2000 17:47:23 -0400 (EDT) This discussion took me a little while to figure out, because there was clearly something missing in the manyfolks draft that I wasn't seeing. The current manyfolks draft shows two examples, one where a confirmation is requested by the UAS from the UAC, and one where two confirmations are requested, first by the UAC from the UAS, then by the UAS from the UAC. However, (and the part I missed several times re-re-re-reading the draft), the wording of the spec also allows the UAC to request a confirmation from the UAS without the UAS requesting a confirmation from the UAC. This seems pointless. |----(1)INVITE------->| |<---(2)183-----------| |----(3)PRACK-------->| |<---(4)200-----------| |<---(5)COMET---------| |----(6)200---------->| |<---(7)180-----------| If message (1)INVITE includes a request for a confirmation, i.e. (5)COMET, but message (2)183 does not also request a confirmation, then there is nothing the UAC can do upon receipt of the (5)COMET. The UAS is already doing the alerting and the (7)180 is probably already on its way. The fact that (7)180 is sent indicates the resource preconditions were met by UAS, because otherwise it would have responded with a 580-precondition-failure response. So why even bother with (5)COMET? My original intention in writing the procedures for the two-way COMET exchange was that it be triggered by the UAC requesting a confirmation. The UAS, on receipt of a SDP containing a precondition line with a confirmation request, MUST include a precondition line in its SDP with a confirmation request. This text doesn't appear, and would solve the problem presented by third party call control. Did anyone see a case where the one-way confirmation shown in the diagram above was actually useful and should be allowed? Otherwise, I think we should add the requirement on UAS behavior. If the response to the INVITE(with confirmation requested) is a 180, or a 183 without a precondition line, it indicates the UAS doesn't support the resource extension. A 183 response with a precondition line that doesn't include a confirmation would also, in this case, indicate lack support of the UAS (or lack of sanity). Bill Marshall wtm@research.att.com -----Original Message----- From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] Sent: Thursday, October 12, 2000 1:38 AM To: Jonathan Rosenberg Cc: 'sip' Subject: Re: [SIP] Feedback on manyfolks Hi, I agree. This is getting pretty complex. Anyway, for this specific matter we have three choices: 1) COMET is always mandatory in both directions. It does not matter if the preconditions are mandatory or optional. 2) COMET is mandatory just when the preconditions are mandatory. 3) COMET is just sent when requested by any of the parties. This would be the mechanism used so far (with the extension defined in draft-camarillo-manyfolks-confirm-00.txt) Approach number 1 is the simplest. After doing whatever in order to fulfil the preconditions a COMET is sent. Number 2 is also pretty simple. If the preconditions were mandatory, the session is stopped until the COMET is sent. If the preconditions were optional the session establishment goes on, so no COMET is sent. The gain of approach number 3 is that it saves some messages. However, as you pointed out, they are not a lot. In the most common situation it would save 2 messages (1 RTT). This is when A calls B in a two-party session where there is just one COMET from A towards B. The COMET from B to A is not normally needed since B just begins alerting the user once the preconditions are met. So, we have a little more complexity for a little gain. My only concern is the amonut of signalling messages that we already have for establishing a session using preconditions (PRACKs, COMETs). A RTT for a workstation in an ethernet is not a big deal, but for a terminal using a cellular access begins to be more important. Anyway, I do not have a religious position here, so any of the 3 solutions is alright for me. Let's pick one and go on resolving different issues. Opinions? Regards, Gonzalo Jonathan Rosenberg wrote: > > Its just thats its more options, more complexities ontop of a thing which is > growing more and more complex. We need to remove options, not add them. I > don't see what they need is for the negotiation. We need to justify the > existence of it, not the elimination of it. > > -Jonathan R. > > --- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > > -----Original Message----- > > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > Sent: Tuesday, October 10, 2000 10:46 AM > > To: Jonathan Rosenberg > > Cc: 'sip' > > Subject: Re: [SIP] Feedback on manyfolks > > > > > > Hi, > > > > Certainly we are not talking about tons of messages. However, in this > > case I would rather let the confim be negotiated. The negotiation is > > rather simple. > > > > The UAC can request: > > 1) No COMET > > 2) one COMET UAC->UAS > > 3) one COMET UAC- > 4) two COMETs > > > > The UAS should accept what the UAC requests, and possibly request more > > (e.g. two COMETs when the UAC just requested one). > > > > I believe this is not a complicated mechanism. It is just a > > deterministic two-way handshake. > > > > Best regards, > > > > Gonzalo > > > > > > > > Jonathan Rosenberg wrote: > > > > > > This seems reasonable to me, and needed, as Gonzalo points out. > > > > > > My only issue is whether all this stuff should be optional > > at all. Wouldn't > > > it be easier if both sides always sent COMET, period? All > > this negotiation > > > stuff is a pain. We're not talking tons of messages here. > > Can't we keep it > > > simple? > > > > > > -Jonathan R. > > > > > > --- > > > Jonathan D. Rosenberg 72 Eagle Rock Ave. > > > Chief Scientist First Floor > > > dynamicsoft East Hanover, NJ 07936 > > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > > > http://www.dynamicsoft.com > > > > > > > -----Original Message----- > > > > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > > > Sent: Monday, October 09, 2000 2:33 AM > > > > To: sip > > > > Subject: [SIP] Feedback on manyfolks > > > > > > > > > > > > Hi, > > > > > > > > Here you have a new I-D that contains feedback on the > > manyfolks draft. > > > > > > > > http://search.ietf.org/internet-drafts/draft-camarillo-manyfol > > > > ks-confirm-00.txt > > > > > > > > " > > > > Abstract > > > > > > > > This document describes certain functionality that is > > > > missing in the > > > > current "Integration of Resource Management and SIP" > > [1] (a.k.a. > > > > manyfolks draft). An extension to add this functionality is > > > > outlined. > > > > > > > > This functionality is needed in general to provide richer > > > > signalling > > > > capabilities and can be employed in several scenarios. > > This draft > > > > describes its use in third party call control applications. > > > > > > > > If this extension is accepted it is foreseen that this > > draft would > > > > be merged with [1]. > > > > " > > > > > > > > Best regards, > > > > > > > > Gonzalo > > > > -- > > > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > > > Telecom R&D Fax : +358 9 299 30 52 > > > > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > > > > Finland http://www.hut.fi/~gonzalo > > > > > > > > _______________________________________________ > > > > SIP mailing list > > > > SIP@lists.bell-labs.com > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > -- > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > Telecom R&D Fax : +358 9 299 30 52 > > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > > Finland http://www.hut.fi/~gonzalo > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland http://www.hut.fi/~gonzalo _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 23 19:34:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA11143 for ; Mon, 23 Oct 2000 19:34:02 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2AB424433A; Mon, 23 Oct 2000 18:34:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from thalia.fm.intel.com (thalia.fm.intel.com [132.233.247.11]) by lists.bell-labs.com (Postfix) with ESMTP id CAC0344339 for ; Mon, 23 Oct 2000 18:33:06 -0400 (EDT) Received: from SMTP (fmsmsxvs05-1.fm.intel.com [132.233.42.205]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.32 2000/10/12 22:57:04 dmccart Exp $) with SMTP id XAA21210 for ; Mon, 23 Oct 2000 23:34:07 GMT Received: from fmsmsx28.fm.intel.com ([132.233.48.28]) by 132.233.48.205 (Norton AntiVirus for Internet Email Gateways 1.0) ; Mon, 23 Oct 2000 23:32:51 0000 (GMT) Received: by fmsmsx28.fm.intel.com with Internet Mail Service (5.5.2650.21) id ; Mon, 23 Oct 2000 16:32:50 -0700 Message-ID: From: "Schmidlin, David" To: sip@lists.bell-labs.com MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] Location Servers Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 23 Oct 2000 16:32:34 -0700 Does anyone know where you can download an eval copy of a Location Server or if there are any public location servers that can be used? Thanks, Dave _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 23 21:20:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA23051 for ; Mon, 23 Oct 2000 21:20:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id EE4AE4433B; Mon, 23 Oct 2000 20:20:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from smtp-out1.bellatlantic.net (smtp-out1.bellatlantic.net [199.45.39.156]) by lists.bell-labs.com (Postfix) with ESMTP id 5DD7C4433A for ; Mon, 23 Oct 2000 20:20:00 -0400 (EDT) Received: from cs.columbia.edu (adsl-151-198-20-48.nnj.adsl.bellatlantic.net [151.198.20.48]) by smtp-out1.bellatlantic.net (8.9.1/8.9.1) with ESMTP id VAA29044; Mon, 23 Oct 2000 21:19:02 -0400 (EDT) Message-ID: <39F4E36F.14B6738A@cs.columbia.edu> From: Henning Schulzrinne X-Mailer: Mozilla 4.7 [en]C-CCK-MCD BA45DSL (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Schmidlin, David" Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Location Servers References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 23 Oct 2000 21:18:39 -0400 Content-Transfer-Encoding: 7bit Location servers are generally not separate entities that make sense without an associated proxy or redirect server. We have built a set of "location servers" that use various pieces of login and 'finger' information, for example, but it probably only works with our server, or within a sip-cgi server. Pointers to implementations of proxy servers can be found at http://www.cs.columbia.edu/sip "Schmidlin, David" wrote: > > Does anyone know where you can download an eval copy of a Location Server or > if > there are any public location servers that can be used? > > Thanks, > Dave > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 24 03:50:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA01712 for ; Tue, 24 Oct 2000 03:50:02 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 110924433B; Tue, 24 Oct 2000 02:50:06 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lists.bell-labs.com (Postfix) with ESMTP id 990224433A for ; Tue, 24 Oct 2000 02:49:17 -0400 (EDT) Received: from esealnt409.al.sw.ericsson.se (esealnt409.al.sw.ericsson.se [153.88.251.32]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id e9O7nCZ16686 for ; Tue, 24 Oct 2000 09:49:12 +0200 (MEST) Received: FROM esealnt743.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Tue Oct 24 09:49:05 2000 +0200 Received: by esealnt743.al.sw.ericsson.se with Internet Mail Service (5.5.2651.58) id <4Z87QGL6>; Tue, 24 Oct 2000 09:49:06 +0200 Message-ID: <56E7307B0850D411B1480008C75DD5EAB73D4A@enlrynt303.dsn.ericsson.se> From: "Arnoud van Wijk (ELN)" To: "'Agarwal, Aseem'" , "'Jonathan Rosenberg'" , "'Piotr S. Kossowski'" Cc: sip@lists.bell-labs.com Subject: RE: [SIP] Multi-message UDP datagrams (probably not specified beh aviour) MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 24 Oct 2000 09:48:59 +0200 I was watching this thread with interest. It is indeed a good question if there is an implementation that sends multiple messages in one single datagram. I think that it is possible. Perhaps some dedicated SIP server that has to send many small messages to a centrally located SIP proxy. Thus instead of sending 40 UDP packets, it may be possible to place them all inside just one datagram (message size depending ofcourse). So I would in this case make the Content-Length mandatory for that server. Splitting SIP messages over 2 or more datagrams for TCP would not matter at all since the message would be pieced together in one whole piece. Thanks to TCP, right? (just as long that the Content-Length is given, the server knows where the new message starts) In my opinion, I think that this is just a case of UA behaviour and not SIP. What I would suggest is thus that Content-Length has to be mandatory for UAS or UAC that put multiple messages in one UDP datagram. And then if there is no Content-Length given, the receiving UA can then act as in the RFC "(...)If a server receives a UDP request without Content-Length, it MUST assume that the request encompasses the remainder of the packet." Maybe it is a good idea to add to the bis-draft that Content-Length MUST be included by the UA when there are Multiple messages placed into one UDP datagram. AND when messages are (likely) to be split over 2 or more datagrams. Just my 2 Euro cents :-) Arnoud _______________________________________________________________ ERICSSON EUROLABS NETHERLANDS BV Arnoud van Wijk ABACUS Lab Research & Development (ELN/V) Fax: +31-161 247569 _______________________________________________________________ -----Original Message----- From: Agarwal, Aseem [mailto:aseem@trillium.com] Sent: maandag 23 okt 2000 20:55 To: 'Jonathan Rosenberg'; 'Piotr S. Kossowski'; unlisted-recipients Cc: sip@lists.bell-labs.com Subject: RE: [SIP] Multi-message UDP datagrams (probably not specified beh aviour) Hi all, Is there a realistic situation where some implementation will send multiple messages in a single datagram ? If NOT, then is it not better to remove this source of confusion from the new version of the draft. Another related point is about transport of SIP messages using TCP. Since it is possible to receive partial or more than one SIP message in one TCP-recv() call, an implementation has to put in extra logic to determine the end of the message, e.g. find out the CRLF CRLF sequence, then check for Content-Length header, wait for the remaining bytes and so on.. One option may be to have an application level framing mechanism (something similar to TPKT -rfc 1006) to simplify things. What is the general opinion about this issue ? -regards, aseem -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Monday, October 23, 2000 10:50 AM To: 'Piotr S. Kossowski'; unlisted-recipients Cc: sip@lists.bell-labs.com Subject: RE: [SIP] Multi-message UDP datagrams (probably not specified beh aviour) > -----Original Message----- > From: Piotr S. Kossowski [mailto:P.Kossowski@elka.pw.edu.pl] > Sent: Monday, October 23, 2000 1:42 PM > To: unlisted-recipients > Cc: sip@lists.bell-labs.com > Subject: [SIP] Multi-message UDP datagrams (probably not specified > behaviour) > > > > Hello, > > After further studying of Multiple response per UDP datagram issue, > and Content-Length header, I suppose that inaccuracy may appear. > > Scenario: first let's forget about single UAC that sends > many messages in one datagram. > Let's assume that in UDP datagram received by UAS there are > two messages, > however (perhaps, because of unique implementation of proxy that > multiplexes messages to one datagram...). These messages may > be not correlated and both did NOT contatin Content-Length, > and both have correct syntax (and semantics, as well). > Their orginators assumed that UAS would distinguish body > from message according to section 6.18 of the spec: > > "(...)If a server receives a UDP request without Content-Length, > it MUST assume that the request encompasses the remainder of > the packet." > > So UAS starts parsing of message and it assumes that the body > is to the end of the packet. And this is not true because > such body will contain body from the first message and all the > remainder: headers from the second message plus the second > body etc. Well, thats because the implementation that has sent multiple responses has erred. If it puts multiple responses in a packet it has to use Content-Length, else what you have described will happen. > I have also another question: > > Table 4 from section 6.4 of the spec. assumes for Content-Length > in Methods to be "m*", what indicates that the header SHOULD be sent, > but servers need to be prepared to receive requests without > that header > field. > > Is there any important reason for "m*" instead of "m" for > this header ? Yes. It was not mandatory in rfc2543. So, for backwards compatibility, you must be prepared to deal with that (of course, an rfc2543 implementation would still need to put CL in the response if it were sending multiple messages per datagram). --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 24 04:06:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA05136 for ; Tue, 24 Oct 2000 04:06:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7923E443C2; Tue, 24 Oct 2000 03:06:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lists.bell-labs.com (Postfix) with ESMTP id B4233443C1 for ; Tue, 24 Oct 2000 03:05:47 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id e9O85ft09362 for ; Tue, 24 Oct 2000 10:05:42 +0200 (MEST) 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 LAA12811 for ; Tue, 24 Oct 2000 11:05:41 +0300 (EET DST) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.73]) by greymse1.lmf.ericsson.se (8.9.3 (PHNE_18979)/8.8.6) with ESMTP id LAA26849 for ; Tue, 24 Oct 2000 11:05:39 +0300 (EETDST) Message-ID: <39F542D0.714157FC@lmf.ericsson.se> From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Content-Type: multipart/mixed; boundary="------------6CB859DA8B1743D1212B2E97" Subject: [SIP] Redirect server returning new From header Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 24 Oct 2000 11:05:36 +0300 This is a multi-part message in MIME format. --------------6CB859DA8B1743D1212B2E97 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Another proposal on the issue, with another use of the "Also-From" header. Currently, a redirect server add a new Request-URI (in the 3xx response Contact header) to the UAC. An idea would be that it could also return a new From header, for example with a telephone number. In this case, the UAC, and intermediate proxies, would not need to insert any extra headers or URI parameters in the request. This would be a new, optional, feature in a redirect server. Comments? Christer Holmberg Ericsson Finland --------------6CB859DA8B1743D1212B2E97 Content-Type: text/x-vcard; charset=us-ascii; name="christer.holmberg.vcf" Content-Description: Card for Christer Holmberg Content-Disposition: attachment; filename="christer.holmberg.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Holmberg;Christer tel;cell:+358-40-5604412 tel;work:+358-9-2992943 x-mozilla-html:FALSE org:Ericsson;Advanced Signalling Research Laboratory adr:;;;;;; version:2.1 email;internet:christer.holmberg@lmf.ericsson.se title:System Designer fn:Christer Holmberg end:vcard --------------6CB859DA8B1743D1212B2E97-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 24 04:11:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA06213 for ; Tue, 24 Oct 2000 04:11:00 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 24AE1443C8; Tue, 24 Oct 2000 03:11:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from drago1.ubiquity.net (unknown [194.202.146.92]) by lists.bell-labs.com (Postfix) with SMTP id C534E443C2 for ; Tue, 24 Oct 2000 03:10:12 -0400 (EDT) Received: from gecko.ubiquity.co.uk by drago1.ubiquity.net via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 24 Oct 2000 08:10:44 UT Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id JAA20222; Tue, 24 Oct 2000 09:08:33 +0100 (BST) From: "Jo Hornsby" To: "Bertil Engelholm" , Subject: RE: [SIP] loop detection ?? Message-ID: <001901c03d91$99e15e90$4e34c3c1@ubiquity.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 In-Reply-To: <39F44E4B.51E649@uab.ericsson.se> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 24 Oct 2000 09:08:32 +0100 Content-Transfer-Encoding: 7bit > I have a question regarding loop detection. > > In the description of VIA-headers it says that the loop detection > value MAY be a hash of TO,FROM,CALL-ID,CSEQ and REQUEST-URI. > > So I wonder if it's not enough to only use the REQUEST-URI. Yes. Technically, the branch parameter must be a function of the Request-URI, but this is the only component of a message that must be used. > there exist cases where someone changes any of the other fields > (and thereby change CALL-LEG) and continues with the VIA-list > that existed before the change ? Is this allowed ? This is sort of allowed, although the entity that did this would not be a proxy (more like a B2BUA). In such cases, all bets would be off (it might have also changed the Vias, thus it becomes impossible to detect loops in such cases). > If someone does this I guess they have to be prepared to change > the values back when the response is sent back. Otherwise the > caller will not be able to recognise the CALL-LEG ? Very much so. - Jo. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 24 04:26:28 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA09478 for ; Tue, 24 Oct 2000 04:26:28 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E71B8443C0; Tue, 24 Oct 2000 03:22:14 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mail.speedventures.com (unknown [212.75.74.99]) by lists.bell-labs.com (Postfix) with ESMTP id 9EB5F4433A for ; Tue, 24 Oct 2000 03:21:05 -0400 (EDT) Received: from HASH ([192.168.27.104]) by mail.speedventures.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id V22M5ST8; Tue, 24 Oct 2000 10:17:11 +0200 From: "Hisham Khartabil" To: "Schmidlin, David" , Subject: RE: [SIP] Location Servers Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 24 Oct 2000 11:20:27 +0300 Content-Transfer-Encoding: 7bit Hi, Check out www.openldap.org Regards, Hisham -----Original Message----- From: sip-admin@lists.bell-labs.com [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Schmidlin, David Sent: 24. lokakuuta 2000 2:33 To: sip@lists.bell-labs.com Subject: [SIP] Location Servers Does anyone know where you can download an eval copy of a Location Server or if there are any public location servers that can be used? Thanks, Dave _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 24 04:32:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA10662 for ; Tue, 24 Oct 2000 04:32:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 829124436F; Tue, 24 Oct 2000 03:32:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mars.hss.co.in (unknown [202.54.26.197]) by lists.bell-labs.com (Postfix) with ESMTP id 2E3374434F for ; Tue, 24 Oct 2000 03:31:24 -0400 (EDT) Received: from sampark.hss.hns.com (sampark [139.85.229.22]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id e9O8UnC23320; Tue, 24 Oct 2000 14:00:50 +0530 (IST) Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 65256982.002F0DB0 ; Tue, 24 Oct 2000 14:03:56 +0530 X-Lotus-FromDomain: HSSBLR From: archow@hss.hns.com To: "Arnoud van Wijk (ELN)" Cc: "'Agarwal, Aseem'" , "'Jonathan Rosenberg'" , "'Piotr S. Kossowski'" , sip@lists.bell-labs.com Message-ID: <65256982.002F0D4A.00@sampark.hss.hns.com> Subject: RE: [SIP] Multi-message UDP datagrams (probably not specified behaviour) Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 24 Oct 2000 14:03:55 +0530 Arnoud> In my opinion, I think that this is just a case of UA Arnoud> behaviour and not SIP. What I would suggest is thus that Arnoud> Content-Length has to be mandatory for UAS or UAC that Arnoud> put multiple messages in one UDP datagram. Arnoud> And then if there is no Content-Length given, the Arnoud> receiving UA can then act as in the RFC "(...)If a server receives a Arnoud> UDP request without Content-Length, it MUST assume that the Arnoud> request encompasses the remainder of the packet." Arnoud> Maybe it is a good idea to add to the bis-draft that Arnoud> Content-Length MUST be included by the UA when there are Arnoud> Multiple messages placed into one UDP datagram. AND when Arnoud> messages are (likely) to be split over 2 or more datagrams. Actually the presence of Content-Length for multiple message in a UDP packet, although not explictly mentioned in the draft seems to be implicitly stated by the para: (pg 45, 6.18) "If a response does not contain a Content-Length, the client assumes that it encompasses the remainder of the UDP packet or the data until the TCP connection is closed, as applicable." This means that if the sender did want to send multiple messages in a UDP message, if he did not specify a content-length, the recipient would treat it as one full message anyway, and probably throw an error if he tried to parse the body or at best include the entire bunched messages as one body (incase the Content-Type said some body type which the recipient did not understand), which is not something the sender wanted in anycase. So if you wanted the recipient to interpret it as multiple messages, this para seems to state you dont have any other option but content-length . Arnoud> Splitting SIP messages over 2 or more datagrams for TCP Arnoud> would not matter at all since the message would be pieced Arnoud> together in one whole piece. Thanks to TCP, right? (just Arnoud> as long that the Content-Length is given, the server knows where Arnoud> the new message starts) Not directly related to your point, but here goes: My main point of concern with TCP is more to do with the buffer the user specifies while reception. My worry is more to do with application reassembling rather than TCP/IP stack re-assembing. The current logic of finding out message length for TCP is read a buffer, grep for Content-Length,say value X. if bytesRead < X read X-bytesRead more bytes, cat it as a complete message and then go ahead to do a parse. However, what if the recipient does a read() with a buffer B. It is possible that in the first read, he does not get the content-length header. Or maybe he gets half of it. Then what does he do ? He has to add more code to handle these scenarios just to ensure that he has the complete message. All this stems from the fact that the header that actually may specify length of the message can occur anywhere in between the header section. So, the user can never be sure that there will not be a scenario where he cannot figure out the length of the message after the first read(). Also in this method, his read buffer must be large enough to accomodate the first content-length header - which is a heuristic value.Since he does not know how big a message is, he cannot do an alloc just for that much (if he wants to). Things are relatively fine if we assume that the first read gets the complete C-Len header. All this could be avoided if for stream oriented protocols we have a concept similar to TPKT. I think this point has been raised several times, but it was decided not to do anything similar to TPKT. The bad part is that this makes is protocol specific. Good part is that it avoids these application level re-assembling worries. So the question is, how important is each, relatively ? I would like some comments from other implementors too - do you find the existing mechanism sufficient for you, do you find it inappropriate, or is there a neat solution which someone has out there which you can share ? Regds Arjun _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 24 05:17:00 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA20253 for ; Tue, 24 Oct 2000 05:17:00 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B854144342; Tue, 24 Oct 2000 04:17:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 50E674433A for ; Tue, 24 Oct 2000 04:16:53 -0400 (EDT) Received: from dynamicsoft.com (ip25.honxr1.ras.tele.dk [195.249.119.25]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id FAA11504; Tue, 24 Oct 2000 05:18:58 -0400 (EDT) Message-ID: <39F552ED.F598C9DF@dynamicsoft.com> From: Anders Kristensen Organization: dynamicsoft X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 To: Christer Holmberg Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Redirect server returning new From header References: <39F542D0.714157FC@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 24 Oct 2000 11:14:21 +0200 Content-Transfer-Encoding: 7bit Christer Holmberg wrote: > > Another proposal on the issue, with another use of the "Also-From" > header. > > Currently, a redirect server add a new Request-URI (in the 3xx response > Contact header) to the UAC. An idea would be that it could also return a > new From header, for example with a telephone number. In this case, the > UAC, and intermediate proxies, would not need to insert any extra > headers or URI parameters in the request. This would be a new, optional, > feature in a redirect server. A registrar is free to return SIP, tel:, mailto:, http: and any other kind of URLs in Contacts. Whatever it is you think you need the extra From for I think you'll find you can use Contact for. Anders _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 24 05:39:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA24940 for ; Tue, 24 Oct 2000 05:39:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7541D44349; Tue, 24 Oct 2000 04:39:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lists.bell-labs.com (Postfix) with ESMTP id BDC5144342 for ; Tue, 24 Oct 2000 04:38:50 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id e9O9cit04846; Tue, 24 Oct 2000 11:38:44 +0200 (MEST) 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 MAA20142; Tue, 24 Oct 2000 12:38:44 +0300 (EET DST) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.73]) by greymse1.lmf.ericsson.se (8.9.3 (PHNE_18979)/8.8.6) with ESMTP id MAA21371; Tue, 24 Oct 2000 12:38:34 +0300 (EETDST) Message-ID: <39F55897.402E7881@lmf.ericsson.se> From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Cc: sean.olson@ericsson.com Subject: Re: [SIP] Redirect server returning new From header References: <39F542D0.714157FC@lmf.ericsson.se> <39F54B2E.F3704BFA@ericsson.com> Content-Type: multipart/mixed; boundary="------------D2C37324FDDB2E545FCCF3F1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 24 Oct 2000 12:38:31 +0300 This is a multi-part message in MIME format. --------------D2C37324FDDB2E545FCCF3F1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, >Do you actually mean the From: or do you mean the To:? From. >It seems a bit odd for a redirect server to tell the UAC what >From: to use. Perhaps you could give an example of its usage. Well, this is - once again - related to the PSTN/SIP GW issue, if the GW needs a telephone number for some kind of A number analysis. When I make a phone call from my SIP phone I may not know that the call may end up on the PSTN side, so I can for example put my email address in the From header. However, since the network architecture includes a GW to the PSTN network, somewhere there could be a server which is able to do the mapping between the email address user part and a telephone number user part (if SIP URL is used). Regards, Christer Holmberg Ericsson Finland > > Regards, > Sean > > -- > Sean Olson > > Christer Holmberg wrote: > > > Another proposal on the issue, with another use of the "Also-From" > > header. > > > > Currently, a redirect server add a new Request-URI (in the 3xx response > > Contact header) to the UAC. An idea would be that it could also return a > > new From header, for example with a telephone number. In this case, the > > UAC, and intermediate proxies, would not need to insert any extra > > headers or URI parameters in the request. This would be a new, optional, > > feature in a redirect server. > > > > Comments? > > > > Christer Holmberg > > Ericsson Finland --------------D2C37324FDDB2E545FCCF3F1 Content-Type: text/x-vcard; charset=us-ascii; name="christer.holmberg.vcf" Content-Description: Card for Christer Holmberg Content-Disposition: attachment; filename="christer.holmberg.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Holmberg;Christer tel;cell:+358-40-5604412 tel;work:+358-9-2992943 x-mozilla-html:FALSE org:Ericsson;Advanced Signalling Research Laboratory adr:;;;;;; version:2.1 email;internet:christer.holmberg@lmf.ericsson.se title:System Designer fn:Christer Holmberg end:vcard --------------D2C37324FDDB2E545FCCF3F1-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 24 06:50:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA11792 for ; Tue, 24 Oct 2000 06:50:03 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 14F3844349; Tue, 24 Oct 2000 05:50:06 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from qnsgs000.nortel.com (qnsgs000.nortelnetworks.com [47.211.0.31]) by lists.bell-labs.com (Postfix) with ESMTP id 4177644342 for ; Tue, 24 Oct 2000 05:48:45 -0400 (EDT) Received: from zhard00m.europe.nortel.com (actually zhard00m) by qnsgs000.nortel.com; Tue, 24 Oct 2000 11:46:48 +0100 Received: by zhard00m.europe.nortel.com with Internet Mail Service (5.5.2652.35) id ; Tue, 24 Oct 2000 11:46:46 +0100 Message-ID: <61ABD11436FED21192440000F81F3E360304C3AE@nwcwi1a.europe.nortel.com> From: "Mark Watson" To: "'William Marshall'" , gonzalo.camarillo@lmf.ericsson.se, jdrosen@dynamicsoft.com Cc: sip@lists.bell-labs.com Subject: RE: [SIP] Feedback on manyfolks MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C03DA7.AEE6ADC0" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 24 Oct 2000 11:46:36 +0100 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_01C03DA7.AEE6ADC0 Content-Type: text/plain; charset="ISO-8859-1" Good point. What is the point of the UAS to UAC COMET at all ? If you need two-way confirmation of resource reservation, won't the 180 provide the backwards confirmation in all cases ? The point about resource reservation is that the progress of the session - which has a definate direction UAC -> UAS - needs to be delayed pending completion of the reservation. Once it has received the INVITE, it is the UAS which is in control of the session progress. The UAS knows for itself when it has completed its local preconditions, so surely the only precondition-met signalling which is needed it forwards, from UAC to UAS ? Regards, Mark Watson Nortel Networks > -----Original Message----- > From: William Marshall [mailto:wtm@research.att.com] > Sent: 23 October 2000 22:47 > To: gonzalo.camarillo@lmf.ericsson.se; jdrosen@dynamicsoft.com > Cc: sip@lists.bell-labs.com > Subject: FW: [SIP] Feedback on manyfolks > > > This discussion took me a little while to figure out, because there > was clearly something missing in the manyfolks draft that I wasn't > seeing. > > The current manyfolks draft shows two examples, one where a > confirmation > is requested by the UAS from the UAC, and one where two confirmations > are requested, first by the UAC from the UAS, then by the UAS > from the UAC. > > However, (and the part I missed several times > re-re-re-reading the draft), > the wording of the spec also allows the UAC to request a > confirmation from > the UAS without the UAS requesting a confirmation from the UAC. This > seems pointless. > > |----(1)INVITE------->| > |<---(2)183-----------| > |----(3)PRACK-------->| > |<---(4)200-----------| > |<---(5)COMET---------| > |----(6)200---------->| > |<---(7)180-----------| > > If message (1)INVITE includes a request for a confirmation, > i.e. (5)COMET, > but message (2)183 does not also request a confirmation, then there is > nothing the UAC can do upon receipt of the (5)COMET. The UAS > is already > doing the alerting and the (7)180 is probably already on its > way. The fact > that (7)180 is sent indicates the resource preconditions were > met by UAS, > because otherwise it would have responded with a > 580-precondition-failure > response. So why even bother with (5)COMET? > > My original intention in writing the procedures for the two-way COMET > exchange was that it be triggered by the UAC requesting a > confirmation. > The UAS, on receipt of a SDP containing a precondition line with a > confirmation request, MUST include a precondition line in its SDP with > a confirmation request. This text doesn't appear, and would solve > the problem presented by third party call control. > > Did anyone see a case where the one-way confirmation shown in the > diagram above was actually useful and should be allowed? Otherwise, > I think we should add the requirement on UAS behavior. > > If the response to the INVITE(with confirmation requested) is > a 180, or > a 183 without a precondition line, it indicates the UAS > doesn't support > the resource extension. A 183 response with a precondition line that > doesn't include a confirmation would also, in this case, indicate lack > support of the UAS (or lack of sanity). > > > Bill Marshall > wtm@research.att.com > > > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > Sent: Thursday, October 12, 2000 1:38 AM > To: Jonathan Rosenberg > Cc: 'sip' > Subject: Re: [SIP] Feedback on manyfolks > > > Hi, > > I agree. This is getting pretty complex. > > Anyway, for this specific matter we have three choices: > > 1) COMET is always mandatory in both directions. It does not matter if > the preconditions are mandatory or optional. > > 2) COMET is mandatory just when the preconditions are mandatory. > > 3) COMET is just sent when requested by any of the parties. This would > be the mechanism used so far (with the extension defined in > draft-camarillo-manyfolks-confirm-00.txt) > > > Approach number 1 is the simplest. After doing whatever in order to > fulfil the preconditions a COMET is sent. > > Number 2 is also pretty simple. If the preconditions were > mandatory, the > session is stopped until the COMET is sent. If the preconditions were > optional the session establishment goes on, so no COMET is sent. > > The gain of approach number 3 is that it saves some messages. However, > as you pointed out, they are not a lot. In the most common > situation it > would save 2 messages (1 RTT). This is when A calls B in a two-party > session where there is just one COMET from A towards B. The > COMET from B > to A is not normally needed since B just begins alerting the user once > the preconditions are met. > > So, we have a little more complexity for a little gain. > > My only concern is the amonut of signalling messages that we already > have for establishing a session using preconditions (PRACKs, > COMETs). A > RTT for a workstation in an ethernet is not a big deal, but for a > terminal using a cellular access begins to be more important. > > Anyway, I do not have a religious position here, so any of the 3 > solutions is alright for me. Let's pick one and go on resolving > different issues. > > Opinions? > > Regards, > > Gonzalo > > > > > Jonathan Rosenberg wrote: > > > > Its just thats its more options, more complexities ontop of > a thing which > is > > growing more and more complex. We need to remove options, > not add them. I > > don't see what they need is for the negotiation. We need to > justify the > > existence of it, not the elimination of it. > > > > -Jonathan R. > > > > --- > > Jonathan D. Rosenberg 72 Eagle Rock Ave. > > Chief Scientist First Floor > > dynamicsoft East Hanover, NJ 07936 > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > > http://www.dynamicsoft.com > > > > > -----Original Message----- > > > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > > Sent: Tuesday, October 10, 2000 10:46 AM > > > To: Jonathan Rosenberg > > > Cc: 'sip' > > > Subject: Re: [SIP] Feedback on manyfolks > > > > > > > > > Hi, > > > > > > Certainly we are not talking about tons of messages. > However, in this > > > case I would rather let the confim be negotiated. The > negotiation is > > > rather simple. > > > > > > The UAC can request: > > > 1) No COMET > > > 2) one COMET UAC->UAS > > > 3) one COMET UAC- > > 4) two COMETs > > > > > > The UAS should accept what the UAC requests, and possibly > request more > > > (e.g. two COMETs when the UAC just requested one). > > > > > > I believe this is not a complicated mechanism. It is just a > > > deterministic two-way handshake. > > > > > > Best regards, > > > > > > Gonzalo > > > > > > > > > > > > Jonathan Rosenberg wrote: > > > > > > > > This seems reasonable to me, and needed, as Gonzalo points out. > > > > > > > > My only issue is whether all this stuff should be optional > > > at all. Wouldn't > > > > it be easier if both sides always sent COMET, period? All > > > this negotiation > > > > stuff is a pain. We're not talking tons of messages here. > > > Can't we keep it > > > > simple? > > > > > > > > -Jonathan R. > > > > > > > > --- > > > > Jonathan D. Rosenberg 72 Eagle Rock Ave. > > > > Chief Scientist First Floor > > > > dynamicsoft East > Hanover, NJ 07936 > > > > jdrosen@dynamicsoft.com FAX: > (973) 952-5050 > > > > http://www.cs.columbia.edu/~jdrosen PHONE: > (973) 952-5000 > > > > http://www.dynamicsoft.com > > > > > > > > > -----Original Message----- > > > > > From: Gonzalo Camarillo > [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > > > > Sent: Monday, October 09, 2000 2:33 AM > > > > > To: sip > > > > > Subject: [SIP] Feedback on manyfolks > > > > > > > > > > > > > > > Hi, > > > > > > > > > > Here you have a new I-D that contains feedback on the > > > manyfolks draft. > > > > > > > > > > http://search.ietf.org/internet-drafts/draft-camarillo-manyfol > > > > > ks-confirm-00.txt > > > > > > > > > > " > > > > > Abstract > > > > > > > > > > This document describes certain functionality that is > > > > > missing in the > > > > > current "Integration of Resource Management and SIP" > > > [1] (a.k.a. > > > > > manyfolks draft). An extension to add this functionality is > > > > > outlined. > > > > > > > > > > This functionality is needed in general to provide richer > > > > > signalling > > > > > capabilities and can be employed in several scenarios. > > > This draft > > > > > describes its use in third party call control applications. > > > > > > > > > > If this extension is accepted it is foreseen that this > > > draft would > > > > > be merged with [1]. > > > > > " > > > > > > > > > > Best regards, > > > > > > > > > > Gonzalo > > > > > -- > > > > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > > > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > > > > Telecom R&D Fax : +358 9 299 30 52 > > > > > FIN-02420 Jorvas Email : > Gonzalo.Camarillo@ericsson.com > > > > > Finland http://www.hut.fi/~gonzalo > > > > > > > > > > _______________________________________________ > > > > > SIP mailing list > > > > > SIP@lists.bell-labs.com > > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > > > > -- > > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > > Telecom R&D Fax : +358 9 299 30 52 > > > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > > > Finland http://www.hut.fi/~gonzalo > > > > > > _______________________________________________ > > > SIP mailing list > > > SIP@lists.bell-labs.com > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > -- > Gonzalo Camarillo Phone : +358 9 299 33 71 > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > Telecom R&D Fax : +358 9 299 30 52 > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > Finland http://www.hut.fi/~gonzalo > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > ------_=_NextPart_001_01C03DA7.AEE6ADC0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: [SIP] Feedback on manyfolks

Good point.

What is the point of the UAS to UAC COMET at all ? If = you need two-way confirmation of resource reservation, won't the 180 = provide the backwards confirmation in all cases ?

The point about resource reservation is that the = progress of the session - which has a definate direction UAC -> UAS = - needs to be delayed pending completion of the reservation.

Once it has received the INVITE, it is the UAS which = is in control of the session progress. The UAS knows for itself when it = has completed its local preconditions, so surely the only = precondition-met signalling which is needed it forwards, from UAC to = UAS ?

Regards,

Mark Watson
Nortel Networks

> -----Original Message-----
> From: William Marshall [mailto:wtm@research.att.com]
> Sent: 23 October 2000 22:47
> To: gonzalo.camarillo@lmf.ericsson.se; = jdrosen@dynamicsoft.com
> Cc: sip@lists.bell-labs.com
> Subject: FW: [SIP] Feedback on manyfolks
>
>
> This discussion took me a little while to = figure out, because there
> was clearly something missing in the manyfolks = draft that I wasn't
> seeing.
>
> The current manyfolks draft shows two examples, = one where a
> confirmation
> is requested by the UAS from the UAC, and one = where two confirmations
> are requested, first by the UAC from the UAS, = then by the UAS
> from the UAC.
>
> However, (and the part I missed several times =
> re-re-re-reading the draft),
> the wording of the spec also allows the UAC to = request a
> confirmation from
> the UAS without the UAS requesting a = confirmation from the UAC.  This
> seems pointless.
>
>   |----(1)INVITE------->|
>   |<---(2)183-----------|
>   |----(3)PRACK-------->|
>   |<---(4)200-----------|
>   |<---(5)COMET---------|
>   |----(6)200---------->|
>   |<---(7)180-----------|
>
> If message (1)INVITE includes a request for a = confirmation,
> i.e. (5)COMET,
> but message (2)183 does not also request a = confirmation, then there is
> nothing the UAC can do upon receipt of the = (5)COMET.  The UAS
> is already
> doing the alerting and the (7)180 is probably = already on its
> way.  The fact
> that (7)180 is sent indicates the resource = preconditions were
> met by UAS,
> because otherwise it would have responded with = a
> 580-precondition-failure
> response.  So why even bother with = (5)COMET?
>
> My original intention in writing the procedures = for the two-way COMET
> exchange was that it be triggered by the UAC = requesting a
> confirmation.
> The UAS, on receipt of a SDP containing a = precondition line with a
> confirmation request, MUST include a = precondition line in its SDP with
> a confirmation request.  This text doesn't = appear, and would solve
> the problem presented by third party call = control.
>
> Did anyone see a case where the one-way = confirmation shown in the
> diagram above was actually useful and should be = allowed?  Otherwise,
> I think we should add the requirement on UAS = behavior.
>
> If the response to the INVITE(with confirmation = requested) is
> a 180, or
> a 183 without a precondition line, it indicates = the UAS
> doesn't support
> the resource extension.  A 183 response = with a precondition line that
> doesn't include a confirmation would also, in = this case, indicate lack
> support of the UAS (or lack of sanity).
>
>
> Bill Marshall
> wtm@research.att.com
>
>
> -----Original Message-----
> From: Gonzalo Camarillo [mailto:Gonzalo.Camaril= lo@lmf.ericsson.se]
> Sent: Thursday, October 12, 2000 1:38 AM
> To: Jonathan Rosenberg
> Cc: 'sip'
> Subject: Re: [SIP] Feedback on manyfolks
>
>
> Hi,
>
> I agree. This is getting pretty complex.
>
> Anyway, for this specific matter we have three = choices:
>
> 1) COMET is always mandatory in both = directions. It does not matter if
> the preconditions are mandatory or = optional.
>
> 2) COMET is mandatory just when the = preconditions are mandatory.
>
> 3) COMET is just sent when requested by any of = the parties. This would
> be the mechanism used so far (with the = extension defined in
> = draft-camarillo-manyfolks-confirm-00.txt)
>
>
> Approach number 1 is the simplest. After doing = whatever in order to
> fulfil the preconditions a COMET is = sent.
>
> Number 2 is also pretty simple. If the = preconditions were
> mandatory, the
> session is stopped until the COMET is sent. If = the preconditions were
> optional the session establishment goes on, so = no COMET is sent.
>
> The gain of approach number 3 is that it saves = some messages. However,
> as you pointed out, they are not a lot. In the = most common
> situation it
> would save 2 messages (1 RTT). This is when A = calls B in a two-party
> session where there is just one COMET from A = towards B. The
> COMET from B
> to A is not normally needed since B just begins = alerting the user once
> the preconditions are met.
>
> So, we have a little more complexity for a = little gain.
>
> My only concern is the amonut of signalling = messages that we already
> have for establishing a session using = preconditions (PRACKs,
> COMETs). A
> RTT for a workstation in an ethernet is not a = big deal, but for a
> terminal using a cellular access begins to be = more important.
>
> Anyway, I do not have a religious position = here, so any of the 3
> solutions is alright for me. Let's pick one and = go on resolving
> different issues.
>
> Opinions?
>
> Regards,
>
> Gonzalo
>
>
>
>
> Jonathan Rosenberg wrote:
> >
> > Its just thats its more options, more = complexities ontop of
> a thing which
> is
> > growing more and more complex. We need to = remove options,
> not add them. I
> > don't see what they need is for the = negotiation. We need to
> justify the
> > existence of it, not the elimination of = it.
> >
> > -Jonathan R.
> >
> > ---
> > Jonathan D. = Rosenberg          &nb= sp;            = 72 Eagle Rock Ave.
> > Chief = Scientist          &nb= sp;           &nb= sp;      First Floor
> > = dynamicsoft          &= nbsp;           &= nbsp;          East = Hanover, NJ 07936
> > = jdrosen@dynamicsoft.com        &= nbsp;            = FAX:   (973) 952-5050
> > http://www.cs.columbia.edu/~jdrosen  &nb= sp;      PHONE: (973) 952-5000
> > http://www.dynamicsoft.com
> >
> > > -----Original Message-----
> > > From: Gonzalo Camarillo [mailto:Gonzalo.Camaril= lo@lmf.ericsson.se]
> > > Sent: Tuesday, October 10, 2000 10:46 = AM
> > > To: Jonathan Rosenberg
> > > Cc: 'sip'
> > > Subject: Re: [SIP] Feedback on = manyfolks
> > >
> > >
> > > Hi,
> > >
> > > Certainly we are not talking about = tons of messages.
> However, in this
> > > case I would rather let the confim be = negotiated. The
> negotiation is
> > > rather simple.
> > >
> > > The UAC can request:
> > > 1) No COMET
> > > 2) one COMET UAC->UAS
> > > 3) one COMET UAC-<UAS
> > > 4) two COMETs
> > >
> > > The UAS should accept what the UAC = requests, and possibly
> request more
> > > (e.g. two COMETs when the UAC just = requested one).
> > >
> > > I believe this is not a complicated = mechanism. It is just a
> > > deterministic two-way = handshake.
> > >
> > > Best regards,
> > >
> > > Gonzalo
> > >
> > >
> > >
> > > Jonathan Rosenberg wrote:
> > > >
> > > > This seems reasonable to me, and = needed, as Gonzalo points out.
> > > >
> > > > My only issue is whether all = this stuff should be optional
> > > at all. Wouldn't
> > > > it be easier if both sides = always sent COMET, period? All
> > > this negotiation
> > > > stuff is a pain. We're not = talking tons of messages here.
> > > Can't we keep it
> > > > simple?
> > > >
> > > > -Jonathan R.
> > > >
> > > > ---
> > > > Jonathan D. = Rosenberg          &nb= sp;            = 72 Eagle Rock Ave.
> > > > Chief = Scientist          &nb= sp;           &nb= sp;      First Floor
> > > > = dynamicsoft          &= nbsp;           &= nbsp;          East =
> Hanover, NJ 07936
> > > > = jdrosen@dynamicsoft.com        &= nbsp;            = FAX:  
> (973) 952-5050
> > > > http://www.cs.columbia.edu/~jdrosen  &nb= sp;      PHONE:
> (973) 952-5000
> > > > http://www.dynamicsoft.com
> > > >
> > > > > -----Original = Message-----
> > > > > From: Gonzalo Camarillo =
> [mailto:Gonzalo.Camaril= lo@lmf.ericsson.se]
> > > > > Sent: Monday, October 09, = 2000 2:33 AM
> > > > > To: sip
> > > > > Subject: [SIP] Feedback on = manyfolks
> > > > >
> > > > >
> > > > > Hi,
> > > > >
> > > > > Here you have a new I-D = that contains feedback on the
> > > manyfolks draft.
> > > > >
> > > > > http://search.ietf.org/internet-drafts/draft-camarillo= -manyfol
> > > > > ks-confirm-00.txt
> > > > >
> > > > > "
> > > > > Abstract
> > > > >
> > > > >    This = document describes certain functionality that is
> > > > > missing in the
> > > > >    current = "Integration of Resource Management and SIP"
> > > [1] (a.k.a.
> > > > >    manyfolks = draft). An extension to add this functionality is
> > > > >    = outlined.
> > > > >
> > > > >    This = functionality is needed in general to provide richer
> > > > > signalling
> > > > >    = capabilities and can be employed in several scenarios.
> > > This draft
> > > > >    describes = its use in third party call control applications.
> > > > >
> > > > >    If this = extension is accepted it is foreseen that this
> > > draft would
> > > > >    be merged = with [1].
> > > > > "
> > > > >
> > > > > Best regards,
> > > > >
> > > > > Gonzalo
> > > > > --
> > > > > Gonzalo = Camarillo         Phone :  = +358  9 299 33 71
> > > > > Oy L M Ericsson = Ab        Mobile:  +358 40 702 = 35 35
> > > > > Telecom = R&D           = ;    Fax   :  +358  9 299 30 = 52
> > > > > FIN-02420 = Jorvas          Email = : 
> Gonzalo.Camarillo@ericsson.com
> > > > > = Finland           = ;        http://www.hut.fi/~gonzalo
> > > > >
> > > > > = _______________________________________________
> > > > > SIP mailing list
> > > > > = SIP@lists.bell-labs.com
> > > > > http://lists.bell-labs.com/mailman/listinfo/sip
> > > > >
> > >
> > > --
> > > Gonzalo = Camarillo         Phone :  = +358  9 299 33 71
> > > Oy L M Ericsson = Ab        Mobile:  +358 40 702 = 35 35
> > > Telecom = R&D           = ;    Fax   :  +358  9 299 30 = 52
> > > FIN-02420 = Jorvas          Email = :  Gonzalo.Camarillo@ericsson.com
> > > = Finland           = ;        http://www.hut.fi/~gonzalo
> > >
> > > = _______________________________________________
> > > SIP mailing list
> > > SIP@lists.bell-labs.com
> > > http://lists.bell-labs.com/mailman/listinfo/sip
> > >
>
> --
> Gonzalo = Camarillo         Phone :  = +358  9 299 33 71
> Oy L M Ericsson = Ab        Mobile:  +358 40 702 = 35 35
> Telecom = R&D           = ;    Fax   :  +358  9 299 30 = 52
> FIN-02420 = Jorvas          Email = :  Gonzalo.Camarillo@ericsson.com
> = Finland           = ;        http://www.hut.fi/~gonzalo
>
>
> = _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip
>

------_=_NextPart_001_01C03DA7.AEE6ADC0-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 24 07:03:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA15068 for ; Tue, 24 Oct 2000 07:03:03 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C9CDA4435E; Tue, 24 Oct 2000 06:03:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lists.bell-labs.com (Postfix) with ESMTP id CAF6A4433A for ; Tue, 24 Oct 2000 06:02:03 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id e9OB1vZ05897; Tue, 24 Oct 2000 13:01:58 +0200 (MEST) 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 OAA27675; Tue, 24 Oct 2000 14:01:56 +0300 (EET DST) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.73]) by greymse1.lmf.ericsson.se (8.9.3 (PHNE_18979)/8.8.6) with ESMTP id OAA14865; Tue, 24 Oct 2000 14:01:55 +0300 (EETDST) Message-ID: <39F56C1F.A552E95B@lmf.ericsson.se> From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Cc: Anders Kristensen Subject: Re: [SIP] Redirect server returning new From header References: <39F542D0.714157FC@lmf.ericsson.se> <39F552ED.F598C9DF@dynamicsoft.com> Content-Type: multipart/mixed; boundary="------------6248E1E6D565D71FF9E8A623" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 24 Oct 2000 14:01:51 +0300 This is a multi-part message in MIME format. --------------6248E1E6D565D71FF9E8A623 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, >>Another proposal on the issue, with another use of the "Also-From" >>header. >> >>Currently, a redirect server add a new Request-URI (in the 3xx response >>Contact header) to the UAC. An idea would be that it could also return a >>new From header, for example with a telephone number. In this case, the >>UAC, and intermediate proxies, would not need to insert any extra >>headers or URI parameters in the request. This would be a new, optional, >>feature in a redirect server. > >A registrar is free to return SIP, tel:, mailto:, http: and any other >kind of URLs in Contacts. Whatever it is you think you need the extra >From for I think you'll find you can use Contact for. I know, but the idea was to give the possibility not only to return a new RequestURI - whatever format - in the Conact header, but also to give a new From header, if for example the Redirect server knows that the request will reach a PSTN/IP GW, and the current From header can for example not be used for A number analysis. I want to point out that this case is not about solving a bug in the protocol itself, it has to do only with the interworking architecture with PSTN. Regards, Christer Holmberg Ericsson Finland --------------6248E1E6D565D71FF9E8A623 Content-Type: text/x-vcard; charset=us-ascii; name="christer.holmberg.vcf" Content-Description: Card for Christer Holmberg Content-Disposition: attachment; filename="christer.holmberg.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Holmberg;Christer tel;cell:+358-40-5604412 tel;work:+358-9-2992943 x-mozilla-html:FALSE org:Ericsson;Advanced Signalling Research Laboratory adr:;;;;;; version:2.1 email;internet:christer.holmberg@lmf.ericsson.se title:System Designer fn:Christer Holmberg end:vcard --------------6248E1E6D565D71FF9E8A623-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 24 07:30:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA22507 for ; Tue, 24 Oct 2000 07:30:02 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 952BA4435C; Tue, 24 Oct 2000 06:30:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mail.speedventures.com (unknown [212.75.74.99]) by lists.bell-labs.com (Postfix) with ESMTP id C85A54433D for ; Tue, 24 Oct 2000 06:29:42 -0400 (EDT) Received: from HASH ([192.168.27.104]) by mail.speedventures.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id V22M5TR4; Tue, 24 Oct 2000 13:25:48 +0200 From: "Hisham Khartabil" To: "Christer Holmberg" , Subject: RE: [SIP] Redirect server returning new From header Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: <39F56C1F.A552E95B@lmf.ericsson.se> Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 24 Oct 2000 14:29:06 +0300 Content-Transfer-Encoding: 7bit Hi, I see what you are trying to achieve here, but my concern is with the redirection rules. When a UA gets a 3xx response, it issues a new request. MUST that new request belong to the same call leg as the original request? ie: same To: From: Call-id, but higher Cseq. If so, your proposal breaks that rule. Regards, Hisham -----Original Message----- From: sip-admin@lists.bell-labs.com [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Christer Holmberg Sent: 24. lokakuuta 2000 14:02 To: sip@lists.bell-labs.com Cc: Anders Kristensen Subject: Re: [SIP] Redirect server returning new From header Hi, >>Another proposal on the issue, with another use of the "Also-From" >>header. >> >>Currently, a redirect server add a new Request-URI (in the 3xx response >>Contact header) to the UAC. An idea would be that it could also return a >>new From header, for example with a telephone number. In this case, the >>UAC, and intermediate proxies, would not need to insert any extra >>headers or URI parameters in the request. This would be a new, optional, >>feature in a redirect server. > >A registrar is free to return SIP, tel:, mailto:, http: and any other >kind of URLs in Contacts. Whatever it is you think you need the extra >From for I think you'll find you can use Contact for. I know, but the idea was to give the possibility not only to return a new RequestURI - whatever format - in the Conact header, but also to give a new From header, if for example the Redirect server knows that the request will reach a PSTN/IP GW, and the current From header can for example not be used for A number analysis. I want to point out that this case is not about solving a bug in the protocol itself, it has to do only with the interworking architecture with PSTN. Regards, Christer Holmberg Ericsson Finland _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 24 07:47:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA26625 for ; Tue, 24 Oct 2000 07:47:02 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A8A944433A; Tue, 24 Oct 2000 06:47:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lists.bell-labs.com (Postfix) with ESMTP id 2EB4F44336 for ; Tue, 24 Oct 2000 06:46:58 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id e9OBkqt03768; Tue, 24 Oct 2000 13:46:52 +0200 (MEST) 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 OAA01468; Tue, 24 Oct 2000 14:46:51 +0300 (EET DST) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.73]) by greymse1.lmf.ericsson.se (8.9.3 (PHNE_18979)/8.8.6) with ESMTP id OAA26726; Tue, 24 Oct 2000 14:46:48 +0300 (EETDST) Message-ID: <39F576A6.340A79FD@lmf.ericsson.se> From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Cc: Hisham Khartabil Subject: Re: [SIP] Redirect server returning new From header References: Content-Type: multipart/mixed; boundary="------------A50B0456A8FB9A39D096037E" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 24 Oct 2000 14:46:46 +0300 This is a multi-part message in MIME format. --------------A50B0456A8FB9A39D096037E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, >I see what you are trying to achieve here, but my concern is with the >redirection rules. When a UA gets a 3xx response, it issues a new >request. MUST that new request belong to the same call leg as the >original request? >ie: same To: From: Call-id, but higher Cseq. If so, your proposal breaks >that rule. It doesn't have to belong to the same call leg. It MAY do so, but you MAY also change the To header (with the new value in the 3xx response Contact header), and you MAY also change the Call-id value. And, in any case, it doesn't affect anything else than my own implementation, even if I use the same Call-id (which one would probably do). I mean - I don't even have to issue a new INVITE when I receive a 3xx, so any possible intermediate SIP proxy etc. should not be affected. Regards, Christer Holmberg Ericsson Finland > -----Original Message----- > From: sip-admin@lists.bell-labs.com [mailto:sip-admin@lists.bell-labs.com]On > Behalf Of Christer Holmberg > Sent: 24. lokakuuta 2000 14:02 > To: sip@lists.bell-labs.com > Cc: Anders Kristensen > Subject: Re: [SIP] Redirect server returning new From header > > Hi, > > >>Another proposal on the issue, with another use of the "Also-From" > >>header. > >> > >>Currently, a redirect server add a new Request-URI (in the 3xx response > >>Contact header) to the UAC. An idea would be that it could also return a > >>new From header, for example with a telephone number. In this case, the > >>UAC, and intermediate proxies, would not need to insert any extra > >>headers or URI parameters in the request. This would be a new, optional, > >>feature in a redirect server. > > > >A registrar is free to return SIP, tel:, mailto:, http: and any other > >kind of URLs in Contacts. Whatever it is you think you need the extra > >From for I think you'll find you can use Contact for. > > I know, but the idea was to give the possibility not only to return a > new RequestURI - whatever format - in the Conact header, but also to > give a new From header, if for example the Redirect server knows that > the request will reach a PSTN/IP GW, and the current From header can for > example not be used for A number analysis. > > I want to point out that this case is not about solving a bug in the > protocol itself, it has to do only with the interworking architecture > with PSTN. > > Regards, > > Christer Holmberg > Ericsson Finland --------------A50B0456A8FB9A39D096037E Content-Type: text/x-vcard; charset=us-ascii; name="christer.holmberg.vcf" Content-Description: Card for Christer Holmberg Content-Disposition: attachment; filename="christer.holmberg.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Holmberg;Christer tel;cell:+358-40-5604412 tel;work:+358-9-2992943 x-mozilla-html:FALSE org:Ericsson;Advanced Signalling Research Laboratory adr:;;;;;; version:2.1 email;internet:christer.holmberg@lmf.ericsson.se title:System Designer fn:Christer Holmberg end:vcard --------------A50B0456A8FB9A39D096037E-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 24 07:55:16 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA28579 for ; Tue, 24 Oct 2000 07:55:16 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E34C044348; Tue, 24 Oct 2000 06:55:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mail.speedventures.com (unknown [212.75.74.99]) by lists.bell-labs.com (Postfix) with ESMTP id E77B34433A for ; Tue, 24 Oct 2000 06:54:26 -0400 (EDT) Received: from HASH ([192.168.27.104]) by mail.speedventures.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id V22M5TWB; Tue, 24 Oct 2000 13:50:22 +0200 From: "Hisham Khartabil" To: "Christer Holmberg" , Subject: RE: [SIP] Redirect server returning new From header Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: <39F576A6.340A79FD@lmf.ericsson.se> Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 24 Oct 2000 14:53:40 +0300 Content-Transfer-Encoding: 7bit I can't find in the bis where it says that they belong to the same call leg, but in section 1.4.4 the last paragraph, it does say "The caller issues a new request, with the same call-ID but a higher CSeq, to the address returned by the first server" Hisham -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] Sent: 24. lokakuuta 2000 14:47 To: sip@lists.bell-labs.com Cc: Hisham Khartabil Subject: Re: [SIP] Redirect server returning new From header Hi, >I see what you are trying to achieve here, but my concern is with the >redirection rules. When a UA gets a 3xx response, it issues a new >request. MUST that new request belong to the same call leg as the >original request? >ie: same To: From: Call-id, but higher Cseq. If so, your proposal breaks >that rule. It doesn't have to belong to the same call leg. It MAY do so, but you MAY also change the To header (with the new value in the 3xx response Contact header), and you MAY also change the Call-id value. And, in any case, it doesn't affect anything else than my own implementation, even if I use the same Call-id (which one would probably do). I mean - I don't even have to issue a new INVITE when I receive a 3xx, so any possible intermediate SIP proxy etc. should not be affected. Regards, Christer Holmberg Ericsson Finland > -----Original Message----- > From: sip-admin@lists.bell-labs.com [mailto:sip-admin@lists.bell-labs.com]On > Behalf Of Christer Holmberg > Sent: 24. lokakuuta 2000 14:02 > To: sip@lists.bell-labs.com > Cc: Anders Kristensen > Subject: Re: [SIP] Redirect server returning new From header > > Hi, > > >>Another proposal on the issue, with another use of the "Also-From" > >>header. > >> > >>Currently, a redirect server add a new Request-URI (in the 3xx response > >>Contact header) to the UAC. An idea would be that it could also return a > >>new From header, for example with a telephone number. In this case, the > >>UAC, and intermediate proxies, would not need to insert any extra > >>headers or URI parameters in the request. This would be a new, optional, > >>feature in a redirect server. > > > >A registrar is free to return SIP, tel:, mailto:, http: and any other > >kind of URLs in Contacts. Whatever it is you think you need the extra > >From for I think you'll find you can use Contact for. > > I know, but the idea was to give the possibility not only to return a > new RequestURI - whatever format - in the Conact header, but also to > give a new From header, if for example the Redirect server knows that > the request will reach a PSTN/IP GW, and the current From header can for > example not be used for A number analysis. > > I want to point out that this case is not about solving a bug in the > protocol itself, it has to do only with the interworking architecture > with PSTN. > > Regards, > > Christer Holmberg > Ericsson Finland _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 24 08:03:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA00448 for ; Tue, 24 Oct 2000 08:03:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4C74C4433A; Tue, 24 Oct 2000 07:03:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lists.bell-labs.com (Postfix) with ESMTP id 25B1C44336 for ; Tue, 24 Oct 2000 07:02:23 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id e9OC2Ht13531; Tue, 24 Oct 2000 14:02:17 +0200 (MEST) 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 PAA02818; Tue, 24 Oct 2000 15:02:16 +0300 (EET DST) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.73]) by greymse1.lmf.ericsson.se (8.9.3 (PHNE_18979)/8.8.6) with ESMTP id PAA00943; Tue, 24 Oct 2000 15:02:14 +0300 (EETDST) Message-ID: <39F57A43.EF470512@lmf.ericsson.se> From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Cc: Hisham Khartabil Subject: Re: [SIP] Redirect server returning new From header References: Content-Type: multipart/mixed; boundary="------------A8FC0EEE1DEDACB3102E11E6" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 24 Oct 2000 15:02:11 +0300 This is a multi-part message in MIME format. --------------A8FC0EEE1DEDACB3102E11E6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, Well, you may use the same call-ID value (the value should be unique for the call, not for a single call leg), but you are still allowed to change the To- and From headers. And, chapter 7.3.3. says that the call-ID value can also be changed. Regards, Christer Holmberg Ericsson Finland Hisham Khartabil wrote: > > I can't find in the bis where it says that they belong to the same call leg, > but in section 1.4.4 the last paragraph, it does say "The caller issues a > new request, > with the same call-ID but a higher CSeq, to the address returned by the > first server" > > Hisham > > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > Sent: 24. lokakuuta 2000 14:47 > To: sip@lists.bell-labs.com > Cc: Hisham Khartabil > Subject: Re: [SIP] Redirect server returning new From header > > Hi, > > >I see what you are trying to achieve here, but my concern is with the > >redirection rules. When a UA gets a 3xx response, it issues a new > >request. MUST that new request belong to the same call leg as the >original > request? > >ie: same To: From: Call-id, but higher Cseq. If so, your proposal breaks > >that rule. > > It doesn't have to belong to the same call leg. It MAY do so, but you > MAY also change the To header (with the new value in the 3xx response > Contact header), and you MAY also change the Call-id value. > > And, in any case, it doesn't affect anything else than my own > implementation, even if I use the same Call-id (which one would probably > do). > I mean - I don't even have to issue a new INVITE when I receive a 3xx, > so any possible intermediate SIP proxy etc. should not be affected. > > Regards, > > Christer Holmberg > Ericsson Finland > > > -----Original Message----- > > From: sip-admin@lists.bell-labs.com > [mailto:sip-admin@lists.bell-labs.com]On > > Behalf Of Christer Holmberg > > Sent: 24. lokakuuta 2000 14:02 > > To: sip@lists.bell-labs.com > > Cc: Anders Kristensen > > Subject: Re: [SIP] Redirect server returning new From header > > > > Hi, > > > > >>Another proposal on the issue, with another use of the "Also-From" > > >>header. > > >> > > >>Currently, a redirect server add a new Request-URI (in the 3xx response > > >>Contact header) to the UAC. An idea would be that it could also return a > > >>new From header, for example with a telephone number. In this case, the > > >>UAC, and intermediate proxies, would not need to insert any extra > > >>headers or URI parameters in the request. This would be a new, optional, > > >>feature in a redirect server. > > > > > >A registrar is free to return SIP, tel:, mailto:, http: and any other > > >kind of URLs in Contacts. Whatever it is you think you need the extra > > >From for I think you'll find you can use Contact for. > > > > I know, but the idea was to give the possibility not only to return a > > new RequestURI - whatever format - in the Conact header, but also to > > give a new From header, if for example the Redirect server knows that > > the request will reach a PSTN/IP GW, and the current From header can for > > example not be used for A number analysis. > > > > I want to point out that this case is not about solving a bug in the > > protocol itself, it has to do only with the interworking architecture > > with PSTN. > > > > Regards, > > > > Christer Holmberg > > Ericsson Finland --------------A8FC0EEE1DEDACB3102E11E6 Content-Type: text/x-vcard; charset=us-ascii; name="christer.holmberg.vcf" Content-Description: Card for Christer Holmberg Content-Disposition: attachment; filename="christer.holmberg.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Holmberg;Christer tel;cell:+358-40-5604412 tel;work:+358-9-2992943 x-mozilla-html:FALSE org:Ericsson;Advanced Signalling Research Laboratory adr:;;;;;; version:2.1 email;internet:christer.holmberg@lmf.ericsson.se title:System Designer fn:Christer Holmberg end:vcard --------------A8FC0EEE1DEDACB3102E11E6-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 24 10:07:12 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA29744 for ; Tue, 24 Oct 2000 10:07:10 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D676A44349; Tue, 24 Oct 2000 09:07:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id D006C44339 for ; Mon, 23 Oct 2000 16:23:08 -0400 (EDT) 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 RAA22363; Mon, 23 Oct 2000 17:22:57 -0400 (EDT) Message-ID: <39F4AC32.66940D5D@cs.columbia.edu> From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "Agarwal, Aseem" Cc: "'Jonathan Rosenberg'" , "'Piotr S. Kossowski'" , sip@lists.bell-labs.com Subject: Re: [SIP] Multi-message UDP datagrams (probably not specified behaviour) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 23 Oct 2000 17:22:58 -0400 Content-Transfer-Encoding: 7bit "Agarwal, Aseem" wrote: > > Hi all, > Is there a realistic situation where some implementation will > send multiple messages in a single datagram ? If NOT, then is it > not better to remove this source of confusion from the new version > of the draft. > > Another related point is about transport of SIP messages using > TCP. Since it is possible to receive partial or more than one SIP message > in one TCP-recv() call, an implementation has to put in extra logic to > determine the end of the message, e.g. find out the CRLF CRLF sequence, > then check for Content-Length header, wait for the remaining bytes and > so on.. > > One option may be to have an application level framing mechanism > (something similar to TPKT -rfc 1006) to simplify things. What is the > general opinion about this issue ? > > -regards, > aseem > > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Monday, October 23, 2000 10:50 AM > To: 'Piotr S. Kossowski'; unlisted-recipients > Cc: sip@lists.bell-labs.com > Subject: RE: [SIP] Multi-message UDP datagrams (probably not specified > beh aviour) > > > > > -----Original Message----- > > From: Piotr S. Kossowski [mailto:P.Kossowski@elka.pw.edu.pl] > > Sent: Monday, October 23, 2000 1:42 PM > > To: unlisted-recipients > > Cc: sip@lists.bell-labs.com > > Subject: [SIP] Multi-message UDP datagrams (probably not specified > > behaviour) > > > > > > > > Hello, > > > > After further studying of Multiple response per UDP datagram issue, > > and Content-Length header, I suppose that inaccuracy may appear. > > > > Scenario: first let's forget about single UAC that sends > > many messages in one datagram. > > Let's assume that in UDP datagram received by UAS there are > > two messages, > > however (perhaps, because of unique implementation of proxy that > > multiplexes messages to one datagram...). These messages may > > be not correlated and both did NOT contatin Content-Length, > > and both have correct syntax (and semantics, as well). > > Their orginators assumed that UAS would distinguish body > > from message according to section 6.18 of the spec: > > > > "(...)If a server receives a UDP request without Content-Length, > > it MUST assume that the request encompasses the remainder of > > the packet." > > > > So UAS starts parsing of message and it assumes that the body > > is to the end of the packet. And this is not true because > > such body will contain body from the first message and all the > > remainder: headers from the second message plus the second > > body etc. > > Well, thats because the implementation that has sent multiple responses has > erred. If it puts multiple responses in a packet it has to use > Content-Length, else what you have > described will happen. > > > I have also another question: > > > > Table 4 from section 6.4 of the spec. assumes for Content-Length > > in Methods to be "m*", what indicates that the header SHOULD be sent, > > but servers need to be prepared to receive requests without > > that header > > field. > > > > Is there any important reason for "m*" instead of "m" for > > this header ? > > Yes. It was not mandatory in rfc2543. So, for backwards compatibility, > you must be prepared to deal with that (of course, an rfc2543 implementation > would still need to put CL in the response if it were sending multiple > messages per datagram). > In my view, bad idea. It diverges from what's being done in HTTP and RTSP, for no gain. Also, as soon as you add RFC 1006, it's no longer a text protocol, so you loose some of the advantages. It also adds yet another error condition, where the Content-Length disagrees with the RFC 1006 length. In practice, as discussed previously, TCP parsing is 50 lines of code: read lines until blank line (using fgets or whatever), then parse header, then read message body, or some variation on this theme. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 24 10:09:36 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA00282 for ; Tue, 24 Oct 2000 10:09:32 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3484A44351; Tue, 24 Oct 2000 09:07:13 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from topaz.3com.com (topaz.3com.com [192.156.136.158]) by lists.bell-labs.com (Postfix) with ESMTP id 107D44433A for ; Mon, 23 Oct 2000 17:04:30 -0400 (EDT) Received: from opal.3com.com (opal.3com.com [139.87.50.117]) by topaz.3com.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id e9NM3qx25541; Mon, 23 Oct 2000 15:03:52 -0700 (PDT) Received: from hqoutbound.ops.3com.com (hqoutbound.OPS.3Com.COM [139.87.48.104]) by opal.3com.com (Switch-2.0.1/Switch-2.0.1) with SMTP id e9NM4O619534; Mon, 23 Oct 2000 15:04:24 -0700 (PDT) Received: by hqoutbound.ops.3com.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 88256981.0079683F ; Mon, 23 Oct 2000 15:06:05 -0700 X-Lotus-FromDomain: 3COM From: Anoop_Tripathi@3com.com To: William Marshall Cc: sip@lists.bell-labs.com Message-ID: <88256981.00795F7D.00@hqoutbound.ops.3com.com> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [SIP] Feedback on manyfolks Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 23 Oct 2000 17:03:47 -0500 How does this document address a case where I have a network with phones that know nothing about the QoS issues and only the intermediate proxies are aware ( or are involved in QoS setup ) of it? Thanks, Anoop _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 24 10:14:46 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA01239 for ; Tue, 24 Oct 2000 10:14:45 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E83DC44357; Tue, 24 Oct 2000 09:07:20 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by lists.bell-labs.com (Postfix) with ESMTP id 789B44433A for ; Tue, 24 Oct 2000 03:41:32 -0400 (EDT) Received: from mr4u3.ericy.com (mr4u3.ericy.com [208.237.135.127]) by imr1.ericy.com (8.9.3/8.9.3) with ESMTP id DAA27449 for ; Tue, 24 Oct 2000 03:41:27 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr4u3.ericy.com (8.9.3/8.9.3) with ESMTP id DAA21279 for ; Tue, 24 Oct 2000 03:41:27 -0500 (CDT) Received: from ericsson.com ([147.214.68.17]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id DAA18596; Tue, 24 Oct 2000 03:41:21 -0500 (CDT) Message-ID: <39F54B2E.F3704BFA@ericsson.com> From: Sean Olson Organization: Ericsson Inc. X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Christer Holmberg Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Redirect server returning new From header References: <39F542D0.714157FC@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 24 Oct 2000 10:41:19 +0200 Content-Transfer-Encoding: 7bit Do you actually mean the From: or do you mean the To:? It seems a bit odd for a redirect server to tell the UAC what From: to use. Perhaps you could give an example of its usage. Regards, Sean -- Sean Olson Christer Holmberg wrote: > Another proposal on the issue, with another use of the "Also-From" > header. > > Currently, a redirect server add a new Request-URI (in the 3xx response > Contact header) to the UAC. An idea would be that it could also return a > new From header, for example with a telephone number. In this case, the > UAC, and intermediate proxies, would not need to insert any extra > headers or URI parameters in the request. This would be a new, optional, > feature in a redirect server. > > Comments? > > Christer Holmberg > Ericsson Finland _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 24 10:23:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA02277 for ; Tue, 24 Oct 2000 10:23:03 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 00CF744360; Tue, 24 Oct 2000 09:07:28 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lists.bell-labs.com (Postfix) with ESMTP id 91A194433B for ; Tue, 24 Oct 2000 05:40:59 -0400 (EDT) Received: from ms.uab.ericsson.se (ms.uab.ericsson.se [134.138.201.16]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id e9OAerZ23901; Tue, 24 Oct 2000 12:40:53 +0200 (MEST) Received: from uabx04c384.uab.ericsson.se.uab.ericsson.se (uabx04c384 [134.138.229.144]) by ms.uab.ericsson.se (8.10.0/8.10.0/uab-2.26) with ESMTP id e9OAern07204; Tue, 24 Oct 2000 12:40:53 +0200 (MET DST) Received: from uab.ericsson.se by uabx04c384.uab.ericsson.se.uab.ericsson.se (8.8.7/client-1.3uab1) id MAA07485; Tue, 24 Oct 2000 12:40:49 +0200 (MET DST) Message-ID: <39F5672C.60A75012@uab.ericsson.se> From: Bertil Engelholm Organization: Ericsson Utvecklings AB X-Mailer: Mozilla 4.74C-CCK-MCD [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: sv,en-US MIME-Version: 1.0 To: SIP@lists.bell-labs.com Cc: Jonathan Rosenberg Subject: Re: [SIP] multiple responses ?? References: <8t296n$43e$1@lux2.datacom-lab.uab.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 24 Oct 2000 12:40:44 +0200 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > > > > -----Original Message----- > > From: Bertil Engelholm [mailto:Bertil.Engelholm@uab.ericsson.se] > > Sent: Monday, October 23, 2000 12:20 PM > > To: sip@lists.bell-labs.com > > Subject: [SIP] multiple responses ?? > > > > > > Hi, > > > > I have some questions regarding the possibility to forward > > best vs. forward all responses. > > Forward all simply does not work. > > A proxy can forward one or more 200 responses (and indeed, really must > forward all of them), since those are ACKed end to end. Non-200s are ACKed > hop by hop. A proxy or client receiving multiple non-200 responses to the > same request will have no way to distinguish them, and the state machines > currently defined would not work. OK, that simplifies things a bit. > > > > > First of all I wonder if this is not a function that should > > be decided by the UA e.g. by setting a special header ? > > Caller preferences addresses some simple cases where a UAC can request > specific service from proxies. But, since forward-all-responses doesn't > work, having a caller prefs value for it doesn't seem that useful. Maybe I used the wrong term here. Forward all seems not allowed as you explained above. But there are still two different behaviours. Either the proxy only forwards the best response or it forwards all 200 responses. The problem I see is that a UA don't know if it's going to receive one or several 200 responses. So it has to be prepared to always receive several 200 responses. If you MUST set a header to get all 200 responses instead of only the best a UA can decide that it will not handle that case (by not setting the header). > > > It's the UA (the User) that knows if he like to get all > > responses and choose himself or let the network choose the > > best response. Why should each server take this decision ? > > We did it this way (forwarding only the best response) so that it would > scale and work in a reasonable fashion. > > > > > Secondly I have a question regarding the proxy behaviour in > > the following case. > > > > ------ ------ > > | |----->| P2 |---->???? > > ------ | | ------ > > | Ca |----->| P1 | > > ------ | | ------ > > | |----->| P3 |---->???? > > ------ ------ > > > > If Ca calls someone at P1 which forks the call to P2 and P3 how > > should P1 behave in the following cases if it has the policy to > > fork the best response. > > > > If P2 (or someone behind P2) have the policy to fork all responses > > it means that P1 can get several final responses. > > Only multiple 200. > > > Which of these > > reponses should be used in the best choice by P1 ? > > Only the first one that happens to arrive ? > > Everyone that arrives before you get a response from P3 ? > > Beyond 200s, picking which is the best of the non-200 responses is defined > by the spec (600, then 300, then 400, then 500 in that order). However, a > proxy could choose an alternate definition of best amongst the non-200 final > responses it gets, since there are no interoperability issues which choosing > an alternate algorithm. > > > > > What should be done with the rest of the responses that might drop > > in after you have sent your best response back ? > > There should only ever be 200s, which are forwarded upstream. Anything else > would be an error. > > > > > You could actually have received an ACK back from Ca when another > > response drops in from P2. What to do in this case ? > > Won't happen under correct operating conditions. I'm not shure I understand why this can't happen. If P2 can send several 200 responses back to P1 I guess they can come at any time (depending on when someone answers at the other end). So lets say that the first 200 that is received from P2 is choosen as the best result and sent back to Ca. Ca now ACK this OK to P1 because Ca don't know it will get more 200 responses later on. P1 sends the ACK to P2. Another UA behind P2 somewhere now answers the same call which leads to a second 200 response from P2 to P1. And this second 200 response will belong to another CALL-LEG since the TO-tag is different. Maybe I have misunderstood something completly but this is how we have read the specification. If this can't happen it would simplify things but I don't understand why it can't happen. > > -Jonathan R. > --- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip -- Bertil Engelholm AXE Research and Development voice : +46 8 727 3499 SIP Security Fax : +46 8 647 8276 S-126 25 Stockholm Sweden E-mail: Bertil.Engelholm@uab.ericsson.se _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 24 10:27:10 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA02760 for ; Tue, 24 Oct 2000 10:27:09 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B15CC44368; Tue, 24 Oct 2000 09:07:36 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from exchange01.iirltd.co.uk (groupwise.iirltd.co.uk [193.133.64.177]) by lists.bell-labs.com (Postfix) with ESMTP id 025824434D for ; Tue, 24 Oct 2000 06:36:24 -0400 (EDT) Received: by exchange01.iirltd.co.uk with Internet Mail Service (5.5.2650.21) id ; Tue, 24 Oct 2000 12:36:31 +0100 Message-ID: From: Claire Tranah To: "'sip@lists.bell-labs.com'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C03DAE.A7825F10" Subject: [SIP] SIP Interoperability Testing Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 24 Oct 2000 12:36:27 +0100 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_01C03DAE.A7825F10 Content-Type: text/plain; charset="iso-8859-1" Should anyone be interested in taking part in a SIP Interoperability Testing Exhibition (no charge) which is running alongside a SIP conference in Lisbon 7th December can you please contact me. A great chance to display your latest advances in SIP technology Thanks Claire Tranah Conference Producer - Telecoms and Technology IIR Ltd tel. +44 (0) 20 7915 5097 email: ctranah@iir-conferences.com ********************************** see my latest conference at www.telecomstransmission.com/ipqos ********************************** ------_=_NextPart_001_01C03DAE.A7825F10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable SIP Interoperability Testing

Should anyone be interested in taking part in a SIP = Interoperability Testing Exhibition (no charge) which is running = alongside a SIP conference in Lisbon 7th December can you please = contact me. A great chance to display your latest advances in SIP = technology

Thanks

Claire Tranah
Conference Producer - Telecoms and Technology
IIR Ltd

tel. +44 (0) 20 7915 5097
email: ctranah@iir-conferences.com

**********************************
see my latest conference at = www.telecomstransmission.com/ipqos
**********************************

------_=_NextPart_001_01C03DAE.A7825F10-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 24 10:47:52 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA05510 for ; Tue, 24 Oct 2000 10:47:49 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C1D7644350; Tue, 24 Oct 2000 09:45:07 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by lists.bell-labs.com (Postfix) with ESMTP id 2C1144436D for ; Tue, 24 Oct 2000 09:44:26 -0400 (EDT) Received: from mr4u3.ericy.com (mr4u3.ericy.com [208.237.135.127]) by imr1.ericy.com (8.9.3/8.9.3) with ESMTP id JAA09446; Tue, 24 Oct 2000 09:44:00 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr4u3.ericy.com (8.9.3/8.9.3) with ESMTP id JAA01482; Tue, 24 Oct 2000 09:43:48 -0500 (CDT) 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 JAA01031; Tue, 24 Oct 2000 09:43:47 -0500 (CDT) Received: (from eusadam@localhost) by b04a24.exu.ericsson.se (8.9.1/8.9.1) id JAA03706; Tue, 24 Oct 2000 09:43:51 -0500 (CDT) Message-Id: <200010241443.JAA03706@b04a24.exu.ericsson.se> To: schulzrinne@cs.columbia.edu (Henning Schulzrinne) Cc: clive.dellard@bt.com, jdrosen@dynamicsoft.com, byerly@cisco.com, stlevy@cisco.com, jryang@cisco.com, christer.holmberg@lmf.ericsson.se, sip@lists.bell-labs.com In-Reply-To: <39EEF1CA.14CD12BB@cs.columbia.edu> from "Henning Schulzrinne" at Oct 19, 2000 09:06:18 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 Subject: [SIP] Assumptions about billing (was From header to ISUP CgPN mapping) Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 24 Oct 2000 09:43:50 -0500 (CDT) Content-Transfer-Encoding: 7bit >Also, if the outbound gateway is my home provider (as is likely, due to >billing relationships), I will have already registered with a local >registrar, including with a tel: URL. I think this is an unnecessarily restrictive assumption, and one that propigates a narrowminded, old-school way of thinking about billing. Consider the relationships between me, AT&T (internet access provider), and the Wall Street Journal online (content provider). There is an excellent parallel between this situation and, for example, SBC ("home provider" i.e. network access provider), and Worldcom (PSTN gateway provider). Currently, when I access WSJ online, they ask me for a password to verify that I am who I claim to be -- then, they provide me the service that I have agreed to be billed for. There is no relationship between WSJ and AT&T. Similarly, this model works flawlessly when applies to my second example, wherein SBC and Worldcom (for the purposes of this transaction) have no billing relationship. When I use Worldcom's PSTN gateway, it requests authentication from me (or, more likely, my terminal device, which should save me the trouble of typing in a password each time) to verify that it can bill me for the services I'm requesting. When trying to solve problems, *please* don't make simplifying assumptions that break this model. -- 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 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 24 10:59:06 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA07487 for ; Tue, 24 Oct 2000 10:59:03 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6A1914436D; Tue, 24 Oct 2000 09:51:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by lists.bell-labs.com (Postfix) with ESMTP id A76C74436D for ; Tue, 24 Oct 2000 09:50:09 -0400 (EDT) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id 9AFC34CE65 for ; Tue, 24 Oct 2000 10:50:01 -0400 (EDT) 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 KAA26741 for ; Tue, 24 Oct 2000 10:50:01 -0400 (EDT) From: William Marshall Received: (from wtm@localhost) by fish-ha.research.att.com (980427.SGI.8.8.8/8.8.5) id KAA24017 for sip@lists.bell-labs.com; Tue, 24 Oct 2000 10:49:27 -0400 (EDT) Message-Id: <200010241449.KAA24017@fish-ha.research.att.com> To: sip@lists.bell-labs.com Subject: Re: [SIP] Feedback on manyfolks Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 24 Oct 2000 10:49:27 -0400 (EDT) > How does this document address a case where I have a network > with phones that know nothing about the QoS issues > and only the intermediate proxies are aware ( or are > involved in QoS setup) of it? If the phone truly knows nothing about QoS, then it responds to the INVITE containing preconditions with the normal 180-Ringing or 200-OK, and the UAC knows that the preconditions didn't happen (spec requires a UAS supporting the extension to respond with a 183 response). It is also possible that the phone knows nothing about QoS, but an intermediate proxy does know how to do the QoS. The proxy can hold the INVITE and send the 183 response, with a Contact header pointing to the proxy. Thus the COMET will go to the proxy, and then the proxy sends the INVITE on to the endpoint. The 200-OK contains a new Contact header with the endpoint address for future signaling. Manyfolks draft deals with the separate Contact header values, and even a separate Record-Route/Route value for the COMET, in the same way that PRACK allows a proxy to request and receive the acknowledgement. Bill Marshall wtm@research.att.com -----original message----- From: Anoop_Tripathi@3com.com To: William Marshall Cc: sip@lists.bell-labs.com Subject: [SIP] Feedback on manyfolks Date: Mon, 23 Oct 2000 17:03:47 -0500 How does this document address a case where I have a network with phones that know nothing about the QoS issues and only the intermediate proxies are aware ( or are involved in QoS setup) of it? Thanks, Anoop _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 24 12:09:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA20573 for ; Tue, 24 Oct 2000 12:09:04 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0D91F44340; Tue, 24 Oct 2000 11:09:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from thalia.fm.intel.com (thalia.fm.intel.com [132.233.247.11]) by lists.bell-labs.com (Postfix) with ESMTP id CA7E64433D for ; Tue, 24 Oct 2000 11:08:40 -0400 (EDT) Received: from SMTP (fmsmsxvs02-1.fm.intel.com [132.233.42.202]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.32 2000/10/12 22:57:04 dmccart Exp $) with SMTP id QAA17217; Tue, 24 Oct 2000 16:07:55 GMT Received: from fmsmsx29.FM.INTEL.COM ([132.233.48.29]) by 132.233.48.202 (Norton AntiVirus for Internet Email Gateways 1.0) ; Tue, 24 Oct 2000 16:06:39 0000 (GMT) Received: by fmsmsx29.fm.intel.com with Internet Mail Service (5.5.2650.21) id ; Tue, 24 Oct 2000 09:06:37 -0700 Message-ID: From: "Agarwal, Aseem" To: "'Arnoud van Wijk (ELN)'" , "'Jonathan Rosenberg'" , "'Piotr S. Kossowski'" Cc: sip@lists.bell-labs.com Subject: RE: [SIP] Multi-message UDP datagrams (probably not specified beh aviour) MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 24 Oct 2000 09:06:37 -0700 Hi Arnoud, Please find my comments below: -rgds, aseem -----Original Message----- From: Arnoud van Wijk (ELN) [mailto:Arnoud.van.Wijk@eln.ericsson.se] Sent: Tuesday, October 24, 2000 12:49 AM To: 'Agarwal, Aseem'; 'Jonathan Rosenberg'; 'Piotr S. Kossowski' Cc: sip@lists.bell-labs.com Subject: RE: [SIP] Multi-message UDP datagrams (probably not specified beh aviour) I was watching this thread with interest. It is indeed a good question if there is an implementation that sends multiple messages in one single datagram. I think that it is possible. Perhaps some dedicated SIP server that has to send many small messages to a centrally located SIP proxy. Thus instead of sending 40 UDP packets, it may be possible to place them all inside just one datagram (message size depending ofcourse). [ASEEM] Theoretically possible, but I was looking for a more realistic example. Will an application ever like to delay sending out a "small UDP datagram" in order to club it with other such smaller datagrams ?? So I would in this case make the Content-Length mandatory for that server. Splitting SIP messages over 2 or more datagrams for TCP would not matter at all since the message would be pieced together in one whole piece. Thanks to TCP, right? (just as long that the Content-Length is given, the server knows where the new message starts) In my opinion, I think that this is just a case of UA behaviour and not SIP. What I would suggest is thus that Content-Length has to be mandatory for UAS or UAC that put multiple messages in one UDP datagram. And then if there is no Content-Length given, the receiving UA can then act as in the RFC "(...)If a server receives a UDP request without Content-Length, it MUST assume that the request encompasses the remainder of the packet." Maybe it is a good idea to add to the bis-draft that Content-Length MUST be included by the UA when there are Multiple messages placed into one UDP datagram. AND when messages are (likely) to be split over 2 or more datagrams. [ASEEM] I concur with you on this point. Just my 2 Euro cents :-) Arnoud _______________________________________________________________ ERICSSON EUROLABS NETHERLANDS BV Arnoud van Wijk ABACUS Lab Research & Development (ELN/V) Fax: +31-161 247569 _______________________________________________________________ -----Original Message----- From: Agarwal, Aseem [mailto:aseem@trillium.com] Sent: maandag 23 okt 2000 20:55 To: 'Jonathan Rosenberg'; 'Piotr S. Kossowski'; unlisted-recipients Cc: sip@lists.bell-labs.com Subject: RE: [SIP] Multi-message UDP datagrams (probably not specified beh aviour) Hi all, Is there a realistic situation where some implementation will send multiple messages in a single datagram ? If NOT, then is it not better to remove this source of confusion from the new version of the draft. Another related point is about transport of SIP messages using TCP. Since it is possible to receive partial or more than one SIP message in one TCP-recv() call, an implementation has to put in extra logic to determine the end of the message, e.g. find out the CRLF CRLF sequence, then check for Content-Length header, wait for the remaining bytes and so on.. One option may be to have an application level framing mechanism (something similar to TPKT -rfc 1006) to simplify things. What is the general opinion about this issue ? -regards, aseem -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Monday, October 23, 2000 10:50 AM To: 'Piotr S. Kossowski'; unlisted-recipients Cc: sip@lists.bell-labs.com Subject: RE: [SIP] Multi-message UDP datagrams (probably not specified beh aviour) > -----Original Message----- > From: Piotr S. Kossowski [mailto:P.Kossowski@elka.pw.edu.pl] > Sent: Monday, October 23, 2000 1:42 PM > To: unlisted-recipients > Cc: sip@lists.bell-labs.com > Subject: [SIP] Multi-message UDP datagrams (probably not specified > behaviour) > > > > Hello, > > After further studying of Multiple response per UDP datagram issue, > and Content-Length header, I suppose that inaccuracy may appear. > > Scenario: first let's forget about single UAC that sends > many messages in one datagram. > Let's assume that in UDP datagram received by UAS there are > two messages, > however (perhaps, because of unique implementation of proxy that > multiplexes messages to one datagram...). These messages may > be not correlated and both did NOT contatin Content-Length, > and both have correct syntax (and semantics, as well). > Their orginators assumed that UAS would distinguish body > from message according to section 6.18 of the spec: > > "(...)If a server receives a UDP request without Content-Length, > it MUST assume that the request encompasses the remainder of > the packet." > > So UAS starts parsing of message and it assumes that the body > is to the end of the packet. And this is not true because > such body will contain body from the first message and all the > remainder: headers from the second message plus the second > body etc. Well, thats because the implementation that has sent multiple responses has erred. If it puts multiple responses in a packet it has to use Content-Length, else what you have described will happen. > I have also another question: > > Table 4 from section 6.4 of the spec. assumes for Content-Length > in Methods to be "m*", what indicates that the header SHOULD be sent, > but servers need to be prepared to receive requests without > that header > field. > > Is there any important reason for "m*" instead of "m" for > this header ? Yes. It was not mandatory in rfc2543. So, for backwards compatibility, you must be prepared to deal with that (of course, an rfc2543 implementation would still need to put CL in the response if it were sending multiple messages per datagram). --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 24 12:31:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA25035 for ; Tue, 24 Oct 2000 12:31:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A02684433D; Tue, 24 Oct 2000 11:31:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from thalia.fm.intel.com (thalia.fm.intel.com [132.233.247.11]) by lists.bell-labs.com (Postfix) with ESMTP id E4EBD4433A for ; Tue, 24 Oct 2000 11:25:32 -0400 (EDT) Received: from SMTP (fmsmsxvs05-1.fm.intel.com [132.233.42.205]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.32 2000/10/12 22:57:04 dmccart Exp $) with SMTP id QAA00297; Tue, 24 Oct 2000 16:26:23 GMT Received: from fmsmsx28.fm.intel.com ([132.233.48.28]) by 132.233.48.205 (Norton AntiVirus for Internet Email Gateways 1.0) ; Tue, 24 Oct 2000 16:25:07 0000 (GMT) Received: by fmsmsx28.fm.intel.com with Internet Mail Service (5.5.2650.21) id ; Tue, 24 Oct 2000 09:25:05 -0700 Message-ID: From: "Agarwal, Aseem" To: "'Henning G. Schulzrinne'" , "Agarwal, Aseem" Cc: "'Jonathan Rosenberg'" , "'Piotr S. Kossowski'" , sip@lists.bell-labs.com Subject: RE: [SIP] Multi-message UDP datagrams (probably not specified beh aviour) MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 24 Oct 2000 09:25:02 -0700 Hi Henning, I have a different viewpoint. Collating EACH TCP message, searching for CRLF CRLF, waiting for Content-Length bytes, etc., can be avoided by adding message length to each SIP message. In my implementation, I do not want to use fgets, I wish to be able to read whatever data is available in my TCP socket. So I am forced to search for CRLF CRLF sequence in EVERY TCP read call and then exercise TCP collation logic. I see this as an extra overhead. In my previous email, TPKT was quoted as a suggestion. SIP can very well have a new general header "Message-Length" or this parameter may be added on to "Request-Line" and "Response-Line". Computing and adding this header should not be an overhead. It shall definitely simplify logic on the receiving end. Since an implementation can know how many bytes to wait for in all cases. Regards, aseem -----Original Message----- From: Henning G. Schulzrinne [mailto:hgs@cs.columbia.edu] Sent: Monday, October 23, 2000 2:23 PM To: Agarwal, Aseem Cc: 'Jonathan Rosenberg'; 'Piotr S. Kossowski'; sip@lists.bell-labs.com Subject: Re: [SIP] Multi-message UDP datagrams (probably not specified behaviour) "Agarwal, Aseem" wrote: > > Hi all, > Is there a realistic situation where some implementation will > send multiple messages in a single datagram ? If NOT, then is it > not better to remove this source of confusion from the new version > of the draft. > > Another related point is about transport of SIP messages using > TCP. Since it is possible to receive partial or more than one SIP message > in one TCP-recv() call, an implementation has to put in extra logic to > determine the end of the message, e.g. find out the CRLF CRLF sequence, > then check for Content-Length header, wait for the remaining bytes and > so on.. > > One option may be to have an application level framing mechanism > (something similar to TPKT -rfc 1006) to simplify things. What is the > general opinion about this issue ? > > -regards, > aseem > > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Monday, October 23, 2000 10:50 AM > To: 'Piotr S. Kossowski'; unlisted-recipients > Cc: sip@lists.bell-labs.com > Subject: RE: [SIP] Multi-message UDP datagrams (probably not specified > beh aviour) > > > > > -----Original Message----- > > From: Piotr S. Kossowski [mailto:P.Kossowski@elka.pw.edu.pl] > > Sent: Monday, October 23, 2000 1:42 PM > > To: unlisted-recipients > > Cc: sip@lists.bell-labs.com > > Subject: [SIP] Multi-message UDP datagrams (probably not specified > > behaviour) > > > > > > > > Hello, > > > > After further studying of Multiple response per UDP datagram issue, > > and Content-Length header, I suppose that inaccuracy may appear. > > > > Scenario: first let's forget about single UAC that sends > > many messages in one datagram. > > Let's assume that in UDP datagram received by UAS there are > > two messages, > > however (perhaps, because of unique implementation of proxy that > > multiplexes messages to one datagram...). These messages may > > be not correlated and both did NOT contatin Content-Length, > > and both have correct syntax (and semantics, as well). > > Their orginators assumed that UAS would distinguish body > > from message according to section 6.18 of the spec: > > > > "(...)If a server receives a UDP request without Content-Length, > > it MUST assume that the request encompasses the remainder of > > the packet." > > > > So UAS starts parsing of message and it assumes that the body > > is to the end of the packet. And this is not true because > > such body will contain body from the first message and all the > > remainder: headers from the second message plus the second > > body etc. > > Well, thats because the implementation that has sent multiple responses has > erred. If it puts multiple responses in a packet it has to use > Content-Length, else what you have > described will happen. > > > I have also another question: > > > > Table 4 from section 6.4 of the spec. assumes for Content-Length > > in Methods to be "m*", what indicates that the header SHOULD be sent, > > but servers need to be prepared to receive requests without > > that header > > field. > > > > Is there any important reason for "m*" instead of "m" for > > this header ? > > Yes. It was not mandatory in rfc2543. So, for backwards compatibility, > you must be prepared to deal with that (of course, an rfc2543 implementation > would still need to put CL in the response if it were sending multiple > messages per datagram). > In my view, bad idea. It diverges from what's being done in HTTP and RTSP, for no gain. Also, as soon as you add RFC 1006, it's no longer a text protocol, so you loose some of the advantages. It also adds yet another error condition, where the Content-Length disagrees with the RFC 1006 length. In practice, as discussed previously, TCP parsing is 50 lines of code: read lines until blank line (using fgets or whatever), then parse header, then read message body, or some variation on this theme. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 24 12:54:15 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA28422 for ; Tue, 24 Oct 2000 12:54:14 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id BFBBD4433A; Tue, 24 Oct 2000 11:54:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lists.bell-labs.com (Postfix) with ESMTP id BFBCA44336 for ; Tue, 24 Oct 2000 11:53:03 -0400 (EDT) Received: from mailserver1.ericsson.se (mailserver1.ericsson.se [136.225.152.91]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id e9OGqvZ01204; Tue, 24 Oct 2000 18:52:57 +0200 (MEST) Received: from lmf.ericsson.se (rcur181ip224.ericsson.se [147.214.181.224]) by mailserver1.ericsson.se (8.9.3/8.9.3/eri-1.0) with ESMTP id SAA24898; Tue, 24 Oct 2000 18:52:55 +0200 (MET DST) Message-ID: <39F5BE68.658E9B8B@lmf.ericsson.se> 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: William Marshall Cc: jdrosen@dynamicsoft.com, sip@lists.bell-labs.com Subject: Re: FW: [SIP] Feedback on manyfolks References: <200010232147.RAA27966@fish-ha.research.att.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 24 Oct 2000 19:52:56 +0300 Content-Transfer-Encoding: 7bit Hi Bill, There is one scenario you are missing. The UAC wants to send a COMET (UAC->UAS), but it is not interested in receiving a COMET from the UAS. An scenario containing just one COMET from the UAC to the UAS is already in the manyfolks draft, but there, the decision is made by the UAS. The UAS is the one deciding that it whishes to receive the COMET from the UAC. That's why it adds a confirm in the response. In the scenario I am after, the UAC is the one that makes the decision. He wants the UAS to stop the session establishment until there is a COMET from the UAC to the UAS. But he is not interested in the COMET in the other direction. Your suggestion does not solve this problem. Best regards, Gonzalo William Marshall wrote: > > This discussion took me a little while to figure out, because there > was clearly something missing in the manyfolks draft that I wasn't > seeing. > > The current manyfolks draft shows two examples, one where a confirmation > is requested by the UAS from the UAC, and one where two confirmations > are requested, first by the UAC from the UAS, then by the UAS from the UAC. > > However, (and the part I missed several times re-re-re-reading the draft), > the wording of the spec also allows the UAC to request a confirmation from > the UAS without the UAS requesting a confirmation from the UAC. This > seems pointless. > > |----(1)INVITE------->| > |<---(2)183-----------| > |----(3)PRACK-------->| > |<---(4)200-----------| > |<---(5)COMET---------| > |----(6)200---------->| > |<---(7)180-----------| > > If message (1)INVITE includes a request for a confirmation, i.e. (5)COMET, > but message (2)183 does not also request a confirmation, then there is > nothing the UAC can do upon receipt of the (5)COMET. The UAS is already > doing the alerting and the (7)180 is probably already on its way. The fact > that (7)180 is sent indicates the resource preconditions were met by UAS, > because otherwise it would have responded with a 580-precondition-failure > response. So why even bother with (5)COMET? > > My original intention in writing the procedures for the two-way COMET > exchange was that it be triggered by the UAC requesting a confirmation. > The UAS, on receipt of a SDP containing a precondition line with a > confirmation request, MUST include a precondition line in its SDP with > a confirmation request. This text doesn't appear, and would solve > the problem presented by third party call control. > > Did anyone see a case where the one-way confirmation shown in the > diagram above was actually useful and should be allowed? Otherwise, > I think we should add the requirement on UAS behavior. > > If the response to the INVITE(with confirmation requested) is a 180, or > a 183 without a precondition line, it indicates the UAS doesn't support > the resource extension. A 183 response with a precondition line that > doesn't include a confirmation would also, in this case, indicate lack > support of the UAS (or lack of sanity). > > Bill Marshall > wtm@research.att.com > > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > Sent: Thursday, October 12, 2000 1:38 AM > To: Jonathan Rosenberg > Cc: 'sip' > Subject: Re: [SIP] Feedback on manyfolks > > Hi, > > I agree. This is getting pretty complex. > > Anyway, for this specific matter we have three choices: > > 1) COMET is always mandatory in both directions. It does not matter if > the preconditions are mandatory or optional. > > 2) COMET is mandatory just when the preconditions are mandatory. > > 3) COMET is just sent when requested by any of the parties. This would > be the mechanism used so far (with the extension defined in > draft-camarillo-manyfolks-confirm-00.txt) > > Approach number 1 is the simplest. After doing whatever in order to > fulfil the preconditions a COMET is sent. > > Number 2 is also pretty simple. If the preconditions were mandatory, the > session is stopped until the COMET is sent. If the preconditions were > optional the session establishment goes on, so no COMET is sent. > > The gain of approach number 3 is that it saves some messages. However, > as you pointed out, they are not a lot. In the most common situation it > would save 2 messages (1 RTT). This is when A calls B in a two-party > session where there is just one COMET from A towards B. The COMET from B > to A is not normally needed since B just begins alerting the user once > the preconditions are met. > > So, we have a little more complexity for a little gain. > > My only concern is the amonut of signalling messages that we already > have for establishing a session using preconditions (PRACKs, COMETs). A > RTT for a workstation in an ethernet is not a big deal, but for a > terminal using a cellular access begins to be more important. > > Anyway, I do not have a religious position here, so any of the 3 > solutions is alright for me. Let's pick one and go on resolving > different issues. > > Opinions? > > Regards, > > Gonzalo > > Jonathan Rosenberg wrote: > > > > Its just thats its more options, more complexities ontop of a thing which > is > > growing more and more complex. We need to remove options, not add them. I > > don't see what they need is for the negotiation. We need to justify the > > existence of it, not the elimination of it. > > > > -Jonathan R. > > > > --- > > Jonathan D. Rosenberg 72 Eagle Rock Ave. > > Chief Scientist First Floor > > dynamicsoft East Hanover, NJ 07936 > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > > http://www.dynamicsoft.com > > > > > -----Original Message----- > > > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > > Sent: Tuesday, October 10, 2000 10:46 AM > > > To: Jonathan Rosenberg > > > Cc: 'sip' > > > Subject: Re: [SIP] Feedback on manyfolks > > > > > > > > > Hi, > > > > > > Certainly we are not talking about tons of messages. However, in this > > > case I would rather let the confim be negotiated. The negotiation is > > > rather simple. > > > > > > The UAC can request: > > > 1) No COMET > > > 2) one COMET UAC->UAS > > > 3) one COMET UAC- > > 4) two COMETs > > > > > > The UAS should accept what the UAC requests, and possibly request more > > > (e.g. two COMETs when the UAC just requested one). > > > > > > I believe this is not a complicated mechanism. It is just a > > > deterministic two-way handshake. > > > > > > Best regards, > > > > > > Gonzalo > > > > > > > > > > > > Jonathan Rosenberg wrote: > > > > > > > > This seems reasonable to me, and needed, as Gonzalo points out. > > > > > > > > My only issue is whether all this stuff should be optional > > > at all. Wouldn't > > > > it be easier if both sides always sent COMET, period? All > > > this negotiation > > > > stuff is a pain. We're not talking tons of messages here. > > > Can't we keep it > > > > simple? > > > > > > > > -Jonathan R. > > > > > > > > --- > > > > Jonathan D. Rosenberg 72 Eagle Rock Ave. > > > > Chief Scientist First Floor > > > > dynamicsoft East Hanover, NJ 07936 > > > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > > > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > > > > http://www.dynamicsoft.com > > > > > > > > > -----Original Message----- > > > > > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > > > > Sent: Monday, October 09, 2000 2:33 AM > > > > > To: sip > > > > > Subject: [SIP] Feedback on manyfolks > > > > > > > > > > > > > > > Hi, > > > > > > > > > > Here you have a new I-D that contains feedback on the > > > manyfolks draft. > > > > > > > > > > http://search.ietf.org/internet-drafts/draft-camarillo-manyfol > > > > > ks-confirm-00.txt > > > > > > > > > > " > > > > > Abstract > > > > > > > > > > This document describes certain functionality that is > > > > > missing in the > > > > > current "Integration of Resource Management and SIP" > > > [1] (a.k.a. > > > > > manyfolks draft). An extension to add this functionality is > > > > > outlined. > > > > > > > > > > This functionality is needed in general to provide richer > > > > > signalling > > > > > capabilities and can be employed in several scenarios. > > > This draft > > > > > describes its use in third party call control applications. > > > > > > > > > > If this extension is accepted it is foreseen that this > > > draft would > > > > > be merged with [1]. > > > > > " > > > > > > > > > > Best regards, > > > > > > > > > > Gonzalo > > > > > -- > > > > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > > > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > > > > Telecom R&D Fax : +358 9 299 30 52 > > > > > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > > > > > Finland http://www.hut.fi/~gonzalo > > > > > > > > > > _______________________________________________ > > > > > SIP mailing list > > > > > SIP@lists.bell-labs.com > > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > > > > -- > > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > > Telecom R&D Fax : +358 9 299 30 52 > > > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > > > Finland http://www.hut.fi/~gonzalo > > > > > > _______________________________________________ > > > SIP mailing list > > > SIP@lists.bell-labs.com > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > -- > Gonzalo Camarillo Phone : +358 9 299 33 71 > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > Telecom R&D Fax : +358 9 299 30 52 > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > Finland http://www.hut.fi/~gonzalo > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 24 13:14:08 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA01168 for ; Tue, 24 Oct 2000 13:14:07 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 632F544388; Tue, 24 Oct 2000 12:03:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lists.bell-labs.com (Postfix) with ESMTP id 666A54433D for ; Tue, 24 Oct 2000 11:04:10 -0400 (EDT) Received: from ms.uab.ericsson.se (ms.uab.ericsson.se [134.138.201.16]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id e9OG43Z22516 for ; Tue, 24 Oct 2000 18:04:03 +0200 (MEST) Received: from uabx04c384.uab.ericsson.se.uab.ericsson.se (uabx04c384 [134.138.229.144]) by ms.uab.ericsson.se (8.10.0/8.10.0/uab-2.26) with ESMTP id e9OG43n03409 for ; Tue, 24 Oct 2000 18:04:03 +0200 (MET DST) Received: from uab.ericsson.se by uabx04c384.uab.ericsson.se.uab.ericsson.se (8.8.7/client-1.3uab1) id SAA07717; Tue, 24 Oct 2000 18:04:02 +0200 (MET DST) Message-ID: <39F5B2EE.9F47F54@uab.ericsson.se> From: Bertil Engelholm Organization: Ericsson Utvecklings AB X-Mailer: Mozilla 4.74C-CCK-MCD [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: sv,en-US MIME-Version: 1.0 To: sip@lists.bell-labs.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] Sending ACKs using Request-URI ?? Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 24 Oct 2000 18:03:58 +0200 Content-Transfer-Encoding: 7bit Hi again, I now have another question. It says in the specification that ACKs should be sent according to the REQUEST-URI. Why shouldn't it be sent according to ROUTE ? Isn't there a risc that the message will take another path through the network if you use the REQUEST-URI ? -- Bertil Engelholm AXE Research and Development voice : +46 8 727 3499 SIP Security Fax : +46 8 647 8276 S-126 25 Stockholm Sweden E-mail: Bertil.Engelholm@uab.ericsson.se _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 24 13:16:12 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA01451 for ; Tue, 24 Oct 2000 13:16:11 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0A6424438D; Tue, 24 Oct 2000 12:03:12 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id E55C144336 for ; Tue, 24 Oct 2000 11:59:13 -0400 (EDT) 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 MAA19417; Tue, 24 Oct 2000 12:58:56 -0400 (EDT) Message-ID: <39F5BFD1.3128DD02@cs.columbia.edu> From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "Agarwal, Aseem" Cc: "'Jonathan Rosenberg'" , "'Piotr S. Kossowski'" , sip@lists.bell-labs.com Subject: Re: [SIP] Multi-message UDP datagrams (probably not specified behaviour) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 24 Oct 2000 12:58:57 -0400 Content-Transfer-Encoding: 7bit The time for such proposals was about three years ago. Let's not waste time on proposing changes that break every existing SIP implementation to save 50 lines of code. That's the last I say about this. "Agarwal, Aseem" wrote: > > Hi Henning, > I have a different viewpoint. Collating EACH TCP message, searching > for CRLF CRLF, waiting for Content-Length bytes, etc., can be avoided by > adding > message length to each SIP message. > In my implementation, I do not want to use fgets, I wish to be able to > read > whatever data is available in my TCP socket. So I am forced to search for > CRLF > CRLF sequence in EVERY TCP read call and then exercise TCP collation logic. > I see > this as an extra overhead. > > In my previous email, TPKT was quoted as a suggestion. SIP can very well > have > a new general header "Message-Length" or this parameter may be added on to > "Request-Line" > and "Response-Line". > > Computing and adding this header should not be an overhead. It shall > definitely > simplify logic on the receiving end. Since an implementation can know how > many bytes > to wait for in all cases. > > Regards, > aseem > -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 24 13:29:32 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA03071 for ; Tue, 24 Oct 2000 13:29:31 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D9C184439D; Tue, 24 Oct 2000 12:22:07 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from godzilla.ipdialog.com (ipsniffers-122.fiasj.net [208.238.222.122]) by lists.bell-labs.com (Postfix) with ESMTP id 9892844398 for ; Tue, 24 Oct 2000 12:21:26 -0400 (EDT) Received: from ipdialog.com (IDENT:hch@repoman.ipdialog.com [208.238.222.70]) by godzilla.ipdialog.com (8.9.3/8.8.7) with ESMTP id KAA27944; Tue, 24 Oct 2000 10:06:53 -0700 Message-ID: <39F5C1AD.C0008A3C@ipdialog.com> From: Howard Hart Organization: ipDialog, Inc. X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i586) X-Accept-Language: en MIME-Version: 1.0 To: archow@hss.hns.com Cc: "Arnoud van Wijk (ELN)" , "'Agarwal, Aseem'" , "'Jonathan Rosenberg'" , "'Piotr S. Kossowski'" , sip@lists.bell-labs.com Subject: Re: [SIP] Multi-message UDP datagrams (probably not specifiedbehaviour) References: <65256982.002F0D4A.00@sampark.hss.hns.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 24 Oct 2000 10:06:53 -0700 Content-Transfer-Encoding: 7bit Hi Arjun, I think this is covered (implicitly) in sections 3 and 4 of 2543: generic message = headers... CRLF [message body] By implication, you haven't received the complete header section (including Content-Length) until the first empty CRLF line, so buffer processing needs to wait until the remainder of the packet is received or the connection is lost/times out. Corrupted Content-Length headers should probably be handled by throwing the entire message out with a 400 class response, keeping in mind that a TPKT byte sequence is as no more or less likely to be corrupted then the Content-Length header. Henning, if you're out there, any chance we can be even more explicit in 6.18 and specify there must always be a CRLF even in messages with Content-Length=0, and the Content-Length counter does not include that CRLF? Howard Hart ipDialog, Inc. archow@hss.hns.com wrote: > Arnoud> Splitting SIP messages over 2 or more datagrams for TCP > Arnoud> would not matter at all since the message would be pieced > Arnoud> together in one whole piece. Thanks to TCP, right? (just > Arnoud> as long that the Content-Length is given, the server knows where > Arnoud> the new message starts) > > Not directly related to your point, but here goes: > > My main point of concern with TCP is more to do with the buffer the user > specifies > while reception. My worry is more to do with application reassembling > rather than > TCP/IP stack re-assembing. The current logic of finding out message length > for TCP is > read a buffer, grep for Content-Length,say value X. if bytesRead < X read > X-bytesRead > more bytes, cat it as a complete message and then go ahead to do a parse. > However, what if the recipient does a read() with a buffer B. It is > possible that in > the first read, he does not get the content-length header. Or maybe he gets > half of it. > Then what does he do ? He has to add more code to handle these scenarios > just to ensure > that he has the complete message. All this stems from the fact that the > header that actually > may specify length of the message can occur anywhere in between the header > section. So, > the user can never be sure that there will not be a scenario where he > cannot figure out the > length of the message after the first read(). Also in this method, his read > buffer > must be large enough to accomodate the first content-length header - which > is a heuristic > value.Since he does not know how big a message is, he cannot do an alloc > just for that much > (if he wants to). > Things are relatively fine if we assume that the first read gets the > complete > C-Len header. All this could be avoided if for stream > oriented protocols we have a concept similar to TPKT. I think this point > has been > raised several times, but it was decided not to do anything similar to > TPKT. > The bad part is that this makes is protocol specific. Good part is that it > avoids > these application level re-assembling worries. > So the question is, how important is each, relatively ? > I would like some comments from other implementors too - do you find the > existing > mechanism sufficient for you, do you find it inappropriate, > or is there a neat solution which someone has out there which you can share > ? > > Regds > Arjun > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 24 13:40:18 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA04469 for ; Tue, 24 Oct 2000 13:40:17 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 19812443B0; Tue, 24 Oct 2000 12:33:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id DB2E444399 for ; Tue, 24 Oct 2000 12:32:52 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id NAA16059; Tue, 24 Oct 2000 13:34:59 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <4WS2X6JJ>; Tue, 24 Oct 2000 13:28:49 -0400 Message-ID: From: Jonathan Rosenberg To: "'Bertil Engelholm'" , sip@lists.bell-labs.com Subject: RE: [SIP] Sending ACKs using Request-URI ?? MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 24 Oct 2000 13:28:48 -0400 ACKs for non-200 are hop by hop, and thus need to be sent the same place the request was sent. ACKs for 200 do indeed follow the Route headers. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com > -----Original Message----- > From: Bertil Engelholm [mailto:Bertil.Engelholm@uab.ericsson.se] > Sent: Tuesday, October 24, 2000 12:04 PM > To: sip@lists.bell-labs.com > Subject: [SIP] Sending ACKs using Request-URI ?? > > > Hi again, > > I now have another question. It says in the specification > that ACKs should be sent according to the REQUEST-URI. > > Why shouldn't it be sent according to ROUTE ? > > Isn't there a risc that the message will take another path > through the network if you use the REQUEST-URI ? > > -- > Bertil Engelholm > AXE Research and Development voice : +46 8 727 3499 > SIP Security Fax : +46 8 647 8276 > S-126 25 Stockholm Sweden E-mail: > Bertil.Engelholm@uab.ericsson.se > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 24 14:09:00 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA08169 for ; Tue, 24 Oct 2000 14:08:56 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4C9A044384; Tue, 24 Oct 2000 13:03:06 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from smtprch2.nortel.com (smtprch2.nortelnetworks.com [192.135.215.15]) by lists.bell-labs.com (Postfix) with ESMTP id 7F83B4436C for ; Tue, 24 Oct 2000 13:02:31 -0400 (EDT) Received: from zrchb200.us.nortel.com (actually zrchb200) by smtprch2.nortel.com; Tue, 24 Oct 2000 12:53:11 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2652.35) id <4VMDFYZ5>; Tue, 24 Oct 2000 12:57:16 -0500 Message-ID: <36FA02BD7083D411BC9E0000F8073E43FD75BC@crchy271.us.nortel.com> From: "Brian Stucker" To: "Agarwal, Aseem" Cc: sip@lists.bell-labs.com Subject: RE: [SIP] Multi-message UDP datagrams (probably not specified beh aviour) MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C03DE3.D308E560" X-Orig: Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 24 Oct 2000 12:57:07 -0500 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_01C03DE3.D308E560 Content-Type: text/plain; charset="iso-8859-1" Actually, if you were going to do it, why not get the information in a manner that solves a couple of problems: generic-message = start-line length-header *message-header CRLF [ message-body ] length-header = Length: SP [message-length]/[message-body start] Example: INVITE sip:bob@blah.com SIP/2.0 Length: 500/234 ... Where message-length is the total message length, and message-body start is the byte offset that the message body actually begins at. This would help for a couple of reasons: 1. If you just say that it's a message header, then it can appear at basically anywhere in the message. Instead of searching for CRLF CRLF every time for TCP, now you'll need to search for "Length: " which is even worse. If you require it up front then you know exactly where to expect it. Moreover, you'll know exactly when you're not going to get it (so you can stop looking) and so you can switchover to looking for CRLF pairs again because the sender doesn't support that header. 2. If you give the message length early on, then you will know how much buffer to reserve right away. No more guessing, or dynamic buffer resizing problems. You get your message in, you see the length, and you can immediately create the right sized buffer knowing you're not going to be wasting space or have to resize your buffer. This isn't a big problem for small systems, but every little bit of efficiency you can squeeze into the message helps for larger systems. It would be best (in my mind) to include the message length/start as the first token in the start-line, but I imagine doing that would seriously confuse the SIP parsers that are already out there and cause problems. Pretty much, you're stuck with the current tokenization scheme for the start-line from now on, unless there's a requirement that parsers look for the sip version (i.e. look for the "SIP/2.0" in the first line) before doing anything else. MTP/SCCP is nice in this respect because they have pointers embedded in the message that tell you the start offsets and data lengths that you're dealing with. Brian Stucker Nortel Networks -----Original Message----- From: Agarwal, Aseem [mailto:aseem@trillium.com] Sent: Tuesday, October 24, 2000 11:25 AM To: 'Henning G. Schulzrinne'; Agarwal, Aseem Cc: 'Jonathan Rosenberg'; 'Piotr S. Kossowski'; sip@lists.bell-labs.com Subject: RE: [SIP] Multi-message UDP datagrams (probably not specified beh aviour) Hi Henning, I have a different viewpoint. Collating EACH TCP message, searching for CRLF CRLF, waiting for Content-Length bytes, etc., can be avoided by adding message length to each SIP message. In my implementation, I do not want to use fgets, I wish to be able to read whatever data is available in my TCP socket. So I am forced to search for CRLF CRLF sequence in EVERY TCP read call and then exercise TCP collation logic. I see this as an extra overhead. In my previous email, TPKT was quoted as a suggestion. SIP can very well have a new general header "Message-Length" or this parameter may be added on to "Request-Line" and "Response-Line". Computing and adding this header should not be an overhead. It shall definitely simplify logic on the receiving end. Since an implementation can know how many bytes to wait for in all cases. Regards, aseem -----Original Message----- From: Henning G. Schulzrinne [mailto:hgs@cs.columbia.edu] Sent: Monday, October 23, 2000 2:23 PM To: Agarwal, Aseem Cc: 'Jonathan Rosenberg'; 'Piotr S. Kossowski'; sip@lists.bell-labs.com Subject: Re: [SIP] Multi-message UDP datagrams (probably not specified behaviour) "Agarwal, Aseem" wrote: > > Hi all, > Is there a realistic situation where some implementation will > send multiple messages in a single datagram ? If NOT, then is it > not better to remove this source of confusion from the new version > of the draft. > > Another related point is about transport of SIP messages using > TCP. Since it is possible to receive partial or more than one SIP message > in one TCP-recv() call, an implementation has to put in extra logic to > determine the end of the message, e.g. find out the CRLF CRLF sequence, > then check for Content-Length header, wait for the remaining bytes and > so on.. > > One option may be to have an application level framing mechanism > (something similar to TPKT -rfc 1006) to simplify things. What is the > general opinion about this issue ? > > -regards, > aseem > > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Monday, October 23, 2000 10:50 AM > To: 'Piotr S. Kossowski'; unlisted-recipients > Cc: sip@lists.bell-labs.com > Subject: RE: [SIP] Multi-message UDP datagrams (probably not specified > beh aviour) > > > > > -----Original Message----- > > From: Piotr S. Kossowski [mailto:P.Kossowski@elka.pw.edu.pl] > > Sent: Monday, October 23, 2000 1:42 PM > > To: unlisted-recipients > > Cc: sip@lists.bell-labs.com > > Subject: [SIP] Multi-message UDP datagrams (probably not specified > > behaviour) > > > > > > > > Hello, > > > > After further studying of Multiple response per UDP datagram issue, > > and Content-Length header, I suppose that inaccuracy may appear. > > > > Scenario: first let's forget about single UAC that sends > > many messages in one datagram. > > Let's assume that in UDP datagram received by UAS there are > > two messages, > > however (perhaps, because of unique implementation of proxy that > > multiplexes messages to one datagram...). These messages may > > be not correlated and both did NOT contatin Content-Length, > > and both have correct syntax (and semantics, as well). > > Their orginators assumed that UAS would distinguish body > > from message according to section 6.18 of the spec: > > > > "(...)If a server receives a UDP request without Content-Length, > > it MUST assume that the request encompasses the remainder of > > the packet." > > > > So UAS starts parsing of message and it assumes that the body > > is to the end of the packet. And this is not true because > > such body will contain body from the first message and all the > > remainder: headers from the second message plus the second > > body etc. > > Well, thats because the implementation that has sent multiple responses has > erred. If it puts multiple responses in a packet it has to use > Content-Length, else what you have > described will happen. > > > I have also another question: > > > > Table 4 from section 6.4 of the spec. assumes for Content-Length > > in Methods to be "m*", what indicates that the header SHOULD be sent, > > but servers need to be prepared to receive requests without > > that header > > field. > > > > Is there any important reason for "m*" instead of "m" for > > this header ? > > Yes. It was not mandatory in rfc2543. So, for backwards compatibility, > you must be prepared to deal with that (of course, an rfc2543 implementation > would still need to put CL in the response if it were sending multiple > messages per datagram). > In my view, bad idea. It diverges from what's being done in HTTP and RTSP, for no gain. Also, as soon as you add RFC 1006, it's no longer a text protocol, so you loose some of the advantages. It also adds yet another error condition, where the Content-Length disagrees with the RFC 1006 length. In practice, as discussed previously, TCP parsing is 50 lines of code: read lines until blank line (using fgets or whatever), then parse header, then read message body, or some variation on this theme. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip ------_=_NextPart_001_01C03DE3.D308E560 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [SIP] Multi-message UDP datagrams (probably not specified = beh aviour)

Actually, if you were going to do it, why not get the = information in a manner that solves a couple of problems:

generic-message =3D start-line
        =         =         length-header
          &nb= sp;       *message-header
          &nb= sp;       CRLF
          &nb= sp;       [ message-body ]


length-header =3D Length: SP = [message-length]/[message-body start]

Example:

     INVITE sip:bob@blah.com = SIP/2.0
     Length: 500/234
     ...

Where message-length is the total message length, and = message-body start is the byte offset that the message body actually = begins at. This would help for a couple of reasons:

1. If you just say that it's a message header, then = it can appear at basically anywhere in the message. Instead of = searching for CRLF CRLF every time for TCP, now you'll need to search = for "Length: " which is even worse. If you require it up = front then you know exactly where to expect it. Moreover, you'll know = exactly when you're not going to get it (so you can stop looking) and = so you can switchover to looking for CRLF pairs again because the = sender doesn't support that header.

2. If you give the message length early on, then you = will know how much buffer to reserve right away. No more guessing, or = dynamic buffer resizing problems. You get your message in, you see the = length, and you can immediately create the right sized buffer knowing = you're not going to be wasting space or have to resize your buffer. = This isn't a big problem for small systems, but every little bit of = efficiency you can squeeze into the message helps for larger = systems.

It would be best (in my mind) to include the message = length/start as the first token in the start-line, but I imagine doing = that would seriously confuse the SIP parsers that are already out there = and cause problems. Pretty much, you're stuck with the current = tokenization scheme for the start-line from now on, unless there's a = requirement that parsers look for the sip version (i.e. look for the = "SIP/2.0" in the first line) before doing anything = else.

MTP/SCCP is nice in this respect because they have = pointers embedded in the message that tell you the start offsets and = data lengths that you're dealing with.

Brian Stucker
Nortel Networks

-----Original Message-----
From: Agarwal, Aseem [mailto:aseem@trillium.com]=
Sent: Tuesday, October 24, 2000 11:25 AM
To: 'Henning G. Schulzrinne'; Agarwal, Aseem
Cc: 'Jonathan Rosenberg'; 'Piotr S. Kossowski'; = sip@lists.bell-labs.com
Subject: RE: [SIP] Multi-message UDP datagrams = (probably not specified
beh aviour)


Hi Henning,
    I have a different viewpoint. = Collating EACH TCP message, searching
for CRLF CRLF, waiting for Content-Length bytes, = etc., can be avoided by
adding
message length to each SIP message.
    In my implementation, I do not = want to use fgets, I wish to be able to
read
whatever data is available in my TCP socket. So I am = forced to search for
CRLF
CRLF sequence in EVERY TCP read call and then = exercise TCP collation logic.
I see
this as an extra overhead.

    In my previous email, TPKT was = quoted as a suggestion. SIP can very well
have
a new general header "Message-Length" or = this parameter may be added on to
"Request-Line"
and "Response-Line".

    Computing and adding this header = should not be an overhead.  It shall
definitely
simplify logic on the receiving end. Since an = implementation can know how
many bytes
to wait for in all cases.

Regards,
aseem

-----Original Message-----
From: Henning G. Schulzrinne [mailto:hgs@cs.columbia.edu]
Sent: Monday, October 23, 2000 2:23 PM
To: Agarwal, Aseem
Cc: 'Jonathan Rosenberg'; 'Piotr S. Kossowski'; = sip@lists.bell-labs.com
Subject: Re: [SIP] Multi-message UDP datagrams = (probably not specified
behaviour)


"Agarwal, Aseem" wrote:
>
> Hi all,
>   Is there a realistic situation = where some implementation will
> send multiple messages in a single datagram ? = If NOT, then is it
> not better to remove this source of confusion = from the new version
> of the draft.
>
>    Another related point is = about transport of SIP messages using
> TCP. Since it is possible to receive partial or = more than one SIP message
> in one TCP-recv() call, an implementation has = to put in extra logic to
> determine the end of the message, e.g. find out = the CRLF CRLF sequence,
> then check for Content-Length header, wait for = the remaining bytes and
> so on..
>
>   One option may be to have an = application level framing mechanism
> (something similar to TPKT -rfc 1006) to = simplify things. What is the
> general opinion about this issue ?
>
> -regards,
> aseem
>
> -----Original Message-----
> From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> Sent: Monday, October 23, 2000 10:50 AM
> To: 'Piotr S. Kossowski'; = unlisted-recipients
> Cc: sip@lists.bell-labs.com
> Subject: RE: [SIP] Multi-message UDP datagrams = (probably not specified
> beh aviour)
>
>
>
> > -----Original Message-----
> > From: Piotr S. Kossowski [mailto:P.Kossowski@elka.pw.ed= u.pl]
> > Sent: Monday, October 23, 2000 1:42 = PM
> > To: unlisted-recipients
> > Cc: sip@lists.bell-labs.com
> > Subject: [SIP] Multi-message UDP datagrams = (probably not specified
> > behaviour)
> >
> >
> >
> > Hello,
> >
> > After further studying of Multiple = response per UDP datagram issue,
> > and Content-Length header, I suppose that = inaccuracy may appear.
> >
> > Scenario: first let's forget about single = UAC that sends
> > many messages in one datagram.
> > Let's assume that in UDP datagram received = by UAS there are
> > two messages,
> > however (perhaps, because of unique = implementation of proxy that
> > multiplexes messages to one datagram...). = These messages may
> > be not correlated and both did NOT = contatin Content-Length,
> > and both have correct syntax (and = semantics, as well).
> > Their orginators assumed that UAS would = distinguish body
> > from message according to section 6.18 of = the spec:
> >
> > "(...)If a server receives a UDP = request without Content-Length,
> > it MUST assume that the request = encompasses the remainder of
> > the packet."
> >
> > So UAS starts parsing of message and it = assumes that the body
> > is to the end of the packet. And this is = not true because
> > such body will contain body from the first = message and all the
> > remainder: headers from the second message = plus the second
> > body etc.
>
> Well, thats because the implementation that has = sent multiple responses
has
> erred. If it puts multiple responses in a = packet it has to use
> Content-Length, else what you have
> described will happen.
>
> > I have also another question:
> >
> > Table 4 from section 6.4 of the spec. = assumes for Content-Length
> > in Methods to be "m*", what = indicates that the header SHOULD be sent,
> > but servers need to be prepared to receive = requests without
> > that header
> > field.
> >
> > Is there any important reason for = "m*" instead of "m" for
> > this header ?
>
> Yes. It was not mandatory in rfc2543. So, for = backwards compatibility,
> you must be prepared to deal with that (of = course, an rfc2543
implementation
> would still need to put CL in the response if = it were sending multiple
> messages per datagram).
>

In my view, bad idea. It diverges from what's being = done in HTTP and
RTSP, for no gain. Also, as soon as you add RFC = 1006, it's no longer a
text protocol, so you loose some of the advantages. = It also adds yet
another error condition, where the Content-Length = disagrees with the RFC
1006 length. In practice, as discussed previously, = TCP parsing is 50
lines of code: read lines until blank line (using = fgets or whatever),
then parse header, then read message body, or some = variation on this
theme.

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


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip

------_=_NextPart_001_01C03DE3.D308E560-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 24 15:36:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA19563 for ; Tue, 24 Oct 2000 15:36:02 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 337064433A; Tue, 24 Oct 2000 14:36:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from elektron.elka.pw.edu.pl (elektron.elka.pw.edu.pl [194.29.160.2]) by lists.bell-labs.com (Postfix) with ESMTP id 81C5B44337 for ; Tue, 24 Oct 2000 14:35:45 -0400 (EDT) Received: from dial-barska28.warman.com.pl ([195.164.232.29]:1548 "EHLO elka.pw.edu.pl") by elektron.elka.pw.edu.pl with ESMTP id ; Tue, 24 Oct 2000 21:35:36 +0200 Message-ID: <39F5E43A.CBDE2922@elka.pw.edu.pl> From: "Piotr S. Kossowski" Organization: Warsaw University of Technology - Institute of Telecommunications X-Mailer: Mozilla 4.7 [pl] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] Changing session description by callee Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 24 Oct 2000 21:34:19 +0200 Content-Transfer-Encoding: 7bit Hi, I've got a basic question (my appolgies): Are callee and caller symmetrical after establishing a call ? I mean, Can callee change session descripiton for the call (re-"INVITE"?) or the only what it can do is send BYE ? Best Regards, Piotr _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 24 15:40:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA20446 for ; Tue, 24 Oct 2000 15:40:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6F84844354; Tue, 24 Oct 2000 14:40:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 6793D44337 for ; Tue, 24 Oct 2000 14:39:45 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id PAA18598; Tue, 24 Oct 2000 15:41:50 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <4WS2X651>; Tue, 24 Oct 2000 15:35:41 -0400 Message-ID: From: Jonathan Rosenberg To: "'Piotr S. Kossowski'" , sip@lists.bell-labs.com Subject: RE: [SIP] Changing session description by callee MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 24 Oct 2000 15:35:40 -0400 Yes, its symmetrical. Either side can send a re-INVITE. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com > -----Original Message----- > From: Piotr S. Kossowski [mailto:P.Kossowski@elka.pw.edu.pl] > Sent: Tuesday, October 24, 2000 3:34 PM > To: sip@lists.bell-labs.com > Subject: [SIP] Changing session description by callee > > > Hi, > > I've got a basic question (my appolgies): > > Are callee and caller symmetrical after establishing a call ? > I mean, Can callee change session descripiton for the call > (re-"INVITE"?) > or the only what it can do is send BYE ? > > Best Regards, Piotr > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 24 17:59:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA17903 for ; Tue, 24 Oct 2000 17:59:00 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7707144337; Tue, 24 Oct 2000 16:59:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from itecid1.telecom-co.net (unknown [200.21.27.173]) by lists.bell-labs.com (Postfix) with ESMTP id 7DBD544336 for ; Tue, 24 Oct 2000 15:42:19 -0400 (EDT) Received: from mabol ([200.21.27.154]) by itecid1.telecom-co.net (8.9.3+Sun/8.9.1) with SMTP id PAA02650 for ; Tue, 24 Oct 2000 15:49:52 +0500 (GMT) Message-ID: <00aa01c03dfa$d599d200$9a1b15c8@mabol.telecom-co.net> From: "=?iso-8859-1?Q?Mauricio_Bola=F1os_Arturo?=" To: "Lista SIP" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00A7_01C03DD0.ECA852C0" 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 Subject: [SIP] how much does it cost? Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 24 Oct 2000 15:41:49 -0500 This is a multi-part message in MIME format. ------=_NextPart_000_00A7_01C03DD0.ECA852C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi everyone! Anybody knows or has an idea how much the SIP solution (APIs for User = Agent and Servers) cost? or could be it cost?? Mauricio Bola=F1os Arturo ITEC-TELECOM Bogot=E1 Colombia http://itec.telecom-co.net ------=_NextPart_000_00A7_01C03DD0.ECA852C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi everyone!
Anybody knows or has an idea how = much the SIP=20 solution (APIs for User Agent and Servers) cost? or could be it=20 cost??
 
Mauricio Bolaños = Arturo
ITEC-TELECOM
Bogotá Colombia
http://itec.telecom-co.net=
 
 
------=_NextPart_000_00A7_01C03DD0.ECA852C0-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 24 18:30:06 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA21566 for ; Tue, 24 Oct 2000 18:30:06 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 789FA44337; Tue, 24 Oct 2000 17:30:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from elektron.elka.pw.edu.pl (elektron.elka.pw.edu.pl [194.29.160.2]) by lists.bell-labs.com (Postfix) with ESMTP id D5D4D44336 for ; Tue, 24 Oct 2000 17:29:49 -0400 (EDT) Received: from dial-barska42.warman.com.pl ([195.164.232.43]:2132 "EHLO elka.pw.edu.pl") by elektron.elka.pw.edu.pl with ESMTP id ; Wed, 25 Oct 2000 00:29:25 +0200 Message-ID: <39F60D5C.5F122591@elka.pw.edu.pl> From: "Piotr S. Kossowski" Organization: Warsaw University of Technology - Institute of Telecommunications X-Mailer: Mozilla 4.7 [pl] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Subject: [SIP] Unfortunate description of 400 resp. in the spec Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 25 Oct 2000 00:29:48 +0200 Content-Transfer-Encoding: 8bit Hi, Keeping in mind our discussion about Content-Length I've just noticed description in section 7.4.1 of the spec: "7.4.1 400 Bad Request The request could not be understood due to malformed syntax. The Reason-Phrase SHOULD identify the syntax problem in more detail, e.g., “Missing Content-Length header”." I realize this is only an example, which is almost not important, but saying that “Missing Content-Length header” is a syntax problem is not fortunate example, at present... I would recommend exchange this example with phrase e.g. "Missing Call-Id header" because Call-Id is ALWAYS MANDATORY and its missing in a message makes syntax error, in fact. BTW, For error handling due to Content-Length, 411 (Length Required) response is destinated. Regards, Piotr _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 24 18:39:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA22608 for ; Tue, 24 Oct 2000 18:39:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C96DD4433B; Tue, 24 Oct 2000 17:39:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from zrtps06s.us.nortel.com (unknown [47.140.48.50]) by lists.bell-labs.com (Postfix) with ESMTP id F2EDB44337 for ; Tue, 24 Oct 2000 17:38:31 -0400 (EDT) Received: from zrtpd004.us.nortel.com by zrtps06s.us.nortel.com; Tue, 24 Oct 2000 14:51:31 -0400 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id <44WRG23Q>; Tue, 24 Oct 2000 14:47:28 -0400 Message-ID: <28560036253BD41191A10000F8BCBD110250C611@zcard00g.ca.nortel.com> From: "Tom-PT Taylor" To: "'Arnoud van Wijk (ELN)'" , "Sip (E-mail)" Subject: RE: [SIP] The definition of Multi-media MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C03DEA.D7697C30" X-Orig: Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 24 Oct 2000 14:47:21 -0400 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_01C03DEA.D7697C30 Content-Type: text/plain; charset="iso-8859-1" The definition I have used at ITU-T SG 16 is that multimedia communications involve the coordinated transmission of different media types (i.e. voice, text, images, video). We should make the distinction between capabilities and what happens in a given session. Your file transfer in itself is not a multimedia operation, but the complete process of encoding video and sound and putting them both into the same file, transmitting them, and playing them out at the far end is a multimedia process. Then you get into the temporal aspects. In particular, conversational multimedia involves two-way exchange of multiple media streams in real time. > -----Original Message----- > From: Arnoud van Wijk (ELN) [mailto:Arnoud.van.Wijk@eln.ericsson.se] > Sent: Tuesday, October 10, 2000 10:59 AM > To: Sip (E-mail) > Subject: [SIP] The definition of Multi-media > > > Hello all. > I am encountering more and more issues about the definition > of multimedia. > > We at the SIP WG are actually enabling Multimedia IP (VoIP is > just the beginning). > > Is multimedia now streaming video, audio and voice? > Would an RTP stream with text be multimedia? > Would a file send to your mobile device be multimedia? > (downloaded movie vs streaming video). > Would an instant message sent to your buddy via SIP be part > of multi-media? > And IRC like chat via SIP? > > My definition of Multimedia is real-time receiving of > different media, which is audio and video and written data. > No difference between streaming or download and then play. In > fact everything that SIP does or initiates. :-) (but not SIP itself). > > If any of you has a clear definition of Multimedia and > possibly also the source, I will be very grateful. > I do not want this to start a long discussion thread. But to > make our work easier (and improve communications with > managers and vendors so that we will indeed talk about the same case). > > Thanks > > Arnoud > > _______________________________________________________________ > ERICSSON EUROLABS NETHERLANDS BV > Arnoud van Wijk > ABACUS Lab > Research & Development (ELN/V) > Fax: +31-161 247569 > _______________________________________________________________ > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > ------_=_NextPart_001_01C03DEA.D7697C30 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [SIP] The definition of Multi-media

The definition I have used at ITU-T SG 16 is that = multimedia communications involve the coordinated transmission of = different media types (i.e. voice, text, images, video).  We = should make the distinction between capabilities and what happens in a = given session.  Your file transfer in itself is not a multimedia = operation, but the complete process of encoding video and sound and = putting them both into the same file, transmitting them, and playing = them out at the far end is a multimedia process.

Then you get into the temporal aspects.  In = particular, conversational multimedia involves two-way exchange of = multiple media streams in real time.

> -----Original Message-----
> From: Arnoud van Wijk (ELN) [mailto:Arnoud.van.Wijk@e= ln.ericsson.se]
> Sent: Tuesday, October 10, 2000 10:59 AM
> To: Sip (E-mail)
> Subject: [SIP] The definition of = Multi-media
>
>
> Hello all.
> I am encountering more and more issues about = the definition
> of multimedia.
>
> We at the SIP WG are actually enabling = Multimedia IP (VoIP is
> just the beginning).
>
> Is multimedia now streaming video, audio and = voice?
> Would an RTP stream with text be = multimedia?
> Would a file send to your mobile device be = multimedia?
> (downloaded movie vs streaming video).
> Would an instant message sent to your buddy via = SIP be part
> of multi-media?
> And IRC like chat via SIP?
>
> My definition of Multimedia is real-time = receiving of
> different media, which is audio and video and = written data.
> No difference between streaming or download and = then play. In
> fact everything that SIP does or initiates. :-) = (but not SIP itself).
>
> If any of you has a clear definition of = Multimedia and
> possibly also the source, I will be very = grateful.
> I do not want this to start a long discussion = thread. But to
> make our work easier (and improve = communications with
> managers and vendors so that we will indeed = talk about the same case).
>
> Thanks
>
> Arnoud
>
> = _______________________________________________________________
> ERICSSON EUROLABS NETHERLANDS BV
> Arnoud van Wijk
> ABACUS Lab
> Research & Development (ELN/V)
> Fax: +31-161 247569
> = _______________________________________________________________
>
>
>
> = _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip
>

------_=_NextPart_001_01C03DEA.D7697C30-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 24 19:08:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA26073 for ; Tue, 24 Oct 2000 19:08:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1605444337; Tue, 24 Oct 2000 18:08:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id C29F244336 for ; Tue, 24 Oct 2000 18:07:35 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id TAA22186; Tue, 24 Oct 2000 19:09:42 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <4WS2X7QT>; Tue, 24 Oct 2000 19:03:32 -0400 Message-ID: From: Igor Slepchin To: "'Christer Holmberg'" , sip@lists.bell-labs.com Cc: sean.olson@ericsson.com Subject: RE: [SIP] Redirect server returning new From header MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 24 Oct 2000 19:03:31 -0400 You can use URL headers to specify SIP message headers, e.g., the Contact in the 302 may look like Contact: sip:chirster@ericsson?from=tel:12345 It's then up to the UAC to trust your redirect server and overwrite its default From header. See section 2 of 2543bis for details. --- Igor Slepchin > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > Sent: Tuesday, October 24, 2000 5:39 AM > To: sip@lists.bell-labs.com > Cc: sean.olson@ericsson.com > Subject: Re: [SIP] Redirect server returning new From header > > > > Hi, > > >Do you actually mean the From: or do you mean the To:? > > From. > > >It seems a bit odd for a redirect server to tell the UAC what > >From: to use. Perhaps you could give an example of its usage. > > Well, this is - once again - related to the PSTN/SIP GW > issue, if the GW > needs a telephone number for some kind of A number analysis. > When I make > a phone call from my SIP phone I may not know that the call may end up > on the PSTN side, so I can for example put my email address > in the From > header. However, since the network architecture includes a GW to the > PSTN network, somewhere there could be a server which is able > to do the > mapping between the email address user part and a telephone > number user > part (if SIP URL is used). > > Regards, > > Christer Holmberg > Ericsson Finland > > > > > > Regards, > > Sean > > > > -- > > Sean Olson > > > > Christer Holmberg wrote: > > > > > Another proposal on the issue, with another use of the "Also-From" > > > header. > > > > > > Currently, a redirect server add a new Request-URI (in > the 3xx response > > > Contact header) to the UAC. An idea would be that it > could also return a > > > new From header, for example with a telephone number. In > this case, the > > > UAC, and intermediate proxies, would not need to insert any extra > > > headers or URI parameters in the request. This would be a > new, optional, > > > feature in a redirect server. > > > > > > Comments? > > > > > > Christer Holmberg > > > Ericsson Finland > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 24 21:18:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA10827 for ; Tue, 24 Oct 2000 21:18:03 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6DD5644337; Tue, 24 Oct 2000 20:18:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sargasso.cse.msu.edu (sargasso.cse.msu.edu [35.9.20.10]) by lists.bell-labs.com (Postfix) with ESMTP id 9A57E44336 for ; Tue, 24 Oct 2000 20:17:34 -0400 (EDT) Received: from arctic.cse.msu.edu (arctic.cse.msu.edu [35.9.20.20]) by sargasso.cse.msu.edu (8.8.8/8.8.8) with ESMTP id VAA22535 for ; Tue, 24 Oct 2000 21:17:29 -0400 (EDT) Received: (from singhtaj@localhost) by arctic.cse.msu.edu (8.8.8/8.8.8) id VAA00835 for sip@lists.bell-labs.com; Tue, 24 Oct 2000 21:17:29 -0400 (EDT) Received: from arctic.cse.msu.edu (arctic.cse.msu.edu [35.9.20.20]) by sargasso.cse.msu.edu (8.8.8/8.8.8) with ESMTP id VAA22428 for ; Tue, 24 Oct 2000 21:15:35 -0400 (EDT) From: Tajindrapal Singh Received: (from singhtaj@localhost) by arctic.cse.msu.edu (8.8.8/8.8.8) id VAA00668 for singhtaj@cse.msu.edu; Tue, 24 Oct 2000 21:15:35 -0400 (EDT) Message-Id: <200010250115.VAA00668@arctic.cse.msu.edu> To: singhtaj@cse.msu.edu In-Reply-To: from "Igor Slepchin" at Oct 24, 2000 07:03:31 PM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] Help with SIP Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 24 Oct 2000 21:15:35 -0400 (EDT) Content-Transfer-Encoding: 7bit Hi, I am trying to build Instant messenger on top of SIP, but having some problems. First, is there a SIP server available where I can register myself and see if the Instant messenger is working or not ? Second, By reading the documentation I understand that there is a SIP server and SIP client. Just to make it clear, does the SIP server involve in authentication (registar)? OR is it simply a daemon running on a machine and waiting for conections from other sIP servers ? Third, to build an Instant messenger.. Would I build it on top of a SIP client? OR can I build it independently of the sip client.? The questions might me trivial for some people...But please understand I am a beginner in terms of knowing SIP... Any suggestions and comments will be greatly appreciated. Thanks T.Singh _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 25 01:48:14 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA03806 for ; Wed, 25 Oct 2000 01:48:10 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 90DF344337; Wed, 25 Oct 2000 00:48:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lists.bell-labs.com (Postfix) with ESMTP id 4F63D44336 for ; Wed, 25 Oct 2000 00:47:45 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id e9P5lcZ05284; Wed, 25 Oct 2000 07:47:38 +0200 (MEST) 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 IAA12188; Wed, 25 Oct 2000 08:47:36 +0300 (EET DST) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.73]) by greymse1.lmf.ericsson.se (8.9.3 (PHNE_18979)/8.8.6) with ESMTP id IAA14976; Wed, 25 Oct 2000 08:47:34 +0300 (EETDST) Message-ID: <39F673F0.C9E4A09A@lmf.ericsson.se> From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Cc: Igor Slepchin , sean.olson@ericsson.com Subject: Re: [SIP] Redirect server returning new From header References: Content-Type: multipart/mixed; boundary="------------19C3C6C22086769F7ACE506F" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 25 Oct 2000 08:47:28 +0300 This is a multi-part message in MIME format. --------------19C3C6C22086769F7ACE506F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, >You can use URL headers to specify SIP message headers, e.g., the Contact >in the 302 may look like > >Contact: sip:chirster@ericsson?from=tel:12345 > >It's then up to the UAC to trust your redirect server and overwrite its >default From header. See section 2 of 2543bis for details. True, but in this case the redirect server (what I mean by that is actually any SIP node, server or UA, with redirect functionality...) will not know if the UAC is going to use the new header or not. For some reason, the redirect server may behave in different ways (maybe, in some case, it won't even allow the UAC to contact a certain host if the feature is not supported...) depending on if it can give the UAC a new From header or not. But, if we have a new header for this, the UAC can indicate in the Supported header that it supports this feature. Then, the redirect server can add the new "Also-From" header in the response, and indicate in the Require header that the UAC must use it. Maybe this is possible also in the case where you just add it to the Contact header, but in any case I think you would have to define a new Supported/Require tag value (?) Regards, Christer Holmberg Ericsson Finland > > --- > Igor Slepchin > > > -----Original Message----- > > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > > Sent: Tuesday, October 24, 2000 5:39 AM > > To: sip@lists.bell-labs.com > > Cc: sean.olson@ericsson.com > > Subject: Re: [SIP] Redirect server returning new From header > > > > > > > > Hi, > > > > >Do you actually mean the From: or do you mean the To:? > > > > From. > > > > >It seems a bit odd for a redirect server to tell the UAC what > > >From: to use. Perhaps you could give an example of its usage. > > > > Well, this is - once again - related to the PSTN/SIP GW > > issue, if the GW > > needs a telephone number for some kind of A number analysis. > > When I make > > a phone call from my SIP phone I may not know that the call may end up > > on the PSTN side, so I can for example put my email address > > in the From > > header. However, since the network architecture includes a GW to the > > PSTN network, somewhere there could be a server which is able > > to do the > > mapping between the email address user part and a telephone > > number user > > part (if SIP URL is used). > > > > Regards, > > > > Christer Holmberg > > Ericsson Finland > > > > > > > > > > Regards, > > > Sean > > > > > > -- > > > Sean Olson > > > > > > Christer Holmberg wrote: > > > > > > > Another proposal on the issue, with another use of the "Also-From" > > > > header. > > > > > > > > Currently, a redirect server add a new Request-URI (in > > the 3xx response > > > > Contact header) to the UAC. An idea would be that it > > could also return a > > > > new From header, for example with a telephone number. In > > this case, the > > > > UAC, and intermediate proxies, would not need to insert any extra > > > > headers or URI parameters in the request. This would be a > > new, optional, > > > > feature in a redirect server. > > > > > > > > Comments? > > > > > > > > Christer Holmberg > > > > Ericsson Finland > > --------------19C3C6C22086769F7ACE506F Content-Type: text/x-vcard; charset=us-ascii; name="christer.holmberg.vcf" Content-Description: Card for Christer Holmberg Content-Disposition: attachment; filename="christer.holmberg.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Holmberg;Christer tel;cell:+358-40-5604412 tel;work:+358-9-2992943 x-mozilla-html:FALSE org:Ericsson;Advanced Signalling Research Laboratory adr:;;;;;; version:2.1 email;internet:christer.holmberg@lmf.ericsson.se title:System Designer fn:Christer Holmberg end:vcard --------------19C3C6C22086769F7ACE506F-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 25 02:10:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA16791 for ; Wed, 25 Oct 2000 02:10:02 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4D79544337; Wed, 25 Oct 2000 01:10:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from web1401.mail.yahoo.com (web1401.mail.yahoo.com [128.11.23.165]) by lists.bell-labs.com (Postfix) with SMTP id F173644336 for ; Wed, 25 Oct 2000 01:09:07 -0400 (EDT) Received: (qmail 15881 invoked by uid 60001); 25 Oct 2000 06:09:02 -0000 Message-ID: <20001025060902.15880.qmail@web1401.mail.yahoo.com> Received: from [206.82.141.26] by web1401.mail.yahoo.com; Tue, 24 Oct 2000 23:09:02 PDT From: zeeshan razzaque To: SIP@lists.bell-labs.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [SIP] help on REGISTER Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 24 Oct 2000 23:09:02 -0700 (PDT) Hi, Can one SIP UA REGISTER itself by numerous Aliases on the same port. I mean the sip URL for the multiple Aliases is same. Thanx. Zeeshan. __________________________________________________ Do You Yahoo!? Yahoo! Messenger - Talk while you surf! It's FREE. http://im.yahoo.com/ _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 25 02:12:08 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA17240 for ; Wed, 25 Oct 2000 02:12:08 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6C1B144361; Wed, 25 Oct 2000 01:11:06 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mail.speedventures.com (unknown [212.75.74.99]) by lists.bell-labs.com (Postfix) with ESMTP id E0D0944361 for ; Wed, 25 Oct 2000 01:10:17 -0400 (EDT) Received: from HASH ([192.168.27.104]) by mail.speedventures.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id V22M5VTW; Wed, 25 Oct 2000 08:06:18 +0200 From: "Hisham Khartabil" To: "Bertil Engelholm" , Cc: "Jonathan Rosenberg" Subject: RE: [SIP] multiple responses ?? Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: <39F5672C.60A75012@uab.ericsson.se> Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 25 Oct 2000 09:09:39 +0300 Content-Transfer-Encoding: 7bit > -----Original Message----- > From: sip-admin@lists.bell-labs.com > [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Bertil Engelholm > Sent: 24. lokakuuta 2000 13:41 > To: SIP@lists.bell-labs.com > Cc: Jonathan Rosenberg > Subject: Re: [SIP] multiple responses ?? > > > Jonathan Rosenberg wrote: > > > > > > > > > -----Original Message----- > > > From: Bertil Engelholm [mailto:Bertil.Engelholm@uab.ericsson.se] > > > Sent: Monday, October 23, 2000 12:20 PM > > > To: sip@lists.bell-labs.com > > > Subject: [SIP] multiple responses ?? > > > > > > > > > Hi, > > > > > > I have some questions regarding the possibility to forward > > > best vs. forward all responses. > > > > Forward all simply does not work. > > > > A proxy can forward one or more 200 responses (and indeed, really must > > forward all of them), since those are ACKed end to end. > Non-200s are ACKed > > hop by hop. A proxy or client receiving multiple non-200 > responses to the > > same request will have no way to distinguish them, and the > state machines > > currently defined would not work. > > OK, that simplifies things a bit. > > > > > > > > > First of all I wonder if this is not a function that should > > > be decided by the UA e.g. by setting a special header ? > > > > Caller preferences addresses some simple cases where a UAC can request > > specific service from proxies. But, since forward-all-responses doesn't > > work, having a caller prefs value for it doesn't seem that useful. > > Maybe I used the wrong term here. Forward all seems not allowed > as you explained above. But there are still two different behaviours. > Either the proxy only forwards the best response or it forwards > all 200 responses. The problem I see is that a UA don't know if > it's going to receive one or several 200 responses. So it has > to be prepared to always receive several 200 responses. If you > MUST set a header to get all 200 responses instead of only the > best a UA can decide that it will not handle that case (by not > setting the header). You must not set any header. You will get all 200 responses. If you don't want to accept the second one, ACK it then send a BYE (then wait for 200OK for BYE) > > > > > > > It's the UA (the User) that knows if he like to get all > > > responses and choose himself or let the network choose the > > > best response. Why should each server take this decision ? > > > > We did it this way (forwarding only the best response) so that it would > > scale and work in a reasonable fashion. > > > > > > > > Secondly I have a question regarding the proxy behaviour in > > > the following case. > > > > > > ------ ------ > > > | |----->| P2 |---->???? > > > ------ | | ------ > > > | Ca |----->| P1 | > > > ------ | | ------ > > > | |----->| P3 |---->???? > > > ------ ------ > > > > > > If Ca calls someone at P1 which forks the call to P2 and P3 how > > > should P1 behave in the following cases if it has the policy to > > > fork the best response. > > > > > > If P2 (or someone behind P2) have the policy to fork all responses > > > it means that P1 can get several final responses. > > > > Only multiple 200. > > > > > Which of these > > > reponses should be used in the best choice by P1 ? > > > Only the first one that happens to arrive ? > > > Everyone that arrives before you get a response from P3 ? > > > > Beyond 200s, picking which is the best of the non-200 responses > is defined > > by the spec (600, then 300, then 400, then 500 in that order). > However, a > > proxy could choose an alternate definition of best amongst the > non-200 final > > responses it gets, since there are no interoperability issues > which choosing > > an alternate algorithm. > > > > > > > > What should be done with the rest of the responses that might drop > > > in after you have sent your best response back ? > > > > There should only ever be 200s, which are forwarded upstream. > Anything else > > would be an error. > > > > > > > > You could actually have received an ACK back from Ca when another > > > response drops in from P2. What to do in this case ? > > > > Won't happen under correct operating conditions. > > I'm not shure I understand why this can't happen. If P2 > can send several 200 responses back to P1 I guess they can > come at any time (depending on when someone answers at the > other end). So lets say that the first 200 that is received > from P2 is choosen as the best result and sent back to Ca. > Ca now ACK this OK to P1 because Ca don't know it will > get more 200 responses later on. P1 sends the ACK to P2. Another > UA behind P2 somewhere now answers the same call which leads > to a second 200 response from P2 to P1. And this second > 200 response will belong to another CALL-LEG since the TO-tag > is different. Maybe I have misunderstood something completly > but this is how we have read the specification. If this > can't happen it would simplify things but I don't understand > why it can't happen. This can happen. You do exactly what i described above. Regards, Hisham > > > > > -Jonathan R. > > --- > > Jonathan D. Rosenberg 72 Eagle Rock Ave. > > Chief Scientist First Floor > > dynamicsoft East Hanover, NJ 07936 > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > > http://www.dynamicsoft.com > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > -- > Bertil Engelholm > AXE Research and Development voice : +46 8 727 3499 > SIP Security Fax : +46 8 647 8276 > S-126 25 Stockholm Sweden E-mail: > Bertil.Engelholm@uab.ericsson.se > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 25 02:55:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA28370 for ; Wed, 25 Oct 2000 02:55:02 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 337644433F; Wed, 25 Oct 2000 01:55:06 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mail.speedventures.com (unknown [212.75.74.99]) by lists.bell-labs.com (Postfix) with ESMTP id E5A4244337 for ; Wed, 25 Oct 2000 01:54:35 -0400 (EDT) Received: from HASH ([192.168.27.104]) by mail.speedventures.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id V22M5VVV; Wed, 25 Oct 2000 08:50:27 +0200 From: "Hisham Khartabil" To: "Christer Holmberg" , Subject: RE: [SIP] Redirect server returning new From header Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: <39F673F0.C9E4A09A@lmf.ericsson.se> Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 25 Oct 2000 09:53:47 +0300 Content-Transfer-Encoding: 7bit Christer, Normally, you contact a redirect server to get contact information about a Callee. That callee has to registered with a registrar that co-exists with the redirect server. Now you are asking that registrar to return info about you (the caller). Is that right? Regards, Hisham > -----Original Message----- > From: sip-admin@lists.bell-labs.com > [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Christer Holmberg > Sent: 25. lokakuuta 2000 8:47 > To: sip@lists.bell-labs.com > Cc: Igor Slepchin; sean.olson@ericsson.com > Subject: Re: [SIP] Redirect server returning new From header > > > > Hi, > > >You can use URL headers to specify SIP message headers, e.g., > the Contact >in the 302 may look like > > > >Contact: sip:chirster@ericsson?from=tel:12345 > > > >It's then up to the UAC to trust your redirect server and overwrite its > >default From header. See section 2 of 2543bis for details. > > True, but in this case the redirect server (what I mean by that is > actually any SIP node, server or UA, with redirect functionality...) > will not know if the UAC is going to use the new header or not. For some > reason, the redirect server may behave in different ways (maybe, in some > case, it won't even allow the UAC to contact a certain host if the > feature is not supported...) depending on if it can give the UAC a new > From header or not. > > But, if we have a new header for this, the UAC can indicate in the > Supported header that it supports this feature. Then, the redirect > server can add the new "Also-From" header in the response, and indicate > in the Require header that the UAC must use it. Maybe this is possible > also in the case where you just add it to the Contact header, but in any > case I think you would have to define a new Supported/Require tag value > (?) > > Regards, > > Christer Holmberg > Ericsson Finland > > > > > > > --- > > Igor Slepchin > > > > > -----Original Message----- > > > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > > > Sent: Tuesday, October 24, 2000 5:39 AM > > > To: sip@lists.bell-labs.com > > > Cc: sean.olson@ericsson.com > > > Subject: Re: [SIP] Redirect server returning new From header > > > > > > > > > > > > Hi, > > > > > > >Do you actually mean the From: or do you mean the To:? > > > > > > From. > > > > > > >It seems a bit odd for a redirect server to tell the UAC what > > > >From: to use. Perhaps you could give an example of its usage. > > > > > > Well, this is - once again - related to the PSTN/SIP GW > > > issue, if the GW > > > needs a telephone number for some kind of A number analysis. > > > When I make > > > a phone call from my SIP phone I may not know that the call may end up > > > on the PSTN side, so I can for example put my email address > > > in the From > > > header. However, since the network architecture includes a GW to the > > > PSTN network, somewhere there could be a server which is able > > > to do the > > > mapping between the email address user part and a telephone > > > number user > > > part (if SIP URL is used). > > > > > > Regards, > > > > > > Christer Holmberg > > > Ericsson Finland > > > > > > > > > > > > > > Regards, > > > > Sean > > > > > > > > -- > > > > Sean Olson > > > > > > > > Christer Holmberg wrote: > > > > > > > > > Another proposal on the issue, with another use of the "Also-From" > > > > > header. > > > > > > > > > > Currently, a redirect server add a new Request-URI (in > > > the 3xx response > > > > > Contact header) to the UAC. An idea would be that it > > > could also return a > > > > > new From header, for example with a telephone number. In > > > this case, the > > > > > UAC, and intermediate proxies, would not need to insert any extra > > > > > headers or URI parameters in the request. This would be a > > > new, optional, > > > > > feature in a redirect server. > > > > > > > > > > Comments? > > > > > > > > > > Christer Holmberg > > > > > Ericsson Finland > > > > > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 25 03:53:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA10880 for ; Wed, 25 Oct 2000 03:53:02 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A1B8D4433F; Wed, 25 Oct 2000 02:53:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mail-in.audiocodes.com (AC-INT-LP.ser.netvision.net.il [212.143.113.33]) by lists.bell-labs.com (Postfix) with ESMTP id 7C13A44337 for ; Wed, 25 Oct 2000 02:52:05 -0400 (EDT) Received: by MAIL-IN with Internet Mail Service (5.5.2650.21) id ; Wed, 25 Oct 2000 09:50:26 +0200 Message-ID: <81C3E8FE6C0AD4119D49009027C3AAB28C263F@MAIL-IN> From: Michel Eilat To: sip@lists.bell-labs.com MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="windows-1255" Subject: [SIP] SIP test tool Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 25 Oct 2000 09:50:26 +0200 Does anyone knows about SIP test tool for window (95/98/NT). The kind that allow a user to generate SIP methods upon request as he wishes , and sends it to another SIP application. It could be use for testing the correctness of a SIP parser and the effectivness of a SIP stack for example. Michel Eilat Audiocodes LTD 4 Hahoresh St, P.O.Box 14 Yehud 56470 Israel Direct: +972-3-5394160 Fax: +972-3-5394040 Email: michel.eilat@audiocodes.com Web Site: http://www.audiocodes.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 25 04:12:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA14961 for ; Wed, 25 Oct 2000 04:12:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1C56244360; Wed, 25 Oct 2000 03:12:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from drago1.ubiquity.net (unknown [194.202.146.92]) by lists.bell-labs.com (Postfix) with SMTP id 4C60E44344 for ; Wed, 25 Oct 2000 03:11:42 -0400 (EDT) Received: from gecko.ubiquity.co.uk by drago1.ubiquity.net via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 25 Oct 2000 08:12:14 UT Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id JAA01899; Wed, 25 Oct 2000 09:09:56 +0100 (BST) Message-ID: <39F69553.3E153FA2@ubiquity.net> From: Neil Deason Organization: Ubiquity Software Corporation Limited X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Michel Eilat Cc: sip@lists.bell-labs.com Subject: Re: [SIP] SIP test tool References: <81C3E8FE6C0AD4119D49009027C3AAB28C263F@MAIL-IN> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 25 Oct 2000 09:09:55 +0100 Content-Transfer-Encoding: 7bit There is some simple SIP Messenger Software available at: http://www.sipcenter.com/devtool.htm It is Java software that allows you to send SIP test messages from text files over UDP to your SIP implementation and, optionally, listen for responses. The messages can be sent using a command line utility or via a GUI. The SIP 'torture test' messages are supplied along with it. Cheers, Neil -- Ubiquity Software Corporation, UK http://www.ubiquity.net Michel Eilat wrote: > > Does anyone knows about SIP test tool for window (95/98/NT). The kind that > allow a user to generate SIP methods upon request as he wishes , and sends > it to another SIP application. It could be use for testing the correctness > of a SIP parser and the effectivness of a SIP stack for example. > > Michel Eilat _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 25 04:28:00 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA19637 for ; Wed, 25 Oct 2000 04:28:00 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 623794433F; Wed, 25 Oct 2000 03:28:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from drago1.ubiquity.net (unknown [194.202.146.92]) by lists.bell-labs.com (Postfix) with SMTP id 70E2D44337 for ; Wed, 25 Oct 2000 03:27:56 -0400 (EDT) Received: from gecko.ubiquity.co.uk by drago1.ubiquity.net via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 25 Oct 2000 08:28:28 UT Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id JAA11141; Wed, 25 Oct 2000 09:26:11 +0100 (BST) From: "Jo Hornsby" To: "zeeshan razzaque" , Subject: RE: [SIP] help on REGISTER Message-ID: <002b01c03e5d$3aad9930$4e34c3c1@ubiquity.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 In-Reply-To: <20001025060902.15880.qmail@web1401.mail.yahoo.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 25 Oct 2000 09:26:10 +0100 Content-Transfer-Encoding: 7bit > Hi, Can one SIP UA REGISTER itself by numerous Aliases > on the same port. I mean the sip URL for the multiple > Aliases is same. If you are asking if a SIP UA can send out say: REGISTER sip:sip-registrar.com SIP/2.0 To: sip:buffy@example.com Contact: sip:willow@ua1.example.com:5060 ... and REGISTER sip:sip-registrar.com SIP/2.0 To: sip:xander@example.com Contact: sip:willow@ua1.example.com:5060 ... then yes, this is fine. Any difficulties are likely to be due to registrar policy. HTH, - Jo. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 25 04:46:00 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA25152 for ; Wed, 25 Oct 2000 04:46:00 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id BCEBF44346; Wed, 25 Oct 2000 03:46:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from esebh01nok.ntc.nokia.com (esebh01nok.ntc.nokia.com [131.228.118.150]) by lists.bell-labs.com (Postfix) with ESMTP id 972E444344 for ; Wed, 25 Oct 2000 03:45:14 -0400 (EDT) Received: by esebh01nok with Internet Mail Service (5.5.2650.21) id ; Wed, 25 Oct 2000 11:37:30 +0300 Message-ID: From: aki.niemi@nokia.com To: sip@lists.bell-labs.com Cc: mwisdom@qualcomm.com, skumar@vovida.com Subject: RE: [SIP] Mutual Authentication (was: Digest Authentication) MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 25 Oct 2000 11:35:59 +0300 > I think that PGP authentication is great. However I am not aware > that it simplifies mutual authentication. From my understanding, > in order to accomplish mutual authentication with PGP, the server > would need to know the client's public PGP key, and the client > would need to know the server's PGP key. Having said this, I am > not aware of a standardized mechanism within SIP to authenicate > the server to the client using PGP. Just a thought, I know it's not a documented mechanism for SIP, but how about using a multipart/signed type in the SIP message body? This way, you wouldn't use any header fields and especially no nonce or cnonce values. You would simply sign your message and send it to the server who'd do the same thing. The parties would need to know each other's public keys of course. A server not implementing this mechanism would simply use the 401 Unauthorized to revert back to Digest or PGP authentication. The message hash could be produced the same way as in WWW-Authentication using PGP, e.g., including the body and some important headers of the message. Message flows: INVITE w/ multipart/signed --------------------------> 200 OK w/ multipart/signed <-------------------------- ACK --------------------------> BR, Aki Niemi _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 25 09:13:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA20303 for ; Wed, 25 Oct 2000 09:13:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5B50244358; Wed, 25 Oct 2000 08:13:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mail.mediatrix.com (mail.mediatrix.com [205.237.248.11]) by lists.bell-labs.com (Postfix) with ESMTP id 881584433F for ; Wed, 25 Oct 2000 08:12:12 -0400 (EDT) Received: by mail.mediatrix.com with Internet Mail Service (5.5.2650.21) id ; Wed, 25 Oct 2000 09:04:30 -0400 Message-ID: From: Eric Tremblay To: "'Jonathan Rosenberg'" , "'Cliff.Harris@nokia.com'" , Eric Tremblay Cc: "'sip@lists.bell-labs.com'" Subject: RE: [SIP] Possible REFER problem? MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 25 Oct 2000 09:04:30 -0400 Hi Jonathan and Cliff, I'm reviving and old thread ;) If you remember, the problem was when doing call transfer with consultation with the REFER request, how can we make sure that the INVITE request (from the Transferee to the Transfer Target) is going to reach the exact same User-Agent as the one that was consulted by the Transferor. The solution was to use the header "Accept-Contact" and specify the contact of the transfer target. I was taking a look at the caller preferences extension, thinking that "Accept-Contact" had solved our problem, but I think it does not solves the problem. Suppose we have the following participants: Transferor (Tror) - Sip address: sip:tror@acme.com - Current location: sip:tror@office1.acme.com Transferee (Tree) - Sip address: sip:tree@acme.com - Current location: sip:tree@office1.acme.com Transfer-Target (TT) - Sip address: sip:tt@acme.com - Current location: sip:tt@office4.mediatrix.com Tror and Tree have established calls. Tror contacts TT and ask if he wishes to accept the call, which he does. Tror sends the following REFER to Tree: REFER sip:tree@office1.acme.com SIP/2.0 From: sip:tror@acme.com To: sip:tree@acme.com Refer-To: sip:tt@acme.com?Accept-Contact=sip:tt@office4.mediatrix.com ... Which spawns the INVITE from Tree to a proxy server somewhere in ACME. INVITE sip:tt@acme.com SIP/2.0 From: sip:tree@acme.com To: sip:tt@acme.com Accept-Contact=sip:tt@office4.mediatrix.com Referred-By: ... ... The proxy receives this request and checks with the location server to find where can tt@acme.com be found. The list of contact returned could look like the following: Contact: sip:tt@office1.acme.com Contact: sip:tt@mediatrix.com Contact: sip:assistant@office1.acme.com Now the proxy has these 3 contacts that do not match the Accept-Contact URL, although the proxy at mediatrix.com would translate tt@mediatrix.com to tt@office4.mediatrix.com. Now the proxy does not really know which contact is prefeered, and can try any of the three contacts, and someone can happily answer at those addresses. How can we avoid this? First, I think that the Proxy should send the Accept-Contact in its downstream requests, in order to have the downstream proxies be able to use the same mechanism. But in truth, the proxy does not know if the downstream request is going to be sent to a proxy or to a UA, so it is possible for a UA to receive such a request. Would it be a good idea to have the UA take a look at the Accept-Contact header to know if the request is really for him? I think that the current caller preferences draft states that a UA should ignore these header if it receives it. Best regards, EricT > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Sunday, September 10, 2000 2:53 AM > To: 'Cliff.Harris@nokia.com'; 'etremblay@mediatrix.com' > Cc: 'sip@lists.bell-labs.com' > Subject: RE: [SIP] Possible REFER problem? > > > Rohan Mahy wrote: > > > > There is probably a way around this by having the > > Tranferor keep the > > > call up > > > > with TT (holding instead of terminating the call) AND > > making Transferee > > > send > > > > an INVITE to the proxy with the same Call-Id, From and To > > (along with > > > tags). > > > > The proxy would be tricked to think that this is a > > re-invite for the > > > > existing session between Transferor and TT and thus route > > it to only TT. > > > > Not necessarly the nicest solution. > > > > > >This won't help, since routing isn't going to be based on > > Call-ID, To, > > >and From (tags or not). You would effectively have to force > > a route, but > > >you cannot do so since you don't know a reasonable route from the > > >transferee to the TT. > > > > Why does it need to take *exactly* the same route? > > > > It doesn't. You are missing my point. Proxies don't know > about re-invites. > They don't route based on tags. The "faked" invite will have no route > headers, and thus will be routed as a brand new INVITE and be > routed with > the same non-determinism as a normal INVITE to the transfer target. > > Cliff later writes: > > > > How can extension groups be handled in SIP? For example, if > > > the URL is > > > > sip:sales@acme.com, and five phones are supposed to ring at > > > once for five > > > > different sales people (a ring-all extension group), or one > > > of five phones > > > > is supposed to ring, selected in circular fashion (a > > > circular extension > > > > group). > > > > > > However you like it. Either approach is supported. Its a > > > matter of local > > > policy in the proxy that servers acme.com. > > > > > > > But doesn't this contradict your previous statement? With > > either type of > > extension group, the REFER problem described in the original > > message of this > > thread will arise, will it not? And with a circular > extension group, a > > subsequent request could be routed to "a totally different > > location", and > > SIP would be acting as a sort of "randomization process". > > Fair enough. I had forgotten about this case in my original note. > > Cliff later writes: > > Another solution would be to use the To tag. Why not have the > > REFER-triggered INVITE include the To tag of the desired UAS > > (but a brand > > new call ID)? If the INVITE gets rejected because of the To > > tag, an INVITE > > without a To tag could then be sent, and nothing is lost. If > > a UA that is > > not the intended Transfer Target rejects the INVITE because > > it contains the > > wrong tag, then a benefit is realized. > > This won't work with tag as currently defined. It has no significance > across call legs. Since the new INVITE has a different call ID (and > certainly a different From), it is a different call leg. > > I had actually forgotten that we have alraedy defined a mechanism to > accomplish exactly what is desired here! Its the caller preferences > extension. It allows you to specify a specific contact you'd > like to reach. > > So, lets say A is talking to B. A then calls C, and wants to > transfer B to > C. The REFER from A to B would look like: > > REFER sip:B > From: sip:A > Refer-To: sip:C?Accept-Contact=sip:C.contact-address > > This has the nice property that the request URI of the INVITE > generated by B > will still be C's regular SIP address, allowing it to be > routed properly. > The Accept-Contact will help ensure that a proxy only sends > it to a specific > instance. > > This is worth noting in the REFER document. > > -Jonathan R. > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 25 10:04:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA07119 for ; Wed, 25 Oct 2000 10:04:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id AA4314434E; Wed, 25 Oct 2000 09:04:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from is1-55.antd.nist.gov (is1-60.antd.nist.gov [129.6.60.251]) by lists.bell-labs.com (Postfix) with ESMTP id E56684434E for ; Wed, 25 Oct 2000 09:03:12 -0400 (EDT) Received: from nist.gov (IDENT:mranga@stinkbug.antd.nist.gov [129.6.55.9]) by is1-55.antd.nist.gov (8.9.3/8.9.3) with ESMTP id JAA04279; Wed, 25 Oct 2000 09:58:25 -0400 (EDT) Message-ID: <39F6E816.196D41F7@nist.gov> From: "M. Ranganathan" Reply-To: mranga@nist.gov Organization: NIST advanced networking technologies group X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: Michel Eilat Cc: sip@lists.bell-labs.com Subject: Re: [SIP] SIP test tool References: <81C3E8FE6C0AD4119D49009027C3AAB28C263F@MAIL-IN> Content-Type: text/plain; charset=iso-8859-1 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 25 Oct 2000 10:03:02 -0400 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id KAA07119 I have found the columbia sipc tool to be useful in this regard. It works on Linux (maybe even windows but I have not tested it under windows) and tcl/tk. It is simple enough to modify without too much effort. Ranga. Michel Eilat wrote: > Does anyone knows about SIP test tool for window (95/98/NT). The kind that > allow a user to generate SIP methods upon request as he wishes , and sends > it to another SIP application. It could be use for testing the correctness > of a SIP parser and the effectivness of a SIP stack for example. > > Michel Eilat > > Audiocodes LTD > 4 Hahoresh St, > P.O.Box 14 Yehud 56470 > Israel > > Direct: +972-3-5394160 > Fax: +972-3-5394040 > Email: michel.eilat@audiocodes.com > Web Site: http://www.audiocodes.com > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip -- M.Ranganathan NIST Advanced Networking Technologies Group, 100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899. Tel: 301 975 3664 Fax: 301 590 0932 ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÒ ùšŠX§‚X¬µ"þX¬¶ÏÛzYÿ•¦ìýÊ&†ÛiÿÿåŠËlý·¥—ùZnÏÜ¢oæj)fjåŠËbú? From sip-admin@lists.bell-labs.com Wed Oct 25 10:07:15 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA07882 for ; Wed, 25 Oct 2000 10:07:15 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1207E44366; Wed, 25 Oct 2000 09:07:05 -0400 (EDT) Delivered-To: sip@share.research.bell-labs.com Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by lists.bell-labs.com (Postfix) with SMTP id 56FB044343 for ; Wed, 25 Oct 2000 09:06:07 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Wed Oct 25 10:05:36 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 440D244384; Wed, 25 Oct 2000 09:52:27 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from uk0006exch001h.wins.lucent.com (uk0006exch001h.uk.lucent.com [135.86.160.150]) by lists.bell-labs.com (Postfix) with ESMTP id 892C34437D for ; Wed, 25 Oct 2000 09:52:26 -0400 (EDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id <4Y6P1RZT>; Wed, 25 Oct 2000 14:52:25 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB00BCFEA@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'SIP discussion list'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Subject: [SIP] Potential definitions required Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 25 Oct 2000 14:52:25 +0100 Looking at the bis draft from a readability viewpoint I considered that a number of additional definitions at the start of the document would improve things. Could I therefore make a request that definitions are drafted for the following: stateful proxy (server) stateless proxy (server) method header Regarding the first two, the first text stating what a proxy server is in regard to stateful and stateless occurs in 12.3. The terms have been used in requirements a number of times considerably before we get to this point. Also, I vaguely remember a discussion on the list with regard to these terms, and as a result I am no longer convinced that 12.3 contains the full story regarding these terms, thus making it more important that we try and draft definitions. As regards method, it some places it apparently gets used as a synonym for message, i.e. a protocol data unit with a particular syntactic structure, and in other places it seems to carry more meaning, i.e. the above, plus the associated procedures for sending and receiving the protocol data unit. I have found no place in the text that seems to contain any words on the meaning. Given that we need to define method, it would also appear appropriate to define header as well. Any views or proposals? regards Keith Drage Keith Drage Lucent Technologies Tel: +44 1793 776249 Email: drage@lucent.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 25 10:12:18 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09016 for ; Wed, 25 Oct 2000 10:12:17 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8F6AE44370; Wed, 25 Oct 2000 09:07:12 -0400 (EDT) Delivered-To: sip@share.research.bell-labs.com Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by lists.bell-labs.com (Postfix) with SMTP id B9F6C44359 for ; Wed, 25 Oct 2000 09:06:07 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Wed Oct 25 10:05:14 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 6234D44380; Wed, 25 Oct 2000 09:52:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from uk0006exch001h.wins.lucent.com (uk0006exch001h.uk.lucent.com [135.86.160.150]) by lists.bell-labs.com (Postfix) with ESMTP id B6D7C4437D for ; Wed, 25 Oct 2000 09:52:04 -0400 (EDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id <4Y6P1RZC>; Wed, 25 Oct 2000 14:52:03 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB00BCFE9@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'SIP discussion list'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Subject: [SIP] Use of notes within the RFC bis draft Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 25 Oct 2000 14:52:00 +0100 This comment is about the documentation, rather than one of any direct technical import. I note throughout the bis draft various areas of indented text, which I assume to be the equivalent of notes in documents produced by other standards bodies. Is this true? Some of these paragraphs begin with the word "Note:" and some do not. Does this imply any difference in status of that text. There are additionally a large number of sentences throughout the text that commence: "Note that...". Are these also notes. As there is a need for other standards organisations to reference the resultant RFCs with a clear understanding of the difference between normative (i.e. requirements and definitions) and informative material (i.e. notes), I would like to propose that this distinction is made absolutely clear. In particular, I propose: - add the word "Note:" at the start of all indented text. - make all sentences starting with the words "Note that" into indented text comencing with the word "Note:". There will be some exceptions to this, as I detect the appearance of the keywords MUST, MAY and so on within some of this text. Some of these appear to me to be inappropriate, but others are obviously requirements, and should not therefore be notes. I can supply some examples to discuss individually if the editors decide to go forward with this. regards Keith Drage Keith Drage Lucent Technologies Tel: +44 1793 776249 Email: drage@lucent.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 25 11:31:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA26409 for ; Wed, 25 Oct 2000 11:31:03 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 04F0444337; Wed, 25 Oct 2000 10:31:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id AC2E744336 for ; Wed, 25 Oct 2000 10:30:57 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id LAA26833; Wed, 25 Oct 2000 11:33:00 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <4WS2X8NK>; Wed, 25 Oct 2000 11:26:48 -0400 Message-ID: From: Igor Slepchin To: "'Christer Holmberg'" , sip@lists.bell-labs.com Cc: Igor Slepchin , sean.olson@ericsson.com Subject: RE: [SIP] Redirect server returning new From header MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 25 Oct 2000 11:26:40 -0400 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > Sent: Wednesday, October 25, 2000 1:47 AM > True, but in this case the redirect server (what I mean by that is > actually any SIP node, server or UA, with redirect functionality...) > will not know if the UAC is going to use the new header or > not. Support of URL headers is required by RFC2543 so I believe your chances of encountering a UA that understands URL headers are much higher than those of encountering a UA that knows another one of the gazillion proposed extensions. > But, if we have a new header for this, the UAC can indicate in the > Supported header that it supports this feature. > Then, the redirect > server can add the new "Also-From" header in the response, > and indicate > in the Require header that the UAC must use it. A new header doesn't seem to buy you anything over URL headers. Given the fact that the support of URL headers is mandatory, I don't see much sense in defining another Supported/Require extension. Your gateway is always free to reject the INVITE if it doesn't see what it likes in the From or anywhere else in the message. --- Igor Slepchin _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 25 11:58:12 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA29872 for ; Wed, 25 Oct 2000 11:58:11 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D49704433E; Wed, 25 Oct 2000 10:58:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by lists.bell-labs.com (Postfix) with ESMTP id 9B99944336 for ; Wed, 25 Oct 2000 10:57:35 -0400 (EDT) Received: from mr4u3.ericy.com (mr4u3.ericy.com [208.237.135.127]) by imr1.ericy.com (8.9.3/8.9.3) with ESMTP id KAA22356; Wed, 25 Oct 2000 10:57:29 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr4u3.ericy.com (8.9.3/8.9.3) with ESMTP id KAA11342; Wed, 25 Oct 2000 10:57:26 -0500 (CDT) 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 KAA18298; Wed, 25 Oct 2000 10:57:26 -0500 (CDT) Received: (from eusadam@localhost) by b04a24.exu.ericsson.se (8.9.1/8.9.1) id KAA07949; Wed, 25 Oct 2000 10:57:29 -0500 (CDT) Message-Id: <200010251557.KAA07949@b04a24.exu.ericsson.se> To: sip@lists.bell-labs.com, sip-events@egroups.com 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 Subject: [SIP] New SUBSCRIBE/NOTIFY draft available Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 25 Oct 2000 10:57:28 -0500 (CDT) Content-Transfer-Encoding: 7bit For some reason, I haven't seen the I-D action go by for the SUBSCRIBE/NOTIFY draft yet. Thanks to everyone who gave input while I was putting this together. Further comments are very welcome. If comments warrant and time permits, I may well release a -02 version of this draft in time for the 49th IETF meeting. --------------------------------------------------------------------------- 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 occurred. 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-01.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 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 25 13:22:08 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA12760 for ; Wed, 25 Oct 2000 13:22:07 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 51FF44433E; Wed, 25 Oct 2000 12:22:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by lists.bell-labs.com (Postfix) with ESMTP id BE35D4433B for ; Wed, 25 Oct 2000 12:21:14 -0400 (EDT) Received: from mr4u3.ericy.com (mr4u3.ericy.com [208.237.135.127]) by imr1.ericy.com (8.9.3/8.9.3) with ESMTP id MAA16872; Wed, 25 Oct 2000 12:20:58 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr4u3.ericy.com (8.9.3/8.9.3) with ESMTP id MAA28858; Wed, 25 Oct 2000 12:20:58 -0500 (CDT) 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 MAA23596; Wed, 25 Oct 2000 12:20:57 -0500 (CDT) Received: (from eusadam@localhost) by b04a24.exu.ericsson.se (8.9.1/8.9.1) id MAA08176; Wed, 25 Oct 2000 12:21:01 -0500 (CDT) Message-Id: <200010251721.MAA08176@b04a24.exu.ericsson.se> Subject: Re: [SIP] New SUBSCRIBE/NOTIFY draft available To: Anoop_Tripathi@3com.com Cc: sip@lists.bell-labs.com, sip-events@egroups.com In-Reply-To: <88256983.005C5FB3.00@hqoutbound.ops.3com.com> from "Anoop_Tripathi@3com.com" at Oct 25, 2000 11:47:03 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: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 25 Oct 2000 12:21:00 -0500 (CDT) Content-Transfer-Encoding: 7bit > Was using a header in INVITE/REGISTER requests as a replacement of SUBSCRIBE > request considered? No, this didn't come up as a suggestion so far. The SUBSCRIBE method dates back to February of 1998 (in spirit, at least), and has been incorporated into PINT and the "SIP for Presence" work. The intent of my draft was to provide a framework which allows multiple uses of the SUBSCRIBE and NOTIFY methods in such a way that the different uses didn't get in the way of each other. Using any method other than "SUBSCRIBE" would leave the current drafts somewhat orphaned. > So far I could only see two cases of using SUBSCRIBE. One > during call. In that case we could send the subscribe information in > INVITE/RE-INVITE requests. Second as part of registration. You register to > Proxy, Voice-mail server etc and subscribe to events. So what is the > motivation behind having a separate request? The short answer is: the same reason "INFO" isn't defined as "BYE" with a "Just-Kidding:" header. "SUBSCRIBE" isn't what "INVITE" means, in any remote sense; neither is it what "REGISTER" is intended to mean. It has been pointed out that all methods could be generalised to one method (e.g. replace "BYE" with "INVITE" and a special header indicating that you are inviting the other party to end the current session.) Defining such a system would be quite easy. It would also be patently ridiculous. Since asyncronous event subscription is a distinct action which has no ties to any of the other defined or proposed actions, it seems reasonable to define a new method. > By defining SUBSCRIBE/NOTIFY requests are we trying to achieve the similar > functionality that exists in MEGACO/H.248. Not really. the H.248 event notification, as I understand it, is more appropriate for terminal/endpoint events (e.g. hookflash, digit collection, etc). The SIP event notification has so far been proposed for tasks such as call status, user presence, and message waiting indication. > Is DTMF digit collection a valid usage of this scheme? That's a religious issue. Search your own soul and figure out what's true for you. If you want to read evangelical screeds on both sides of the issue, check the SIP working group mailing list archives. -- 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 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 25 13:51:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA16407 for ; Wed, 25 Oct 2000 13:51:02 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7580F4433E; Wed, 25 Oct 2000 12:51:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by lists.bell-labs.com (Postfix) with ESMTP id EFE6B4433B for ; Wed, 25 Oct 2000 12:50:14 -0400 (EDT) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id 40D334CE5D; Wed, 25 Oct 2000 13:50:09 -0400 (EDT) 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 NAA21412; Wed, 25 Oct 2000 13:50:08 -0400 (EDT) From: William Marshall Received: (from wtm@localhost) by fish-ha.research.att.com (980427.SGI.8.8.8/8.8.5) id NAA61599; Wed, 25 Oct 2000 13:50:08 -0400 (EDT) Message-Id: <200010251750.NAA61599@fish-ha.research.att.com> To: sip@lists.bell-labs.com Cc: gonzalo.camarillo@lmf.ericsson.se, jdrosen@dynamicsoft.com Subject: Re: FW: [SIP] Feedback on manyfolks Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 25 Oct 2000 13:50:08 -0400 (EDT) This sounds like a request for a Requires: header for support of the resource reservation procedures. This was considered and rejected; perhaps it should be re-opened, but I don't think it solves anything. The basic problem of a "Requires:" header is what to do if the response indicates lack of support. In many cases, that means just re-issuing the same request with slight modifications. Such appears to be the case with the manyfolks draft. The current procedures shorten this iteration, by allowing the session to proceed and informing the UAC that resource preconditions will not be honored. The UAC can then cancel the request if it wants, or figure that it is getting the best that it can to that destination. The notion of a UAC *demanding* that the session not proceed was thrown out with the two-phase INVITE that DCS originally proposed. Presumably, if the UAS supports the resource reservation extension but choses not to indicate this in the response messages, it must have a good reason for the behavior and should not be overridden by the UAC. Bill Marshall wtm@research.att.com -----original message----- From: Gonzalo Camarillo To: William Marshall Cc: jdrosen@dynamicsoft.com, sip@lists.bell-labs.com Subject: Re: FW: [SIP] Feedback on manyfolks Date: Tue, 24 Oct 2000 19:52:56 +0300 Hi Bill, There is one scenario you are missing. The UAC wants to send a COMET (UAC->UAS), but it is not interested in receiving a COMET from the UAS. An scenario containing just one COMET from the UAC to the UAS is already in the manyfolks draft, but there, the decision is made by the UAS. The UAS is the one deciding that it whishes to receive the COMET from the UAC. That's why it adds a confirm in the response. In the scenario I am after, the UAC is the one that makes the decision. He wants the UAS to stop the session establishment until there is a COMET from the UAC to the UAS. But he is not interested in the COMET in the other direction. Your suggestion does not solve this problem. Best regards, Gonzalo William Marshall wrote: > > This discussion took me a little while to figure out, because there > was clearly something missing in the manyfolks draft that I wasn't > seeing. > > The current manyfolks draft shows two examples, one where a confirmation > is requested by the UAS from the UAC, and one where two confirmations > are requested, first by the UAC from the UAS, then by the UAS from the UAC. > > However, (and the part I missed several times re-re-re-reading the draft), > the wording of the spec also allows the UAC to request a confirmation from > the UAS without the UAS requesting a confirmation from the UAC. This > seems pointless. > > |----(1)INVITE------->| > |<---(2)183-----------| > |----(3)PRACK-------->| > |<---(4)200-----------| > |<---(5)COMET---------| > |----(6)200---------->| > |<---(7)180-----------| > > If message (1)INVITE includes a request for a confirmation, i.e. (5)COMET, > but message (2)183 does not also request a confirmation, then there is > nothing the UAC can do upon receipt of the (5)COMET. The UAS is already > doing the alerting and the (7)180 is probably already on its way. The fact > that (7)180 is sent indicates the resource preconditions were met by UAS, > because otherwise it would have responded with a 580-precondition-failure > response. So why even bother with (5)COMET? > > My original intention in writing the procedures for the two-way COMET > exchange was that it be triggered by the UAC requesting a confirmation. > The UAS, on receipt of a SDP containing a precondition line with a > confirmation request, MUST include a precondition line in its SDP with > a confirmation request. This text doesn't appear, and would solve > the problem presented by third party call control. > > Did anyone see a case where the one-way confirmation shown in the > diagram above was actually useful and should be allowed? Otherwise, > I think we should add the requirement on UAS behavior. > > If the response to the INVITE(with confirmation requested) is a 180, or > a 183 without a precondition line, it indicates the UAS doesn't support > the resource extension. A 183 response with a precondition line that > doesn't include a confirmation would also, in this case, indicate lack > support of the UAS (or lack of sanity). > > Bill Marshall > wtm@research.att.com > > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > Sent: Thursday, October 12, 2000 1:38 AM > To: Jonathan Rosenberg > Cc: 'sip' > Subject: Re: [SIP] Feedback on manyfolks > > Hi, > > I agree. This is getting pretty complex. > > Anyway, for this specific matter we have three choices: > > 1) COMET is always mandatory in both directions. It does not matter if > the preconditions are mandatory or optional. > > 2) COMET is mandatory just when the preconditions are mandatory. > > 3) COMET is just sent when requested by any of the parties. This would > be the mechanism used so far (with the extension defined in > draft-camarillo-manyfolks-confirm-00.txt) > > Approach number 1 is the simplest. After doing whatever in order to > fulfil the preconditions a COMET is sent. > > Number 2 is also pretty simple. If the preconditions were mandatory, the > session is stopped until the COMET is sent. If the preconditions were > optional the session establishment goes on, so no COMET is sent. > > The gain of approach number 3 is that it saves some messages. However, > as you pointed out, they are not a lot. In the most common situation it > would save 2 messages (1 RTT). This is when A calls B in a two-party > session where there is just one COMET from A towards B. The COMET from B > to A is not normally needed since B just begins alerting the user once > the preconditions are met. > > So, we have a little more complexity for a little gain. > > My only concern is the amonut of signalling messages that we already > have for establishing a session using preconditions (PRACKs, COMETs). A > RTT for a workstation in an ethernet is not a big deal, but for a > terminal using a cellular access begins to be more important. > > Anyway, I do not have a religious position here, so any of the 3 > solutions is alright for me. Let's pick one and go on resolving > different issues. > > Opinions? > > Regards, > > Gonzalo > > Jonathan Rosenberg wrote: > > > > Its just thats its more options, more complexities ontop of a thing which > is > > growing more and more complex. We need to remove options, not add them. I > > don't see what they need is for the negotiation. We need to justify the > > existence of it, not the elimination of it. > > > > -Jonathan R. > > > > --- > > Jonathan D. Rosenberg 72 Eagle Rock Ave. > > Chief Scientist First Floor > > dynamicsoft East Hanover, NJ 07936 > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > > http://www.dynamicsoft.com > > > > > -----Original Message----- > > > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > > Sent: Tuesday, October 10, 2000 10:46 AM > > > To: Jonathan Rosenberg > > > Cc: 'sip' > > > Subject: Re: [SIP] Feedback on manyfolks > > > > > > > > > Hi, > > > > > > Certainly we are not talking about tons of messages. However, in this > > > case I would rather let the confim be negotiated. The negotiation is > > > rather simple. > > > > > > The UAC can request: > > > 1) No COMET > > > 2) one COMET UAC->UAS > > > 3) one COMET UAC- > > 4) two COMETs > > > > > > The UAS should accept what the UAC requests, and possibly request more > > > (e.g. two COMETs when the UAC just requested one). > > > > > > I believe this is not a complicated mechanism. It is just a > > > deterministic two-way handshake. > > > > > > Best regards, > > > > > > Gonzalo > > > > > > > > > > > > Jonathan Rosenberg wrote: > > > > > > > > This seems reasonable to me, and needed, as Gonzalo points out. > > > > > > > > My only issue is whether all this stuff should be optional > > > at all. Wouldn't > > > > it be easier if both sides always sent COMET, period? All > > > this negotiation > > > > stuff is a pain. We're not talking tons of messages here. > > > Can't we keep it > > > > simple? > > > > > > > > -Jonathan R. > > > > > > > > --- > > > > Jonathan D. Rosenberg 72 Eagle Rock Ave. > > > > Chief Scientist First Floor > > > > dynamicsoft East Hanover, NJ 07936 > > > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > > > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > > > > http://www.dynamicsoft.com > > > > > > > > > -----Original Message----- > > > > > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > > > > Sent: Monday, October 09, 2000 2:33 AM > > > > > To: sip > > > > > Subject: [SIP] Feedback on manyfolks > > > > > > > > > > > > > > > Hi, > > > > > > > > > > Here you have a new I-D that contains feedback on the > > > manyfolks draft. > > > > > > > > > > http://search.ietf.org/internet-drafts/draft-camarillo-manyfol > > > > > ks-confirm-00.txt > > > > > > > > > > " > > > > > Abstract > > > > > > > > > > This document describes certain functionality that is > > > > > missing in the > > > > > current "Integration of Resource Management and SIP" > > > [1] (a.k.a. > > > > > manyfolks draft). An extension to add this functionality is > > > > > outlined. > > > > > > > > > > This functionality is needed in general to provide richer > > > > > signalling > > > > > capabilities and can be employed in several scenarios. > > > This draft > > > > > describes its use in third party call control applications. > > > > > > > > > > If this extension is accepted it is foreseen that this > > > draft would > > > > > be merged with [1]. > > > > > " > > > > > > > > > > Best regards, > > > > > > > > > > Gonzalo > > > > > -- > > > > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > > > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > > > > Telecom R&D Fax : +358 9 299 30 52 > > > > > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > > > > > Finland http://www.hut.fi/~gonzalo > > > > > > > > > > _______________________________________________ > > > > > SIP mailing list > > > > > SIP@lists.bell-labs.com > > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > > > > -- > > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > > Telecom R&D Fax : +358 9 299 30 52 > > > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > > > Finland http://www.hut.fi/~gonzalo > > > > > > _______________________________________________ > > > SIP mailing list > > > SIP@lists.bell-labs.com > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > -- > Gonzalo Camarillo Phone : +358 9 299 33 71 > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > Telecom R&D Fax : +358 9 299 30 52 > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > Finland http://www.hut.fi/~gonzalo > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 25 14:08:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA18421 for ; Wed, 25 Oct 2000 14:08:03 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 94B5D4434B; Wed, 25 Oct 2000 13:08:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by lists.bell-labs.com (Postfix) with SMTP id 3A57544337 for ; Wed, 25 Oct 2000 13:07:52 -0400 (EDT) Received: from 157.54.9.104 by mail2.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 25 Oct 2000 11:09:02 -0700 (Pacific Daylight Time) Received: by INET-IMC-02 with Internet Mail Service (5.5.2651.58) id ; Wed, 25 Oct 2000 11:09:02 -0700 Message-ID: From: Christian Huitema To: "'Adam B. Roach'" , sip@lists.bell-labs.com, sip-events@egroups.com Subject: RE: [SIP] New SUBSCRIBE/NOTIFY draft available X-Mailer: Internet Mail Service (5.5.2651.58) Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 25 Oct 2000 11:07:30 -0700 Adam, What is the relation between this draft and "draft-rosenberg-impp-presence-00.txt" ? I think that we need to work further, and have a single solution that encompasses PINT, IMPP and "events." In particular, we will need to align on the following points: 1) the IMPP draft defines that "SUBSCRIBE" creates a subscription session, identified by its own Call-Id. The session expires when the life time of the subscribe expires before being renewed by another subscribe for the same call-id, or if the subscriber sends a subscribe with a null lifetime. 2) In IMPP, the object to which you subscribe is identified by the request-URI. In PINT, we want to know about the handling of a call. If we subscribe to a call, we have to explicit the syntax of the URI that defines "the call." 3) In the IMPP discussion, we agreed that we should be able to have some amount of security about transport boundaries, for example when you translate a SIP Notify into an IMXP Notify. This implies that the meat of the notification should be carried in the payload, which can be passed unchanged accross system boundaries, rather than in the headers, which will probably be lost. Use of a common syntax is necessary if you want to allow encryption or digital signature of the payload. The agreement is to define that syntax in XML. This implies that the events should be reported as XML tokens in the payload, not as SIP Headers. It is in fact a sound architecture: use the header for "transport control", use the payload for "information." (The basic format of the payload should come from the IMPP working group; we have all possibilities to extend it.) 4) In the IMMP discussion, we also agreed that the publisher/presentity should be able to terminate a subscription at any time, and should be able to report this event in a Notify. In your draft, you mention a possible linkage between the duration of the subscription session and the duration of a call. I think that the Notify solution presented above (4) solves that problem without requiring any additional linkage between the call and the subscription session. Note that we must be clear as to whether it is OK or not to send a SUBSCRIBE on a session that started with an INVITE. I would rather not; if that is OK, however, we must clearly specify the expected behavior. I understand the need to decouple the SIP syntax from the vagaries of the IMPP working group. But I think that it would be beneficial to merge your draft with the sip-impp draft, or at least with the protocol description part of that draft. -- Christian Huitema > -----Original Message----- > From: Adam B. Roach [mailto:Adam.Roach@Ericsson.com] > Sent: Wednesday, October 25, 2000 8:57 AM > To: sip@lists.bell-labs.com; sip-events@egroups.com > Subject: [SIP] New SUBSCRIBE/NOTIFY draft available > > > For some reason, I haven't seen the I-D action go by for > the SUBSCRIBE/NOTIFY draft yet. Thanks to everyone who gave > input while I was putting this together. Further comments are > very welcome. If comments warrant and time permits, I may well > release a -02 version of this draft in time for the 49th > IETF meeting. > > -------------------------------------------------------------- > ------------- > 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 occurred. > > Concrete uses of the mechanism described in this document may be > standardized in the future. > -------------------------------------------------------------- > ------------- > > http://search.ietf.org/internet-drafts/draft-roach-sip-subscri be-notify-01.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 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 25 14:55:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA25555 for ; Wed, 25 Oct 2000 14:55:04 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5F58244337; Wed, 25 Oct 2000 13:55:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id D4AAE44336 for ; Wed, 25 Oct 2000 13:54:48 -0400 (EDT) Received: from athletics ([63.110.3.226]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with SMTP id OAA29541; Wed, 25 Oct 2000 14:56:50 -0400 (EDT) From: "Steve Donovan" To: "SIP Forum Discussion" , "SIP" Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: [SIP] Virtual SIP Bake-Off (VSBO) Mailing List Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 25 Oct 2000 14:52:29 -0400 Content-Transfer-Encoding: 7bit The mailing list for the SIP Forum Virtual SIP Bake-Off has been set up. The following is the contact information. Post message: vsbo@egroups.com Subscribe: vsbo-subscribe@egroups.com Unsubscribe: vsbo-unsubscribe@egroups.com List owner: vsbo-owner@egroups.com URL to this page: http://www.egroups.com/group/vsbo For the time being, discussions relating to the VSBO should occur on both the SIP Forum discussion list and the VSBO list. We will transition to the VSBO list once everyone has had a chance to sign up. For more information on the VSBO, see the following: http://www.sipforum.org/whitepapers/Bake-Off.pdf Regards, Steve _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 25 15:42:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA01780 for ; Wed, 25 Oct 2000 15:42:03 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id CA73144337; Wed, 25 Oct 2000 14:42:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lists.bell-labs.com (Postfix) with ESMTP id 1D61044336 for ; Wed, 25 Oct 2000 14:41:31 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id e9PJfKZ14543; Wed, 25 Oct 2000 21:41:20 +0200 (MEST) 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 WAA05931; Wed, 25 Oct 2000 22:41:19 +0300 (EET DST) Received: from lmf.ericsson.se (E0080C77A56E4.lmf.ericsson.se [131.160.105.66]) by greymse1.lmf.ericsson.se (8.9.3 (PHNE_18979)/8.8.6) with ESMTP id WAA23356; Wed, 25 Oct 2000 22:41:17 +0300 (EETDST) Message-ID: <39F7374A.A9322721@lmf.ericsson.se> From: Gonzalo Camarillo Organization: Ericsson X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: William Marshall Cc: sip@lists.bell-labs.com, jdrosen@dynamicsoft.com Subject: Re: FW: [SIP] Feedback on manyfolks References: <200010251750.NAA61599@fish-ha.research.att.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 25 Oct 2000 22:40:58 +0300 Content-Transfer-Encoding: 7bit Hi, William Marshall wrote: > > This sounds like a request for a Requires: header for support of the > resource reservation procedures. This was considered and rejected; > perhaps it should be re-opened, but I don't think it solves anything. > > The basic problem of a "Requires:" header is what to do if the > response indicates lack of support. In many cases, that means > just re-issuing the same request with slight modifications. Such > appears to be the case with the manyfolks draft. > > The current procedures shorten this iteration, by allowing the > session to proceed and informing the UAC that resource preconditions > will not be honored. The UAC can then cancel the request if it wants, > or figure that it is getting the best that it can to that destination. > > The notion of a UAC *demanding* that the session not proceed was > thrown out with the two-phase INVITE that DCS originally proposed. As it is shown in the draft this feature is useful in some cases. Among many others, the third party call control draft needs this in order to work. > > Presumably, if the UAS supports the resource reservation extension but > choses not to indicate this in the response messages, it must have a > good reason for the behavior and should not be overridden by the UAC. You are saying that the UAS has a good reason for not adding a confirm tag to the 183 response?? I think you are mixing here two different issues. One is when the UAS do not understand the a=QoS: line. In this situation we cannot really do anything (we can just CANCEL the INVITE). The other issue is the one I am after. Both, UAC and UAS understand the a=QoS: line. So, considering that both understand it, the UAC wants the UAS to wait until the COMET is sent. And, as I said before, I can think of many cases where this is needed. Best regards, Gonzalo > > Bill Marshall > wtm@research.att.com > > -----original message----- > From: Gonzalo Camarillo > To: William Marshall > Cc: jdrosen@dynamicsoft.com, sip@lists.bell-labs.com > Subject: Re: FW: [SIP] Feedback on manyfolks > Date: Tue, 24 Oct 2000 19:52:56 +0300 > > Hi Bill, > > There is one scenario you are missing. > > The UAC wants to send a COMET (UAC->UAS), but it is not interested in > receiving a COMET from the UAS. > > An scenario containing just one COMET from the UAC to the UAS is already > in the manyfolks draft, but there, the decision is made by the UAS. The > UAS is the one deciding that it whishes to receive the COMET from the > UAC. That's why it adds a confirm in the response. > > In the scenario I am after, the UAC is the one that makes the decision. > He wants the UAS to stop the session establishment until there is a > COMET from the UAC to the UAS. But he is not interested in the COMET in > the other direction. > > Your suggestion does not solve this problem. > > Best regards, > > Gonzalo > > William Marshall wrote: > > > > This discussion took me a little while to figure out, because there > > was clearly something missing in the manyfolks draft that I wasn't > > seeing. > > > > The current manyfolks draft shows two examples, one where a confirmation > > is requested by the UAS from the UAC, and one where two confirmations > > are requested, first by the UAC from the UAS, then by the UAS from the UAC. > > > > However, (and the part I missed several times re-re-re-reading the draft), > > the wording of the spec also allows the UAC to request a confirmation from > > the UAS without the UAS requesting a confirmation from the UAC. This > > seems pointless. > > > > |----(1)INVITE------->| > > |<---(2)183-----------| > > |----(3)PRACK-------->| > > |<---(4)200-----------| > > |<---(5)COMET---------| > > |----(6)200---------->| > > |<---(7)180-----------| > > > > If message (1)INVITE includes a request for a confirmation, i.e. (5)COMET, > > but message (2)183 does not also request a confirmation, then there is > > nothing the UAC can do upon receipt of the (5)COMET. The UAS is already > > doing the alerting and the (7)180 is probably already on its way. The fact > > that (7)180 is sent indicates the resource preconditions were met by UAS, > > because otherwise it would have responded with a 580-precondition-failure > > response. So why even bother with (5)COMET? > > > > My original intention in writing the procedures for the two-way COMET > > exchange was that it be triggered by the UAC requesting a confirmation. > > The UAS, on receipt of a SDP containing a precondition line with a > > confirmation request, MUST include a precondition line in its SDP with > > a confirmation request. This text doesn't appear, and would solve > > the problem presented by third party call control. > > > > Did anyone see a case where the one-way confirmation shown in the > > diagram above was actually useful and should be allowed? Otherwise, > > I think we should add the requirement on UAS behavior. > > > > If the response to the INVITE(with confirmation requested) is a 180, or > > a 183 without a precondition line, it indicates the UAS doesn't support > > the resource extension. A 183 response with a precondition line that > > doesn't include a confirmation would also, in this case, indicate lack > > support of the UAS (or lack of sanity). > > > > Bill Marshall > > wtm@research.att.com > > > > -----Original Message----- > > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > Sent: Thursday, October 12, 2000 1:38 AM > > To: Jonathan Rosenberg > > Cc: 'sip' > > Subject: Re: [SIP] Feedback on manyfolks > > > > Hi, > > > > I agree. This is getting pretty complex. > > > > Anyway, for this specific matter we have three choices: > > > > 1) COMET is always mandatory in both directions. It does not matter if > > the preconditions are mandatory or optional. > > > > 2) COMET is mandatory just when the preconditions are mandatory. > > > > 3) COMET is just sent when requested by any of the parties. This would > > be the mechanism used so far (with the extension defined in > > draft-camarillo-manyfolks-confirm-00.txt) > > > > Approach number 1 is the simplest. After doing whatever in order to > > fulfil the preconditions a COMET is sent. > > > > Number 2 is also pretty simple. If the preconditions were mandatory, the > > session is stopped until the COMET is sent. If the preconditions were > > optional the session establishment goes on, so no COMET is sent. > > > > The gain of approach number 3 is that it saves some messages. However, > > as you pointed out, they are not a lot. In the most common situation it > > would save 2 messages (1 RTT). This is when A calls B in a two-party > > session where there is just one COMET from A towards B. The COMET from B > > to A is not normally needed since B just begins alerting the user once > > the preconditions are met. > > > > So, we have a little more complexity for a little gain. > > > > My only concern is the amonut of signalling messages that we already > > have for establishing a session using preconditions (PRACKs, COMETs). A > > RTT for a workstation in an ethernet is not a big deal, but for a > > terminal using a cellular access begins to be more important. > > > > Anyway, I do not have a religious position here, so any of the 3 > > solutions is alright for me. Let's pick one and go on resolving > > different issues. > > > > Opinions? > > > > Regards, > > > > Gonzalo > > > > Jonathan Rosenberg wrote: > > > > > > Its just thats its more options, more complexities ontop of a thing which > > is > > > growing more and more complex. We need to remove options, not add them. I > > > don't see what they need is for the negotiation. We need to justify the > > > existence of it, not the elimination of it. > > > > > > -Jonathan R. > > > > > > --- > > > Jonathan D. Rosenberg 72 Eagle Rock Ave. > > > Chief Scientist First Floor > > > dynamicsoft East Hanover, NJ 07936 > > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > > > http://www.dynamicsoft.com > > > > > > > -----Original Message----- > > > > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > > > Sent: Tuesday, October 10, 2000 10:46 AM > > > > To: Jonathan Rosenberg > > > > Cc: 'sip' > > > > Subject: Re: [SIP] Feedback on manyfolks > > > > > > > > > > > > Hi, > > > > > > > > Certainly we are not talking about tons of messages. However, in this > > > > case I would rather let the confim be negotiated. The negotiation is > > > > rather simple. > > > > > > > > The UAC can request: > > > > 1) No COMET > > > > 2) one COMET UAC->UAS > > > > 3) one COMET UAC- > > > 4) two COMETs > > > > > > > > The UAS should accept what the UAC requests, and possibly request more > > > > (e.g. two COMETs when the UAC just requested one). > > > > > > > > I believe this is not a complicated mechanism. It is just a > > > > deterministic two-way handshake. > > > > > > > > Best regards, > > > > > > > > Gonzalo > > > > > > > > > > > > > > > > Jonathan Rosenberg wrote: > > > > > > > > > > This seems reasonable to me, and needed, as Gonzalo points out. > > > > > > > > > > My only issue is whether all this stuff should be optional > > > > at all. Wouldn't > > > > > it be easier if both sides always sent COMET, period? All > > > > this negotiation > > > > > stuff is a pain. We're not talking tons of messages here. > > > > Can't we keep it > > > > > simple? > > > > > > > > > > -Jonathan R. > > > > > > > > > > --- > > > > > Jonathan D. Rosenberg 72 Eagle Rock Ave. > > > > > Chief Scientist First Floor > > > > > dynamicsoft East Hanover, NJ 07936 > > > > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > > > > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > > > > > http://www.dynamicsoft.com > > > > > > > > > > > -----Original Message----- > > > > > > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > > > > > Sent: Monday, October 09, 2000 2:33 AM > > > > > > To: sip > > > > > > Subject: [SIP] Feedback on manyfolks > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > Here you have a new I-D that contains feedback on the > > > > manyfolks draft. > > > > > > > > > > > > http://search.ietf.org/internet-drafts/draft-camarillo-manyfol > > > > > > ks-confirm-00.txt > > > > > > > > > > > > " > > > > > > Abstract > > > > > > > > > > > > This document describes certain functionality that is > > > > > > missing in the > > > > > > current "Integration of Resource Management and SIP" > > > > [1] (a.k.a. > > > > > > manyfolks draft). An extension to add this functionality is > > > > > > outlined. > > > > > > > > > > > > This functionality is needed in general to provide richer > > > > > > signalling > > > > > > capabilities and can be employed in several scenarios. > > > > This draft > > > > > > describes its use in third party call control applications. > > > > > > > > > > > > If this extension is accepted it is foreseen that this > > > > draft would > > > > > > be merged with [1]. > > > > > > " > > > > > > > > > > > > Best regards, > > > > > > > > > > > > Gonzalo > > > > > > -- > > > > > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > > > > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > > > > > Telecom R&D Fax : +358 9 299 30 52 > > > > > > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > > > > > > Finland http://www.hut.fi/~gonzalo > > > > > > > > > > > > _______________________________________________ > > > > > > SIP mailing list > > > > > > SIP@lists.bell-labs.com > > > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > > > > > > > -- > > > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > > > Telecom R&D Fax : +358 9 299 30 52 > > > > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > > > > Finland http://www.hut.fi/~gonzalo > > > > > > > > _______________________________________________ > > > > SIP mailing list > > > > SIP@lists.bell-labs.com > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > -- > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > Telecom R&D Fax : +358 9 299 30 52 > > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > > Finland http://www.hut.fi/~gonzalo > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip -- 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 31 18 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 25 16:26:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA06821 for ; Wed, 25 Oct 2000 16:26:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9ECDA44337; Wed, 25 Oct 2000 15:26:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by lists.bell-labs.com (Postfix) with ESMTP id 0ABBD44336 for ; Wed, 25 Oct 2000 15:25:13 -0400 (EDT) Received: from mr5.exu.ericsson.se (mr5u3.ericy.com [208.237.135.124]) by imr1.ericy.com (8.9.3/8.9.3) with ESMTP id PAA13225; Wed, 25 Oct 2000 15:24:34 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr5.exu.ericsson.se (8.10.2/8.10.2) with ESMTP id e9PKMlk16222; Wed, 25 Oct 2000 15:22:47 -0500 (CDT) 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 PAA05214; Wed, 25 Oct 2000 15:24:33 -0500 (CDT) Received: (from eusadam@localhost) by b04a24.exu.ericsson.se (8.9.1/8.9.1) id PAA10157; Wed, 25 Oct 2000 15:24:37 -0500 (CDT) Message-Id: <200010252024.PAA10157@b04a24.exu.ericsson.se> Subject: Re: [SIP] New SUBSCRIBE/NOTIFY draft available To: huitema@microsoft.com (Christian Huitema) Cc: sip@lists.bell-labs.com, sip-events@egroups.com In-Reply-To: from "Christian Huitema" at Oct 25, 2000 11:07:30 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: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 25 Oct 2000 15:24:37 -0500 (CDT) Content-Transfer-Encoding: 7bit Christian Huitema writes: >What is the relation between this draft and >"draft-rosenberg-impp-presence-00.txt" ? My intention was to synchronise the drafts as closely as possible. To my knowledge, the events draft allows for all of the behaviours described in the presence draft (with one minor exception; see below). >I think that we need to work >further, and have a single solution that encompasses PINT, IMPP and >"events." I agree 100%. My entire goal in composing this draft is to have a framework which allows PINT and IMPP to co-exist with a whole slew of other extensions based on asyncronous notification. If we have no framework, each extension will just cobble on their own semantics, probably conflicting with several others. >1) the IMPP draft defines that "SUBSCRIBE" creates a subscription session, >identified by its own Call-Id. The session expires when the life time of the >subscribe expires before being renewed by another subscribe for the same >call-id, or if the subscriber sends a subscribe with a null lifetime. This is what I describe as "third-party" subscriptions. The behavior is, to my knowledge, identical between the presence and events draft. If I have left something out in this regards, please let me know. (From section 5.1.1:) "Third-party SUBSCRIBE requests will not correlate to any previously-existing call leg in the server. The Call-ID of resource-related requests will be unique to the SUBSCRIBE and any subsequent NOTIFY requests." >2) In IMPP, the object to which you subscribe is identified by the >request-URI. In PINT, we want to know about the handling of a call. If we >subscribe to a call, we have to explicit the syntax of the URI that defines >"the call." Once again, I beleive that the behavior in the events draft is lined up with that in the presence draft (section 5.1.3): "The Request URI of a SUBSCRIBE request, most importantly, contains enough information to route the request to the appropriate entity. It also contains enough information to identify the resource for which event notification is desired, but not necessarily enough information to uniquely identify the nature of the event (e.g. "sip:adam.roach@ericsson.com" would be an appropriate URI to subscribe to for my presence state; it would also be an appropriate URI to subscribe to the state of my voice mailbox)." If you have any ideas about how this mechanism can be refined to align more closely with PINT, I'm open to suggestions. Note that, from where I stand, the description in my draft is not fundimentally at odds with PINT. >3) In the IMPP discussion, we agreed that we should be able to have some >amount of security about transport boundaries, for example when you >translate a SIP Notify into an IMXP Notify. This implies that the meat of >the notification should be carried in the payload, which can be passed >unchanged accross system boundaries, rather than in the headers, which will >probably be lost. Use of a common syntax is necessary if you want to allow >encryption or digital signature of the payload. The agreement is to define >that syntax in XML. This implies that the events should be reported as XML >tokens in the payload, not as SIP Headers. It is in fact a sound >architecture: use the header for "transport control", use the payload for >"information." (The basic format of the payload should come from the IMPP >working group; we have all possibilities to extend it.) The draft I just published accomodates this model quite well. As in the presence draft, the URI indicates the object to which a subscription is being requested. I suspect that, for presence, an XML-based presence syntax (or one that can be freely translated to and from XML) will be carried in the body. The only headers added by the events draft are "Event:" and "Allow-Event:". "Event:" is used solely as an opaque token to differentiate beween different event extensions (e.g. PINT and presence). You can think of it as very roughly analogous to the "Required:" header for SIP extensions. Similarly, "Allow-Events" can be thought of as similar to "Supported:". >4) In the IMMP discussion, we also agreed that the publisher/presentity >should be able to terminate a subscription at any time, and should be able >to report this event in a Notify. Thank you; this is apparently a feature I overlooked. I will add this in an upcoming version of the draft. >In your draft, you mention a possible linkage between the duration of the >subscription session and the duration of a call. I think that the Notify >solution presented above (4) solves that problem without requiring any >additional linkage between the call and the subscription session. This linkage only applies for call-related subscriptions; this is precicely the kind of subscription that presence does not use. As I ask in the draft: is there any sensible reason for keeping subscription state which relates exclusively to a call which is over? After a call is over, nothing about it will change. There is no relevant state. The only thing possible that I can think of is synthetic events like "the call has been over for five minutes now." Is that useful? Is it even sane? >Note that >we must be clear as to whether it is OK or not to send a SUBSCRIBE on a >session that started with an INVITE. That was my intention when I drafted the following paragraph: "Call-member SUBSCRIBE requests will be correlated in the same way that any other call-related request is (e.g. BYE) using To, From, and Call-ID; these subscriptions will generally be used to request information about the specific call." I'll add some text indicating more explicitly that I'm referring to a session which has been initiated by an INVITE. Let me know if that doesn't address your point. >I would rather not; if that is OK, >however, we must clearly specify the expected behavior. It's not a particularly special case; refreshes occur as normal (using the same call-leg as the original SUBSCRIBE), and notifications occur as normal (once again, using the same call-leg as the original SUBSCRIBE). The only difference, as currently defined, is that the subscriptions automatically vanish at the end of a call -- because it doesn't seem to make sense not to. What does this gain you? It's a very simple way for call-leg related event extensions to use an existing mechanism to say "I want events relating to *this* call leg" without defining an additional correlation mechanism. The alternative is for these types of extensions to go out of their way to define a leg correlation mechanism for the body of their message: SUBSCRIBE sip:eusadam@ws148.ericsson.com SIP/2.0 To: ;tag=abcd From: ;tag=ef01 Call-ID: 1234@a1234.microsoft.com CSeq: 2874 SUBSCRIBE Event: foo Content-Type: text/fooml Content-Length: 205 ... >I understand the need to decouple the SIP syntax from the vagaries of the >IMPP working group. But I think that it would be beneficial to merge your >draft with the sip-impp draft, or at least with the protocol description >part of that draft. My hope is that, once the events draft is complete, the presence draft will be somewhat thinner, and have the luxury of concentrating on presence instead of event notification. If you feel that there are any generally applicable features included in the presence draft which I have failed to clearly incorporate in my draft, please point them out. Thanks for your comments. -- 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 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Oct 25 18:27:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA25524 for ; Wed, 25 Oct 2000 18:27:02 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 23EDB44337; Wed, 25 Oct 2000 17:27:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by lists.bell-labs.com (Postfix) with ESMTP id A588144336 for ; Wed, 25 Oct 2000 17:26:46 -0400 (EDT) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id BFC554CE1A; Wed, 25 Oct 2000 18:26:37 -0400 (EDT) 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 SAA01737; Wed, 25 Oct 2000 18:26:34 -0400 (EDT) From: William Marshall Received: (from wtm@localhost) by fish-ha.research.att.com (980427.SGI.8.8.8/8.8.5) id SAA87331; Wed, 25 Oct 2000 18:26:33 -0400 (EDT) Message-Id: <200010252226.SAA87331@fish-ha.research.att.com> To: gonzalo.camarillo@lmf.ericsson.se Cc: jdrosen@dynamicsoft.com, sip@lists.bell-labs.com Subject: Re: FW: [SIP] Feedback on manyfolks Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 25 Oct 2000 18:26:33 -0400 (EDT) Gonzalo wrote: > The other issue is the one I am after. Both, UAC and UAS understand the > a=QoS: line. So, considering that both understand it, the UAC wants the > UAS to wait until the COMET is sent. And, as I said before, I can think > of many cases where this is needed. In enumerating the cases, I see the confirmation-tag choices as follows: UAC sends UAS sends result 1. confirm 1 COMET, UAS->UAC, useless 2. confirm confirm 2 COMETs, UAS->UAC, then UAC->UAS 3. 0 COMETs 4. confirm 1 COMET, UAC->UAS I've heard no argument to my proposal of dropping case (1). Third party call control wants to force choice (4), without going as far as choice (2), thereby saving one round-trip time and one UAS->UAC message. If we add a new confirmation-tag value that can be sent by the UAC, "wait", the revised enumeration of cases is: UAC sends UAS sends result confirm confirm 2 COMETs, UAS->UAC, then UAC->UAS wait confirm 1 COMET, UAC->UAS 0 COMETs confirm 1 COMET, UAC->UAS The semantics of this at the UAS are kept very simple: if either a "confirm" or a "wait" appears as a confirmation-tag in the SDP in the INVITE, then a "confirm" MUST be sent in the SDP in the 183 response. All other procedures unchanged. I believe this covers the third-party call control case. Agree? Bill Marshall wtm@research.att.com p.s. There is only one case not covered, that of the UAC sending but the UAS wanting a double-COMET exchange. However, the single COMET (which UAS can force to happen) gives the UAS all the resource results from the UAC, and the UAS can then decide whether to proceed with a 180-Ringing or to return a 580-failure. No loss of functionality here, and no reason to extend the table to allow the UAS to force a double-COMET. -----original message----- Date: Wed, 25 Oct 2000 22:40:58 +0300 From: Gonzalo Camarillo To: William Marshall Cc: sip@lists.bell-labs.com, jdrosen@dynamicsoft.com Subject: Re: FW: [SIP] Feedback on manyfolks Hi, William Marshall wrote: > > This sounds like a request for a Requires: header for support of the > resource reservation procedures. This was considered and rejected; > perhaps it should be re-opened, but I don't think it solves anything. > > The basic problem of a "Requires:" header is what to do if the > response indicates lack of support. In many cases, that means > just re-issuing the same request with slight modifications. Such > appears to be the case with the manyfolks draft. > > The current procedures shorten this iteration, by allowing the > session to proceed and informing the UAC that resource preconditions > will not be honored. The UAC can then cancel the request if it wants, > or figure that it is getting the best that it can to that destination. > > The notion of a UAC *demanding* that the session not proceed was > thrown out with the two-phase INVITE that DCS originally proposed. As it is shown in the draft this feature is useful in some cases. Among many others, the third party call control draft needs this in order to work. > > Presumably, if the UAS supports the resource reservation extension but > choses not to indicate this in the response messages, it must have a > good reason for the behavior and should not be overridden by the UAC. You are saying that the UAS has a good reason for not adding a confirm tag to the 183 response?? I think you are mixing here two different issues. One is when the UAS do not understand the a=QoS: line. In this situation we cannot really do anything (we can just CANCEL the INVITE). The other issue is the one I am after. Both, UAC and UAS understand the a=QoS: line. So, considering that both understand it, the UAC wants the UAS to wait until the COMET is sent. And, as I said before, I can think of many cases where this is needed. Best regards, Gonzalo > > Bill Marshall > wtm@research.att.com > > -----original message----- > From: Gonzalo Camarillo > To: William Marshall > Cc: jdrosen@dynamicsoft.com, sip@lists.bell-labs.com > Subject: Re: FW: [SIP] Feedback on manyfolks > Date: Tue, 24 Oct 2000 19:52:56 +0300 > > Hi Bill, > > There is one scenario you are missing. > > The UAC wants to send a COMET (UAC->UAS), but it is not interested in > receiving a COMET from the UAS. > > An scenario containing just one COMET from the UAC to the UAS is already > in the manyfolks draft, but there, the decision is made by the UAS. The > UAS is the one deciding that it whishes to receive the COMET from the > UAC. That's why it adds a confirm in the response. > > In the scenario I am after, the UAC is the one that makes the decision. > He wants the UAS to stop the session establishment until there is a > COMET from the UAC to the UAS. But he is not interested in the COMET in > the other direction. > > Your suggestion does not solve this problem. > > Best regards, > > Gonzalo > > William Marshall wrote: > > > > This discussion took me a little while to figure out, because there > > was clearly something missing in the manyfolks draft that I wasn't > > seeing. > > > > The current manyfolks draft shows two examples, one where a confirmation > > is requested by the UAS from the UAC, and one where two confirmations > > are requested, first by the UAC from the UAS, then by the UAS from the UAC. > > > > However, (and the part I missed several times re-re-re-reading the draft), > > the wording of the spec also allows the UAC to request a confirmation from > > the UAS without the UAS requesting a confirmation from the UAC. This > > seems pointless. > > > > |----(1)INVITE------->| > > |<---(2)183-----------| > > |----(3)PRACK-------->| > > |<---(4)200-----------| > > |<---(5)COMET---------| > > |----(6)200---------->| > > |<---(7)180-----------| > > > > If message (1)INVITE includes a request for a confirmation, i.e. (5)COMET, > > but message (2)183 does not also request a confirmation, then there is > > nothing the UAC can do upon receipt of the (5)COMET. The UAS is already > > doing the alerting and the (7)180 is probably already on its way. The fact > > that (7)180 is sent indicates the resource preconditions were met by UAS, > > because otherwise it would have responded with a 580-precondition-failure > > response. So why even bother with (5)COMET? > > > > My original intention in writing the procedures for the two-way COMET > > exchange was that it be triggered by the UAC requesting a confirmation. > > The UAS, on receipt of a SDP containing a precondition line with a > > confirmation request, MUST include a precondition line in its SDP with > > a confirmation request. This text doesn't appear, and would solve > > the problem presented by third party call control. > > > > Did anyone see a case where the one-way confirmation shown in the > > diagram above was actually useful and should be allowed? Otherwise, > > I think we should add the requirement on UAS behavior. > > > > If the response to the INVITE(with confirmation requested) is a 180, or > > a 183 without a precondition line, it indicates the UAS doesn't support > > the resource extension. A 183 response with a precondition line that > > doesn't include a confirmation would also, in this case, indicate lack > > support of the UAS (or lack of sanity). > > > > Bill Marshall > > wtm@research.att.com > > > > -----Original Message----- > > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > Sent: Thursday, October 12, 2000 1:38 AM > > To: Jonathan Rosenberg > > Cc: 'sip' > > Subject: Re: [SIP] Feedback on manyfolks > > > > Hi, > > > > I agree. This is getting pretty complex. > > > > Anyway, for this specific matter we have three choices: > > > > 1) COMET is always mandatory in both directions. It does not matter if > > the preconditions are mandatory or optional. > > > > 2) COMET is mandatory just when the preconditions are mandatory. > > > > 3) COMET is just sent when requested by any of the parties. This would > > be the mechanism used so far (with the extension defined in > > draft-camarillo-manyfolks-confirm-00.txt) > > > > Approach number 1 is the simplest. After doing whatever in order to > > fulfil the preconditions a COMET is sent. > > > > Number 2 is also pretty simple. If the preconditions were mandatory, the > > session is stopped until the COMET is sent. If the preconditions were > > optional the session establishment goes on, so no COMET is sent. > > > > The gain of approach number 3 is that it saves some messages. However, > > as you pointed out, they are not a lot. In the most common situation it > > would save 2 messages (1 RTT). This is when A calls B in a two-party > > session where there is just one COMET from A towards B. The COMET from B > > to A is not normally needed since B just begins alerting the user once > > the preconditions are met. > > > > So, we have a little more complexity for a little gain. > > > > My only concern is the amonut of signalling messages that we already > > have for establishing a session using preconditions (PRACKs, COMETs). A > > RTT for a workstation in an ethernet is not a big deal, but for a > > terminal using a cellular access begins to be more important. > > > > Anyway, I do not have a religious position here, so any of the 3 > > solutions is alright for me. Let's pick one and go on resolving > > different issues. > > > > Opinions? > > > > Regards, > > > > Gonzalo > > > > Jonathan Rosenberg wrote: > > > > > > Its just thats its more options, more complexities ontop of a thing which > > is > > > growing more and more complex. We need to remove options, not add them. I > > > don't see what they need is for the negotiation. We need to justify the > > > existence of it, not the elimination of it. > > > > > > -Jonathan R. > > > > > > --- > > > Jonathan D. Rosenberg 72 Eagle Rock Ave. > > > Chief Scientist First Floor > > > dynamicsoft East Hanover, NJ 07936 > > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > > > http://www.dynamicsoft.com > > > > > > > -----Original Message----- > > > > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > > > Sent: Tuesday, October 10, 2000 10:46 AM > > > > To: Jonathan Rosenberg > > > > Cc: 'sip' > > > > Subject: Re: [SIP] Feedback on manyfolks > > > > > > > > > > > > Hi, > > > > > > > > Certainly we are not talking about tons of messages. However, in this > > > > case I would rather let the confim be negotiated. The negotiation is > > > > rather simple. > > > > > > > > The UAC can request: > > > > 1) No COMET > > > > 2) one COMET UAC->UAS > > > > 3) one COMET UAC- > > > 4) two COMETs > > > > > > > > The UAS should accept what the UAC requests, and possibly request more > > > > (e.g. two COMETs when the UAC just requested one). > > > > > > > > I believe this is not a complicated mechanism. It is just a > > > > deterministic two-way handshake. > > > > > > > > Best regards, > > > > > > > > Gonzalo > > > > > > > > > > > > > > > > Jonathan Rosenberg wrote: > > > > > > > > > > This seems reasonable to me, and needed, as Gonzalo points out. > > > > > > > > > > My only issue is whether all this stuff should be optional > > > > at all. Wouldn't > > > > > it be easier if both sides always sent COMET, period? All > > > > this negotiation > > > > > stuff is a pain. We're not talking tons of messages here. > > > > Can't we keep it > > > > > simple? > > > > > > > > > > -Jonathan R. > > > > > > > > > > --- > > > > > Jonathan D. Rosenberg 72 Eagle Rock Ave. > > > > > Chief Scientist First Floor > > > > > dynamicsoft East Hanover, NJ 07936 > > > > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > > > > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > > > > > http://www.dynamicsoft.com > > > > > > > > > > > -----Original Message----- > > > > > > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > > > > > Sent: Monday, October 09, 2000 2:33 AM > > > > > > To: sip > > > > > > Subject: [SIP] Feedback on manyfolks > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > Here you have a new I-D that contains feedback on the > > > > manyfolks draft. > > > > > > > > > > > > http://search.ietf.org/internet-drafts/draft-camarillo-manyfol > > > > > > ks-confirm-00.txt > > > > > > > > > > > > " > > > > > > Abstract > > > > > > > > > > > > This document describes certain functionality that is > > > > > > missing in the > > > > > > current "Integration of Resource Management and SIP" > > > > [1] (a.k.a. > > > > > > manyfolks draft). An extension to add this functionality is > > > > > > outlined. > > > > > > > > > > > > This functionality is needed in general to provide richer > > > > > > signalling > > > > > > capabilities and can be employed in several scenarios. > > > > This draft > > > > > > describes its use in third party call control applications. > > > > > > > > > > > > If this extension is accepted it is foreseen that this > > > > draft would > > > > > > be merged with [1]. > > > > > > " > > > > > > > > > > > > Best regards, > > > > > > > > > > > > Gonzalo > > > > > > -- > > > > > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > > > > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > > > > > Telecom R&D Fax : +358 9 299 30 52 > > > > > > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > > > > > > Finland http://www.hut.fi/~gonzalo > > > > > > > > > > > > _______________________________________________ > > > > > > SIP mailing list > > > > > > SIP@lists.bell-labs.com > > > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > > > > > > > -- > > > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > > > Telecom R&D Fax : +358 9 299 30 52 > > > > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > > > > Finland http://www.hut.fi/~gonzalo > > > > > > > > _______________________________________________ > > > > SIP mailing list > > > > SIP@lists.bell-labs.com > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > -- > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > Telecom R&D Fax : +358 9 299 30 52 > > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > > Finland http://www.hut.fi/~gonzalo > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip -- 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 31 18 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Oct 26 03:10:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA12993 for ; Thu, 26 Oct 2000 03:10:04 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B40DC44337; Thu, 26 Oct 2000 02:10:06 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lists.bell-labs.com (Postfix) with ESMTP id DB3F444336 for ; Thu, 26 Oct 2000 02:09:42 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id e9Q79bZ01514; Thu, 26 Oct 2000 09:09:37 +0200 (MEST) Received: from lmf.ericsson.se (E005004B57CE1.lmf.ericsson.se [131.160.30.156]) by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id KAA00292; Thu, 26 Oct 2000 10:09:32 +0300 (EET DST) Message-ID: <39F7D8AB.5A04674F@lmf.ericsson.se> 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: William Marshall Cc: jdrosen@dynamicsoft.com, sip@lists.bell-labs.com Subject: Re: FW: [SIP] Feedback on manyfolks References: <200010252226.SAA87331@fish-ha.research.att.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 26 Oct 2000 10:09:31 +0300 Content-Transfer-Encoding: 7bit Hi, William Marshall wrote: > > Gonzalo wrote: > > The other issue is the one I am after. Both, UAC and UAS understand the > > a=QoS: line. So, considering that both understand it, the UAC wants the > > UAS to wait until the COMET is sent. And, as I said before, I can think > > of many cases where this is needed. > > In enumerating the cases, I see the confirmation-tag choices as follows: > > UAC sends UAS sends result > 1. confirm 1 COMET, UAS->UAC, useless > 2. confirm confirm 2 COMETs, UAS->UAC, then UAC->UAS > 3. 0 COMETs > 4. confirm 1 COMET, UAC->UAS > > I've heard no argument to my proposal of dropping case (1). I cannot think of any useful application of case 1 either. > > Third party call control wants to force choice (4), without going as far as > choice (2), thereby saving one round-trip time and one UAS->UAC message. > Yes, that's right. > If we add a new confirmation-tag value that can be sent by the UAC, "wait", > the revised enumeration of cases is: > > UAC sends UAS sends result > confirm confirm 2 COMETs, UAS->UAC, then UAC->UAS > wait confirm 1 COMET, UAC->UAS > 0 COMETs > confirm 1 COMET, UAC->UAS > > The semantics of this at the UAS are kept very simple: if either a "confirm" > or a "wait" appears as a confirmation-tag in the SDP in the INVITE, then > a "confirm" MUST be sent in the SDP in the 183 response. All other > procedures unchanged. I agree that this mechanisms is not complicated either. However, I still prefer the direction tag after the confirm (confirm sendrecv). The mechanism is as simple as this one, and just by examining the response, it is very clear which messages will be exchanged. That is, if the 183 carries "confirm sendrecv" there will be 2 COMETS. If the 183 response carries "confirm recv", there will be one COMET UAC->UAS. Actually if you want the mechanism to be even clearer you could substitute the word "confirm" by the word "comet". So, you will have in the 183 response: "comet sendrecv"... very straightforward. I would like to hear the advantages that you find in the "wait" tag. I find it a bit cumbersome. When the UAC wants to send the COMET, the UAC should ask the UAS to ask the UAC to send it... why? I find it more natural if the UAC requests the COMET directly: "comet send" in the INVITE. As I said, I find both mechanisms pretty simple, but I see some advantages with the use of the direction tag. > > I believe this covers the third-party call control case. Agree? > > Bill Marshall > wtm@research.att.com > > p.s. > There is only one case not covered, that of the UAC sending but > the UAS wanting a double-COMET exchange. However, the single COMET (which > UAS can force to happen) gives the UAS all the resource results from the UAC, > and the UAS can then decide whether to proceed with a 180-Ringing or to > return a 580-failure. No loss of functionality here, and no reason to > extend the table to allow the UAS to force a double-COMET. What you are saying here is that the UAC has to decide always: 1)If the UAC wants a COMET from UAC->UAS, it makes no sense for the server to request the COMET from UAS->UAC. 2)If the UAC wants 2 COMETS, it makes no sense for the UAS to change this choice. 3)If the UAC wants a COMET from UAS->UAC, it makes no sense for the UAS to request the COMET from UAC->UAS, because the UAC is not interested in sending it. That is, the UAC does not want the session establishment to stop waiting for this COMET. Therefore, what you are trying to do is eliminating the useless cases. After this analysis, it is pretty clear that the UAC can always make the decision of which COMETs should be exchanged. Therefore, I suggest to include in the INVITE the direction tag: "comet send" or "comet sendrecv". Then, the UAS is forced to honor this. The UAS cannot change this. UAC sends result comet sendrecv 2 COMETs, UAS->UAC, then UAC->UAS comet send 1 COMET, UAC->UAS 0 COMETs The only case from your table that is not cover is the following: UAC sends UAS sends result confirm 1 COMET, UAC->UAS As I said before, this case is not unseful. If the strengh parameter was "mandatory", the UAC wants the session establishment to stop until the QoS is granted. But if the UAC did not include "comet send" in the INVITE, it jast can be before he is allset with his part. Therefore, the UAS is not interested in the COMET from UAC->UAS. I believe this is the simplest mechanism and the one we should go for. Best regards, Gonzalo > > -----original message----- > Date: Wed, 25 Oct 2000 22:40:58 +0300 > From: Gonzalo Camarillo > To: William Marshall > Cc: sip@lists.bell-labs.com, jdrosen@dynamicsoft.com > Subject: Re: FW: [SIP] Feedback on manyfolks > > Hi, > > William Marshall wrote: > > > > This sounds like a request for a Requires: header for support of the > > resource reservation procedures. This was considered and rejected; > > perhaps it should be re-opened, but I don't think it solves anything. > > > > The basic problem of a "Requires:" header is what to do if the > > response indicates lack of support. In many cases, that means > > just re-issuing the same request with slight modifications. Such > > appears to be the case with the manyfolks draft. > > > > The current procedures shorten this iteration, by allowing the > > session to proceed and informing the UAC that resource preconditions > > will not be honored. The UAC can then cancel the request if it wants, > > or figure that it is getting the best that it can to that destination. > > > > The notion of a UAC *demanding* that the session not proceed was > > thrown out with the two-phase INVITE that DCS originally proposed. > > As it is shown in the draft this feature is useful in some cases. Among > many others, the third party call control draft needs this in order to > work. > > > > > Presumably, if the UAS supports the resource reservation extension but > > choses not to indicate this in the response messages, it must have a > > good reason for the behavior and should not be overridden by the UAC. > > You are saying that the UAS has a good reason for not adding a confirm > tag to the 183 response?? > > I think you are mixing here two different issues. > One is when the UAS do not understand the a=QoS: line. In this situation > we cannot really do anything (we can just CANCEL the INVITE). > > The other issue is the one I am after. Both, UAC and UAS understand the > a=QoS: line. So, considering that both understand it, the UAC wants the > UAS to wait until the COMET is sent. And, as I said before, I can think > of many cases where this is needed. > > Best regards, > > Gonzalo > > > > > Bill Marshall > > wtm@research.att.com > > > > -----original message----- > > From: Gonzalo Camarillo > > To: William Marshall > > Cc: jdrosen@dynamicsoft.com, sip@lists.bell-labs.com > > Subject: Re: FW: [SIP] Feedback on manyfolks > > Date: Tue, 24 Oct 2000 19:52:56 +0300 > > > > Hi Bill, > > > > There is one scenario you are missing. > > > > The UAC wants to send a COMET (UAC->UAS), but it is not interested in > > receiving a COMET from the UAS. > > > > An scenario containing just one COMET from the UAC to the UAS is already > > in the manyfolks draft, but there, the decision is made by the UAS. The > > UAS is the one deciding that it whishes to receive the COMET from the > > UAC. That's why it adds a confirm in the response. > > > > In the scenario I am after, the UAC is the one that makes the decision. > > He wants the UAS to stop the session establishment until there is a > > COMET from the UAC to the UAS. But he is not interested in the COMET in > > the other direction. > > > > Your suggestion does not solve this problem. > > > > Best regards, > > > > Gonzalo > > > > William Marshall wrote: > > > > > > This discussion took me a little while to figure out, because there > > > was clearly something missing in the manyfolks draft that I wasn't > > > seeing. > > > > > > The current manyfolks draft shows two examples, one where a confirmation > > > is requested by the UAS from the UAC, and one where two confirmations > > > are requested, first by the UAC from the UAS, then by the UAS from the UAC. > > > > > > However, (and the part I missed several times re-re-re-reading the draft), > > > the wording of the spec also allows the UAC to request a confirmation from > > > the UAS without the UAS requesting a confirmation from the UAC. This > > > seems pointless. > > > > > > |----(1)INVITE------->| > > > |<---(2)183-----------| > > > |----(3)PRACK-------->| > > > |<---(4)200-----------| > > > |<---(5)COMET---------| > > > |----(6)200---------->| > > > |<---(7)180-----------| > > > > > > If message (1)INVITE includes a request for a confirmation, i.e. (5)COMET, > > > but message (2)183 does not also request a confirmation, then there is > > > nothing the UAC can do upon receipt of the (5)COMET. The UAS is already > > > doing the alerting and the (7)180 is probably already on its way. The fact > > > that (7)180 is sent indicates the resource preconditions were met by UAS, > > > because otherwise it would have responded with a 580-precondition-failure > > > response. So why even bother with (5)COMET? > > > > > > My original intention in writing the procedures for the two-way COMET > > > exchange was that it be triggered by the UAC requesting a confirmation. > > > The UAS, on receipt of a SDP containing a precondition line with a > > > confirmation request, MUST include a precondition line in its SDP with > > > a confirmation request. This text doesn't appear, and would solve > > > the problem presented by third party call control. > > > > > > Did anyone see a case where the one-way confirmation shown in the > > > diagram above was actually useful and should be allowed? Otherwise, > > > I think we should add the requirement on UAS behavior. > > > > > > If the response to the INVITE(with confirmation requested) is a 180, or > > > a 183 without a precondition line, it indicates the UAS doesn't support > > > the resource extension. A 183 response with a precondition line that > > > doesn't include a confirmation would also, in this case, indicate lack > > > support of the UAS (or lack of sanity). > > > > > > Bill Marshall > > > wtm@research.att.com > > > > > > -----Original Message----- > > > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > > Sent: Thursday, October 12, 2000 1:38 AM > > > To: Jonathan Rosenberg > > > Cc: 'sip' > > > Subject: Re: [SIP] Feedback on manyfolks > > > > > > Hi, > > > > > > I agree. This is getting pretty complex. > > > > > > Anyway, for this specific matter we have three choices: > > > > > > 1) COMET is always mandatory in both directions. It does not matter if > > > the preconditions are mandatory or optional. > > > > > > 2) COMET is mandatory just when the preconditions are mandatory. > > > > > > 3) COMET is just sent when requested by any of the parties. This would > > > be the mechanism used so far (with the extension defined in > > > draft-camarillo-manyfolks-confirm-00.txt) > > > > > > Approach number 1 is the simplest. After doing whatever in order to > > > fulfil the preconditions a COMET is sent. > > > > > > Number 2 is also pretty simple. If the preconditions were mandatory, the > > > session is stopped until the COMET is sent. If the preconditions were > > > optional the session establishment goes on, so no COMET is sent. > > > > > > The gain of approach number 3 is that it saves some messages. However, > > > as you pointed out, they are not a lot. In the most common situation it > > > would save 2 messages (1 RTT). This is when A calls B in a two-party > > > session where there is just one COMET from A towards B. The COMET from B > > > to A is not normally needed since B just begins alerting the user once > > > the preconditions are met. > > > > > > So, we have a little more complexity for a little gain. > > > > > > My only concern is the amonut of signalling messages that we already > > > have for establishing a session using preconditions (PRACKs, COMETs). A > > > RTT for a workstation in an ethernet is not a big deal, but for a > > > terminal using a cellular access begins to be more important. > > > > > > Anyway, I do not have a religious position here, so any of the 3 > > > solutions is alright for me. Let's pick one and go on resolving > > > different issues. > > > > > > Opinions? > > > > > > Regards, > > > > > > Gonzalo > > > > > > Jonathan Rosenberg wrote: > > > > > > > > Its just thats its more options, more complexities ontop of a thing which > > > is > > > > growing more and more complex. We need to remove options, not add them. I > > > > don't see what they need is for the negotiation. We need to justify the > > > > existence of it, not the elimination of it. > > > > > > > > -Jonathan R. > > > > > > > > --- > > > > Jonathan D. Rosenberg 72 Eagle Rock Ave. > > > > Chief Scientist First Floor > > > > dynamicsoft East Hanover, NJ 07936 > > > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > > > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > > > > http://www.dynamicsoft.com > > > > > > > > > -----Original Message----- > > > > > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > > > > Sent: Tuesday, October 10, 2000 10:46 AM > > > > > To: Jonathan Rosenberg > > > > > Cc: 'sip' > > > > > Subject: Re: [SIP] Feedback on manyfolks > > > > > > > > > > > > > > > Hi, > > > > > > > > > > Certainly we are not talking about tons of messages. However, in this > > > > > case I would rather let the confim be negotiated. The negotiation is > > > > > rather simple. > > > > > > > > > > The UAC can request: > > > > > 1) No COMET > > > > > 2) one COMET UAC->UAS > > > > > 3) one COMET UAC- > > > > 4) two COMETs > > > > > > > > > > The UAS should accept what the UAC requests, and possibly request more > > > > > (e.g. two COMETs when the UAC just requested one). > > > > > > > > > > I believe this is not a complicated mechanism. It is just a > > > > > deterministic two-way handshake. > > > > > > > > > > Best regards, > > > > > > > > > > Gonzalo > > > > > > > > > > > > > > > > > > > > Jonathan Rosenberg wrote: > > > > > > > > > > > > This seems reasonable to me, and needed, as Gonzalo points out. > > > > > > > > > > > > My only issue is whether all this stuff should be optional > > > > > at all. Wouldn't > > > > > > it be easier if both sides always sent COMET, period? All > > > > > this negotiation > > > > > > stuff is a pain. We're not talking tons of messages here. > > > > > Can't we keep it > > > > > > simple? > > > > > > > > > > > > -Jonathan R. > > > > > > > > > > > > --- > > > > > > Jonathan D. Rosenberg 72 Eagle Rock Ave. > > > > > > Chief Scientist First Floor > > > > > > dynamicsoft East Hanover, NJ 07936 > > > > > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > > > > > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > > > > > > http://www.dynamicsoft.com > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > > > > > > Sent: Monday, October 09, 2000 2:33 AM > > > > > > > To: sip > > > > > > > Subject: [SIP] Feedback on manyfolks > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > Here you have a new I-D that contains feedback on the > > > > > manyfolks draft. > > > > > > > > > > > > > > http://search.ietf.org/internet-drafts/draft-camarillo-manyfol > > > > > > > ks-confirm-00.txt > > > > > > > > > > > > > > " > > > > > > > Abstract > > > > > > > > > > > > > > This document describes certain functionality that is > > > > > > > missing in the > > > > > > > current "Integration of Resource Management and SIP" > > > > > [1] (a.k.a. > > > > > > > manyfolks draft). An extension to add this functionality is > > > > > > > outlined. > > > > > > > > > > > > > > This functionality is needed in general to provide richer > > > > > > > signalling > > > > > > > capabilities and can be employed in several scenarios. > > > > > This draft > > > > > > > describes its use in third party call control applications. > > > > > > > > > > > > > > If this extension is accepted it is foreseen that this > > > > > draft would > > > > > > > be merged with [1]. > > > > > > > " > > > > > > > > > > > > > > Best regards, > > > > > > > > > > > > > > Gonzalo > > > > > > > -- > > > > > > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > > > > > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > > > > > > Telecom R&D Fax : +358 9 299 30 52 > > > > > > > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > > > > > > > Finland http://www.hut.fi/~gonzalo > > > > > > > > > > > > > > _______________________________________________ > > > > > > > SIP mailing list > > > > > > > SIP@lists.bell-labs.com > > > > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > > > > > > > > > > -- > > > > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > > > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > > > > Telecom R&D Fax : +358 9 299 30 52 > > > > > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > > > > > Finland http://www.hut.fi/~gonzalo > > > > > > > > > > _______________________________________________ > > > > > SIP mailing list > > > > > SIP@lists.bell-labs.com > > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > > > > -- > > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > > Telecom R&D Fax : +358 9 299 30 52 > > > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > > > Finland http://www.hut.fi/~gonzalo > > > > > > _______________________________________________ > > > SIP mailing list > > > SIP@lists.bell-labs.com > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > -- > 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 31 18 > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > Finland _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Oct 26 04:25:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA06305 for ; Thu, 26 Oct 2000 04:25:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A90B844343; Thu, 26 Oct 2000 03:25:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id B591844337 for ; Thu, 26 Oct 2000 03:24:43 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id EAA03486; Thu, 26 Oct 2000 04:26:52 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <4WS2X9WV>; Thu, 26 Oct 2000 04:20:39 -0400 Message-ID: From: Jonathan Rosenberg To: "'pkazmier@ibasis.net'" , sip@lists.bell-labs.com Subject: RE: [SIP] The 'Allow' entity header in rfc2543bis-02 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 26 Oct 2000 04:20:29 -0400 Its not currently in Section 6.10 because the use in requests was a recent addition, and the text for that got put only in one place, but not all places it needed to be. It will be added to section 6.10 as well. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com > -----Original Message----- > From: Pete Kazmier [mailto:pkazmier@ibasis.net] > Sent: Monday, October 23, 2000 4:44 PM > To: sip@lists.bell-labs.com > Subject: [SIP] The 'Allow' entity header in rfc2543bis-02 > > > Section 4.2.1 (INVITE), 3rd paragraph from the end, states: > > The initial INVITE from the UAC SHOULD contain the Allow and > Supported header fields, and MAY contain the Accept header > field. > > Then, section 6.10 (Allow) states: > > An Allow header field MUST be present in a 405 (Method Not > Allowed) response, SHOULD be present in an OPTIONS response > SHOULD be present in the 200 (OK) response to the initial INVITE > for a call and MAY be present in final responses for other > methods. > > Its unclear to me if the 'Allow' entity header SHOULD be in the > initial INVITE. Section 4.2.1 states that it should be, but section > 6.10 doesn't mention it. Could someone please clarify? > > Thanks, > Pete > > -- > Pete Kazmier (781) 505-7590 > Senior Network Systems Engineer pkazmier@ibasis.net > iBasis http://www.ibasis.net > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Oct 26 04:34:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA09126 for ; Thu, 26 Oct 2000 04:34:03 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id ACD804435A; Thu, 26 Oct 2000 03:34:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 38D2844343 for ; Thu, 26 Oct 2000 03:33:12 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id EAA03506; Thu, 26 Oct 2000 04:34:51 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <4WS2X9W5>; Thu, 26 Oct 2000 04:28:39 -0400 Message-ID: From: Jonathan Rosenberg To: "'Sean Olson'" , "Vijay K. Gurbani" Cc: Jonathan Rosenberg , "'Piotr S. Kossowski'" , sip@lists.bell-labs.com Subject: RE: [SIP] Multi-message UDP datagrams MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 26 Oct 2000 04:28:31 -0400 A few comments here. First off, on the other thread about new-fangled way to do content-lengths - no way. As Henning has pointed out, its way too late. Plus, there is proof points that what we have now works fine. The mechanism is the one used by both SIP and HTTP, and there are tons of clients and servers, thin and fat, for both of these, and they work just fine. So, we are back to the original issue - should multiple SIP messages per datagram stay or go. Sean is arguing here that it should stay because its low hanging fruit. I would argue that "COULD" is different from "SHOULD". That is, even if this were easy, if there is no reason or need, its not worth it. Its simply yet-another-thing to test, to interoperate, to cerify correctness, and to worry about. So, I would argue that it should stay only if someone can give a good reason why it should. The only mention of a reason to date has been to save overhead. This, however, is a bogus argument. The overhead of the UDP/IP headers compared to the size of the SIP message is tiny. Multiple messages in one datagram has an almost negligible savings for the vast majority of messages. Thus, I do not see this as a valid argument. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com > -----Original Message----- > From: Sean Olson [mailto:sean.olson@ericsson.com] > Sent: Monday, October 23, 2000 3:31 AM > To: Vijay K. Gurbani > Cc: Jonathan Rosenberg; 'Piotr S. Kossowski'; sip@lists.bell-labs.com > Subject: Re: [SIP] Multi-message UDP datagrams > > > I would strongly disagree with the complexity issue. You need > to know where the > end of a > SIP message is. What happens if you receive garbage at the > end of a UDP datagram? > If you are going to take the time to deal with > Content-Length: or multipart/*, > then you've > gone 99% of the way to supporting multiple messages in a > single UDP datagram. > Easy cheesy! This is not that complex. I would remove line > folding before I > messed > with this. (Not that I'm suggesting we do this) > > -- > Sean Olson > > "Vijay K. Gurbani" wrote: > > > Jonathan Rosenberg wrote: > > > > > > It was my view that receiving multiple messages in a > single datagram was the > > > same as if they were received in separate datagrams. In > other words, there > > > was no requirements for ordering or completion. The > result of that was a > > > simplification in the implementation of handling this > case; UDP works just > > > like TCP. Imposing transactional requirements adds > significant burden. I'd > > > rather not do that unless there was serious requirements > or needs here. > > > > > > In fact, I would argue that multiple messages per > datagram might be > > > something to consider for removal. I've never seen it > used. I'm not sure > > > what the benefit is, in reality. There is little byte > savings, and its just > > > more complexity that is really needless. > > > > > > Lets simplify, not complicate. > > [...] > > > > For whatever it is worth, I agree. In the bakeoff scenarios, I have > > never > > seen a SIP entity send multiple messages in the same datagram. > > > > Regards, > > > > - vijay > > -- > > Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} > > Internet Software/IN Architecture Group > > Lucent Technologies/Bell Labs Innovations 263 Shuman Blvd., > Rm 1A-413 > > Naperville, Illinois 60566 Voice: +1 630 224 0216 > Fax: +1 630 713 > > 0184 > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Oct 26 04:46:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA12785 for ; Thu, 26 Oct 2000 04:46:02 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4AE2D44362; Thu, 26 Oct 2000 03:46:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 3FA094435A for ; Thu, 26 Oct 2000 03:45:04 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id EAA03555; Thu, 26 Oct 2000 04:47:11 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <4WS2X9XG>; Thu, 26 Oct 2000 04:40:59 -0400 Message-ID: From: Jonathan Rosenberg To: "'Baniel Uri-CUB001'" , sip@lists.bell-labs.com Subject: RE: [SIP] Stateful proxy MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 26 Oct 2000 04:40:52 -0400 The situation comes up in a proxy which is TCP on the downstream side and UDP in the upstream side: UDP TCP UA1 -------- Proxy --------- UA2 Lets assume that this proxy is stateless, meaning that it holds the TCP connection state but otherwise does not store transaction state. According to the specification, INVITE responses are not retransmitted over TCP. So, UA2 sends its non-200 response, say a 400, just once over that TCP connection. The proxy receives this, and forwards it to UA1. Its lost. UA2 will not retransmit (since its TCP), and neither will the proxy, since its stateless, thus, the message is lost. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com > -----Original Message----- > From: Baniel Uri-CUB001 [mailto:Uri.Baniel@motorola.com] > Sent: Wednesday, October 18, 2000 11:14 AM > To: sip@lists.bell-labs.com > Subject: [SIP] Stateful proxy > > > Hello > > Why does a proxy that uses TCP must be stateful ? Can someone > show me a scenario which went wrong because of a proxy have > used a TCP and > was stateless? > > Thanks > > Uri > > ===================== > Uri Baniel > Motorola > Network solution Sector > 1155 W. Dundee Rd > Arlington Heights > Tel: 847 632 4616 > ===================== > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Oct 26 05:34:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA27421 for ; Thu, 26 Oct 2000 05:34:02 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 008E644362; Thu, 26 Oct 2000 04:34:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 0645C4435C for ; Thu, 26 Oct 2000 04:33:36 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id FAA03631; Thu, 26 Oct 2000 05:35:41 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <4WS2X9XY>; Thu, 26 Oct 2000 05:29:29 -0400 Message-ID: From: Jonathan Rosenberg To: "'Gonzalo Camarillo'" , William Marshall Cc: Jonathan Rosenberg , sip@lists.bell-labs.com Subject: RE: FW: [SIP] Feedback on manyfolks MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 26 Oct 2000 05:29:19 -0400 > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > Sent: Thursday, October 26, 2000 3:10 AM > To: William Marshall > Cc: jdrosen@dynamicsoft.com; sip@lists.bell-labs.com > Subject: Re: FW: [SIP] Feedback on manyfolks > > > Hi, > > William Marshall wrote: > > > > Gonzalo wrote: > > > The other issue is the one I am after. Both, UAC and UAS > understand the > > > a=QoS: line. So, considering that both understand it, the > UAC wants the > > > UAS to wait until the COMET is sent. And, as I said > before, I can think > > > of many cases where this is needed. > > > > In enumerating the cases, I see the confirmation-tag > choices as follows: > > > > UAC sends UAS sends result > > 1. confirm 1 COMET, UAS->UAC, useless > > 2. confirm confirm 2 COMETs, UAS->UAC, > then UAC->UAS > > 3. 0 COMETs > > 4. confirm 1 COMET, UAC->UAS > > > > I've heard no argument to my proposal of dropping case (1). > > I cannot think of any useful application of case 1 either. > > > > > Third party call control wants to force choice (4), without > going as far as > > choice (2), thereby saving one round-trip time and one > UAS->UAC message. > > > > Yes, that's right. I don't follow this. For 3pcc, the controller needs to know when both UAs have completed resource reservation. This is needed so it, in turn, knows when to send a COMET back to them. This seems to imply that 3pcc really requires case 2. The controller wants COMET from the UA's, and the UA's wait to get COMET from the UAC. The problem described in draft-camarillo-manyfolks-confirm is that there might case (1), that is: After (12), all the preconditions are met. However, the controller does not send a COMET to B (16) until A has answered the INVITE (15). Therefore, if A relied on mechanisms different than COMET (such as ResvConf in RSVP) to check if the resource reservation was already done third party call control mechanisms would fail, since A would go on with the session establishment after (12), instead of waiting for (15). Preconditions met confirmations must rely solely on application layer mechanisms - SIP. But, as Bill has pointed out, the easier way to solve this is to forbid this case when the UAS understands preconditions. In other words, if A requests confirmation from B, and B understands the extension, B MUST include a confirmation request in its 183 back to A. This seems to address the problem you are describing. I'd still argue that this whole thread is an artifact of the overly-flexible mechanism defined in the preconditions draft. All this negotiation is simply confusing, and can lead to cases like this where someone wants something, but the other guy doesn't do it, etc. The KISS principle would argue that once the UAC sends a request with preconditions, we have COMET in both directions (assuming, of course, the UAS understands it). Period. This is equivalent to the "comet sendrecv" case below always being used by the UAC. Gonzalo wrote: > Therefore, I suggest to include in the INVITE the direction > tag: "comet > send" or "comet sendrecv". Then, the UAS is forced to honor this. The > UAS cannot change this. > > UAC sends result > comet sendrecv 2 COMETs, UAS->UAC, then UAC->UAS > comet send 1 COMET, UAC->UAS > 0 COMETs > > The only case from your table that is not cover is the following: > UAC sends UAS sends result > confirm 1 COMET, UAC->UAS > > As I said before, this case is not unseful. If the strengh > parameter was > "mandatory", the UAC wants the session establishment to stop until the > QoS is granted. But if the UAC did not include "comet send" in the > INVITE, it jast can be before he is allset with his part. > Therefore, the > UAS is not interested in the COMET from UAC->UAS. > > I believe this is the simplest mechanism and the one we should go for. > -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Oct 26 05:56:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA04196 for ; Thu, 26 Oct 2000 05:56:00 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 83F934433D; Thu, 26 Oct 2000 04:56:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lists.bell-labs.com (Postfix) with ESMTP id 25BE14433B for ; Thu, 26 Oct 2000 04:55:56 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id e9Q9toZ18223; Thu, 26 Oct 2000 11:55:50 +0200 (MEST) Received: from lmf.ericsson.se (E005004B57CE1.lmf.ericsson.se [131.160.30.156]) by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id MAA14087; Thu, 26 Oct 2000 12:55:49 +0300 (EET DST) Message-ID: <39F7FFA3.F46475C4@lmf.ericsson.se> 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: Jonathan Rosenberg Cc: William Marshall , sip@lists.bell-labs.com Subject: Re: FW: [SIP] Feedback on manyfolks References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 26 Oct 2000 12:55:47 +0300 Content-Transfer-Encoding: 7bit Hi Jonathan, Jonathan Rosenberg wrote: > I'd still argue that this whole thread is an artifact of the overly-flexible > mechanism defined in the preconditions draft. All this negotiation is simply > confusing, and can lead to cases like this where someone wants something, > but the other guy doesn't do it, etc. The KISS principle would argue that > once the UAC sends a request with preconditions, we have COMET in both > directions (assuming, of course, the UAS understands it). Period. This is > equivalent to the "comet sendrecv" case below always being used by the UAC. I agree with you. We do not need an overflexible mechanism. But what I am proposing here is actually very close to what you are saying. Your suggestion is: UAC sends result comet sendrecv 2 COMETs, UAS->UAC, then UAC->UAS 0 COMETs My suggestion is: UAC sends result comet sendrecv 2 COMETs, UAS->UAC, then UAC->UAS comet send 1 COMET, UAC->UAS 0 COMETs Neither of both nechanisms allow for negotiation or complicated stuff. Actually both mechanisms very similar. However, the second one would save one RTT is certain situations. Actually, it would save one RTT in the most common situation (two-party session where the UAS waits for the COMET from the UAC and then, when the UAS is allset with the QoS reservation alerts the user). Therefore, you achieve this gain by adding negligible complexity. I still believe that the second mechanism is the one we should go for. It does not break the KISS principle at all and it would decrease the session establishment time for terminals using low-rate accesses. Best regards, Gonzalo > > Gonzalo wrote: > > Therefore, I suggest to include in the INVITE the direction > > tag: "comet > > send" or "comet sendrecv". Then, the UAS is forced to honor this. The > > UAS cannot change this. > > > > UAC sends result > > comet sendrecv 2 COMETs, UAS->UAC, then UAC->UAS > > comet send 1 COMET, UAC->UAS > > 0 COMETs > > > > The only case from your table that is not cover is the following: > > UAC sends UAS sends result > > confirm 1 COMET, UAC->UAS > > > > As I said before, this case is not unseful. If the strengh > > parameter was > > "mandatory", the UAC wants the session establishment to stop until the > > QoS is granted. But if the UAC did not include "comet send" in the > > INVITE, it jast can be before he is allset with his part. > > Therefore, the > > UAS is not interested in the COMET from UAC->UAS. > > > > I believe this is the simplest mechanism and the one we should go for. > > > > -Jonathan R. > --- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Oct 26 06:16:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA09568 for ; Thu, 26 Oct 2000 06:16:04 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 09A174435E; Thu, 26 Oct 2000 05:16:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id E511544353 for ; Thu, 26 Oct 2000 05:15:35 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id GAA03697; Thu, 26 Oct 2000 06:17:42 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <4WS2X9Y2>; Thu, 26 Oct 2000 06:11:29 -0400 Message-ID: From: Jonathan Rosenberg To: "'Adam B. Roach'" , huitema@microsoft.com Cc: sip@lists.bell-labs.com, sip-events@egroups.com Subject: RE: [SIP] New SUBSCRIBE/NOTIFY draft available MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 26 Oct 2000 06:11:27 -0400 > -----Original Message----- > From: Adam B. Roach [mailto:Adam.Roach@Ericsson.com] > Sent: Wednesday, October 25, 2000 4:25 PM > To: huitema@microsoft.com > Cc: sip@lists.bell-labs.com; sip-events@egroups.com > Subject: Re: [SIP] New SUBSCRIBE/NOTIFY draft available > > > Christian Huitema writes: > >What is the relation between this draft and > >"draft-rosenberg-impp-presence-00.txt" ? > > My intention was to synchronise the drafts as closely as possible. > To my knowledge, the events draft allows for all of the behaviours > described in the presence draft (with one minor exception; see below). Right. One of the outputs of our discussion during the last IETF was the need for a core mechanism that could be applied to all of the proposed SUB/NOTIFY applications. > >1) the IMPP draft defines that "SUBSCRIBE" creates a > subscription session, > >identified by its own Call-Id. The session expires when the > life time of the > >subscribe expires before being renewed by another subscribe > for the same > >call-id, or if the subscriber sends a subscribe with a null > lifetime. > > This is what I describe as "third-party" subscriptions. The behavior > is, to my knowledge, identical between the presence and events draft. > If I have left something out in this regards, please let me know. > > (From section 5.1.1:) > > "Third-party SUBSCRIBE requests will not correlate to any > previously-existing call leg in the server. The Call-ID of > resource-related requests will be unique to the SUBSCRIBE and any > subsequent NOTIFY requests." I agree with Christian on this one - that is, I think the semantics of a subscription are always the same. A subscription may or may not appear with the same To/From/Call-ID as an existing call leg, and that does not change at all how one subscribes to something. The body always specifies details of the thing being subscribed to, within the context of the package defined in the Event header. What you are doing here with call-leg related subscriptions is a short cut mechanism to describe the event you are subscribing to. I'd rather keep everything uniform. > > >2) In IMPP, the object to which you subscribe is identified by the > >request-URI. In PINT, we want to know about the handling of > a call. If we > >subscribe to a call, we have to explicit the syntax of the > URI that defines > >"the call." > > Once again, I beleive that the behavior in the events draft is > lined up with that in the presence draft (section 5.1.3): > > "The Request URI of a SUBSCRIBE request, most importantly, > contains enough information to route the request to the > appropriate entity. It also contains enough information to > identify the resource for which event notification is desired, > but not necessarily enough information to uniquely identify the > nature of the event (e.g. "sip:adam.roach@ericsson.com" would be > an appropriate URI to subscribe to for my presence state; it > would also be an appropriate URI to subscribe to the state of my > voice mailbox)." > > If you have any ideas about how this mechanism can be refined to > align more closely with PINT, I'm open to suggestions. Note that, > from where I stand, the description in my draft is not > fundimentally at > odds with PINT. I think it matches up. In pint, the request URI apparently tells you zero about whats being subscribed to, neither does the Call-ID. Its the presence of SDP, and basically the session ID in the SDP that indicates what is being subscribed to. So, this aligns with what we have here, excepting the absence of the Event header. Your hack of "not present means PINT" solves that problem. > > >3) In the IMPP discussion, we agreed that we should be able > to have some > >amount of security about transport boundaries, for example when you > >translate a SIP Notify into an IMXP Notify. This implies > that the meat of > >the notification should be carried in the payload, which can > be passed > >unchanged accross system boundaries, rather than in the > headers, which will > >probably be lost. Use of a common syntax is necessary if you > want to allow > >encryption or digital signature of the payload. The > agreement is to define > >that syntax in XML. This implies that the events should be > reported as XML > >tokens in the payload, not as SIP Headers. It is in fact a sound > >architecture: use the header for "transport control", use > the payload for > >"information." (The basic format of the payload should come > from the IMPP > >working group; we have all possibilities to extend it.) > > The draft I just published accomodates this model quite well. > As in the presence draft, the URI indicates the object to which > a subscription is being requested. I suspect that, for presence, > an XML-based presence syntax (or one that can be freely translated > to and from XML) will be carried in the body. > > The only headers added by the events draft are "Event:" and > "Allow-Event:". "Event:" is used solely as an opaque token to > differentiate beween different event extensions (e.g. PINT and > presence). You can think of it as very roughly analogous to the > "Required:" header for SIP extensions. Similarly, "Allow-Events" > can be thought of as similar to "Supported:". Right. Event is a way to scope the type of subscription. I suppose we could push that into the body as well, but it seems reasonable to keep it in the headers as it could possible affect routing decisions. > > >4) In the IMMP discussion, we also agreed that the > publisher/presentity > >should be able to terminate a subscription at any time, and > should be able > >to report this event in a Notify. > > Thank you; this is apparently a feature I overlooked. I will add > this in an upcoming version of the draft. Its actually not specified right now in draft-rosenberg-impp-presence, but is rather something that has been discussed on the lists and other places. > > >In your draft, you mention a possible linkage between the > duration of the > >subscription session and the duration of a call. I think > that the Notify > >solution presented above (4) solves that problem without > requiring any > >additional linkage between the call and the subscription session. > > This linkage only applies for call-related subscriptions; this is > precicely the kind of subscription that presence does not use. I don't like this. We need one mechanism, and only one, which tells us what the duration of a subscription is. Making it event specific (which is basically what you are doing here, since call-related subscriptions work only for one of the event types we've seen so far), seems a recipe for disaster. > What does this gain you? It's a very simple way for call-leg related > event extensions to use an existing mechanism to say "I want events > relating to *this* call leg" without defining an additional > correlation mechanism. The alternative is for these types of > extensions to go out of their way to define a leg correlation > mechanism for the body of their message: > > SUBSCRIBE sip:eusadam@ws148.ericsson.com SIP/2.0 > To: ;tag=abcd > From: ;tag=ef01 > Call-ID: 1234@a1234.microsoft.com > CSeq: 2874 SUBSCRIBE > Event: foo > Content-Type: text/fooml > Content-Length: 205 > > > > > > > > ... > You are going to need this anyway, I suspect. I bet you that people WILL want third party subscription mechanisms for call state. > > >I understand the need to decouple the SIP syntax from the > vagaries of the > >IMPP working group. But I think that it would be beneficial > to merge your > >draft with the sip-impp draft, or at least with the protocol > description > >part of that draft. > > My hope is that, once the events draft is complete, the presence > draft will be somewhat thinner, and have the luxury of concentrating > on presence instead of event notification. If you feel that there > are any generally applicable features included in the presence > draft which I have failed to clearly incorporate in my draft, please > point them out. I believe that, in general, your draft is more or less the distillation of the presence draft, modulo the above issues plus one more. That additional issue centers around your statement: Since forking proxies pass all 200 responses upstream, it is expected that these "From" fields will not contain any tags which are unknown to the subscriber. However, to make the subscription mechanism more robust, subscribers SHOULD be prepared to receive notifications with previously unknown tags in the "From" field. Your assumption here is false. For non-INVITE methods, there is only a single 200 OK passed upstream. It is this subtlety that led us to say, in the presence draft: For SIP experts - this represents a slightly different operation than for INVITE. When a user sends an INVITE, they will receive a 200 OK with a tag. Requests in the reverse direction then contain that tag, and that tag only, in the From field. Here, the response to SUBSCRIBE may contain a tag in the To field, and a NOTIFY will contain a tag in the From field. However, the UA may receive NOTIFY requests with tags in the From field that do not match the tag in the 200 OK received to the initial SUBSCRIBE. This is because only a single 200 OK is returned to a SUBSCRIBE request, as opposed to multiple 200 OK for INVITE. Thus, the UA MUST be prepared to receive NOTIFYs with many different tags, each from a different PUA. Besides this issue, and the ones above regarding call-leg specific subscriptions, I believe there is nothing different between the two (to put it in Adam's terms, the presence draft is a concrete implementation of the abstract class defined in his draft, without overriding any of its methods :) ) I need to go over both with a fine tooth comb to be sure, however. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Oct 26 06:44:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA15519 for ; Thu, 26 Oct 2000 06:44:02 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2A51744341; Thu, 26 Oct 2000 05:44:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id EE8554433D for ; Thu, 26 Oct 2000 05:43:14 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id GAA03771; Thu, 26 Oct 2000 06:45:22 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <4WS2X9Y5>; Thu, 26 Oct 2000 06:39:09 -0400 Message-ID: From: Jonathan Rosenberg To: "'Christer Holmberg'" , sip@lists.bell-labs.com Cc: Igor Slepchin , sean.olson@ericsson.com Subject: RE: [SIP] Redirect server returning new From header MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 26 Oct 2000 06:39:04 -0400 I thought we had put this issue to bed. As Henning pointed out previously, allowing a UAC to insert a telephone number into a request, which is then passed to the PSTN (via a gateway) as the originating number, is a recipe for a security disaster. Nothing stops me from inserting fake telephone numbers, and calling people pretending to be someone else. You can expect a call from the FCC about that one. So, in fact, this proposed used of the Also-From header is, in practice, unusable without a massive security/PKI infrastructure which really doesn't exist (you would need someone to certify that joe@foo.com owns the number 555-1212. I don't even know who would be able to adequately certify this, and I suspect no CA in their right mind would ever put this in a certificate). So, by corollary, having a proxy tell a UA what number it owns is even more of a security nightmare, and even less likely to ever work. Thus, the mechanics of how best to accomplish it are moot. Perhaps I sound harsh, but I am trying really hard to push back on everyones "lets add X to SIP" request. SIP is already an RFC, folks. We are obliged to carefully scrutinize everything that gets added, and only put things in when they are truly needed, broadly useful, and backwards compatible. This Also-From thing has only one proposed application, which is interoperation with the PSTN, and in this application is frought with serious security issues. -Jonathan R. > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > Sent: Wednesday, October 25, 2000 1:47 AM > To: sip@lists.bell-labs.com > Cc: Igor Slepchin; sean.olson@ericsson.com > Subject: Re: [SIP] Redirect server returning new From header > > > > Hi, > > >You can use URL headers to specify SIP message headers, > e.g., the Contact >in the 302 may look like > > > >Contact: sip:chirster@ericsson?from=tel:12345 > > > >It's then up to the UAC to trust your redirect server and > overwrite its > >default From header. See section 2 of 2543bis for details. > > True, but in this case the redirect server (what I mean by that is > actually any SIP node, server or UA, with redirect functionality...) > will not know if the UAC is going to use the new header or > not. For some > reason, the redirect server may behave in different ways > (maybe, in some > case, it won't even allow the UAC to contact a certain host if the > feature is not supported...) depending on if it can give the UAC a new > From header or not. > > But, if we have a new header for this, the UAC can indicate in the > Supported header that it supports this feature. Then, the redirect > server can add the new "Also-From" header in the response, > and indicate > in the Require header that the UAC must use it. Maybe this is possible > also in the case where you just add it to the Contact header, > but in any > case I think you would have to define a new Supported/Require > tag value > (?) --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Oct 26 06:51:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA17154 for ; Thu, 26 Oct 2000 06:51:03 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4473744368; Thu, 26 Oct 2000 05:51:06 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 479C74435E for ; Thu, 26 Oct 2000 05:50:54 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id GAA03792; Thu, 26 Oct 2000 06:53:02 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <4WS2X9Y9>; Thu, 26 Oct 2000 06:46:49 -0400 Message-ID: From: Jonathan Rosenberg To: "'Drage, Keith (Keith)'" , "'SIP discussion list'" Subject: RE: [SIP] Potential definitions required MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 26 Oct 2000 06:46:44 -0400 > -----Original Message----- > From: Drage, Keith (Keith) [mailto:drage@lucent.com] > Sent: Wednesday, October 25, 2000 9:52 AM > To: 'SIP discussion list' > Subject: [SIP] Potential definitions required > > > Looking at the bis draft from a readability viewpoint I > considered that a > number of additional definitions at the start of the document > would improve > things. Could I therefore make a request that definitions are > drafted for > the following: > > stateful proxy (server) > stateless proxy (server) OK. > method > header Well, I think these are well understood within the community; they likely need to be defined just as much as "protocol" or "name-value pair" would need to be defined. Not a big deal, though, to add. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Oct 26 06:55:06 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA18039 for ; Thu, 26 Oct 2000 06:55:06 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 16F5B4436E; Thu, 26 Oct 2000 05:55:06 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id CEEFE44368 for ; Thu, 26 Oct 2000 05:54:23 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id GAA03804; Thu, 26 Oct 2000 06:56:32 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <4WS2X9ZB>; Thu, 26 Oct 2000 06:50:19 -0400 Message-ID: From: Jonathan Rosenberg To: "'Drage, Keith (Keith)'" , "'SIP discussion list'" Subject: RE: [SIP] Use of notes within the RFC bis draft MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 26 Oct 2000 06:50:13 -0400 > -----Original Message----- > From: Drage, Keith (Keith) [mailto:drage@lucent.com] > Sent: Wednesday, October 25, 2000 9:52 AM > To: 'SIP discussion list' > Subject: [SIP] Use of notes within the RFC bis draft > > > This comment is about the documentation, rather than one of any direct > technical import. > > I note throughout the bis draft various areas of indented > text, which I > assume to be the equivalent of notes in documents produced by other > standards bodies. Is this true? They are commentaries that provide explanations or implementation hints. > > Some of these paragraphs begin with the word "Note:" and some > do not. Does > this imply any difference in status of that text. No. > > There are additionally a large number of sentences throughout > the text that > commence: "Note that...". Are these also notes. > > As there is a need for other standards organisations to reference the > resultant RFCs with a clear understanding of the difference between > normative (i.e. requirements and definitions) and informative > material (i.e. > notes), I would like to propose that this distinction is made > absolutely > clear. In particular, I propose: > > - add the word "Note:" at the start of all indented text. > - make all sentences starting with the words "Note that" > into indented > text comencing with the word "Note:". I don't think this is really needed. The IETF has a clearly defined syntax for describing normative behaviors (rfc2119), and this has sufficed for RFCs up till now. -Jonatan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Oct 26 09:34:07 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA08187 for ; Thu, 26 Oct 2000 09:34:07 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2815044338; Thu, 26 Oct 2000 08:34:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from elektron.elka.pw.edu.pl (elektron.elka.pw.edu.pl [194.29.160.2]) by lists.bell-labs.com (Postfix) with ESMTP id 2F86244337 for ; Thu, 26 Oct 2000 08:33:06 -0400 (EDT) Received: from po60.warszawa.cvx.ppp.tpnet.pl ([213.76.110.60]:1075 "EHLO elka.pw.edu.pl") by elektron.elka.pw.edu.pl with ESMTP id ; Thu, 26 Oct 2000 15:32:47 +0200 Message-ID: <39F830D8.757E955D@elka.pw.edu.pl> From: "Piotr S. Kossowski" Organization: Warsaw University of Technology - Institute of Telecommunications X-Mailer: Mozilla 4.7 [pl] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] message retransmission - a need clarification Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 26 Oct 2000 15:25:44 +0200 Content-Transfer-Encoding: 7bit Hi All, I need some clarification on support of message retransission on UAS side, because it isn't explicite wrote in the spec, i think. First of all: 10.1.1 of the rfc 2543bis-02: "Servers discard ISOMORPHIC requests, but first retransmit the appropriate response. (SIP requests are said to be idempotent, i.e., receiving more than one copy of a request does not change the server state.)" For me it means that if UAS gets a message what it have already got the last time it sends a response that it sent the last time, independable of its current state. I think, for yet, it's clear. According to 1.3: "Two requests or responses are defined to be ISOMORPHIC for the purposes of this document if they have the same values for the Call-ID, To, From and CSeq header fields. In addition, isomorphic requests have to have the same Request-URI and the same second branch parameter in their top-most Via header." So, by definition, retransmission generates always Isomorphic request. On the other hand, if, for example, UAC sends retransmitted message, but it adds e.g. Subject header, what means that it is not retransmission (it's not allowed without changing of CSeq, of course), for UAS this message is still ISOMORPHIC and must (should?) be treated as a retransmission. Is it true ? Next: Let's assume that after INVITE from UAC, UAS sent final 603 (Decline) response (without Retry-After), without eariler provisional response. It probably means that UAS' user will not accept any call from the UAC in the nearest future. Let's assume that this 603 message lost. Thus, UAC retransmit the INVITE. It causes that UAS' user will be bothered by incoming call again (it's of course implemmentation matter). Anyway, we don't want UAS to take up decission again (accept, reject, redirect). So, UAS should keep information about no longer existed calls in case of need of retransmission of response. And that's my questions: 1. Is it true ? 2. If yes, how long (as I noticed, the spec says only about proxies - 32 seconds. The only one such kind of timeout for UAS is on figure 12) ? The last: 10.1.1 (again): "If the request is accepted and matches an existing call leg, the server compares the CSeq header field value. If LESS than or equal to the current sequence number, the request is a retransmission. " It's said: LESS or equal. In case of equal - this message is ISOMORPHIC with last received message befor this one, and UAS sends again response. in case of LESS - ???. Should it retransmit something ? If yes, what is ISOMORPHIC with what and how many messages must 'remember" UAS ? Thank You, Piotr _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Oct 26 09:46:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA10856 for ; Thu, 26 Oct 2000 09:46:03 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0A9A444346; Thu, 26 Oct 2000 08:46:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from atlrel1.hp.com (atlrel1.hp.com [156.153.255.210]) by lists.bell-labs.com (Postfix) with ESMTP id 608CB44337 for ; Thu, 26 Oct 2000 08:45:12 -0400 (EDT) Received: from hpqs0130.sqf.hp.com (hpqs0130.sqf.hp.com [15.144.177.5]) by atlrel1.hp.com (Postfix) with ESMTP id 5C67D111 for ; Thu, 26 Oct 2000 09:45:06 -0400 (EDT) Received: from sqf0084 (sqf0084.sqf.hp.com [15.144.188.101]) by hpqs0130.sqf.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.0) with SMTP id OAA29813 for ; Thu, 26 Oct 2000 14:45:02 +0100 (BST) Message-ID: <037501c03f52$f03e8070$65bc900f@sqf0084.sqf> Reply-To: "Andy Duncan" From: "Andy Duncan" To: 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.3612.1700 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700 Subject: [SIP] SIP and SIP-T distinction. Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 26 Oct 2000 14:45:00 +0100 Content-Transfer-Encoding: 7bit Hi, I realise that SIP-T is not a new protocol specification but simply details the methods, standards and tools necessary to enable MGC's to inter operate via the SIP protocol BUT is there an easy way to distinguish bewteen SIP and SIP-T messages (i.e. messages with encapsulated ISUP as well as SDP). For example, will a SIP-T message have its own SIP-VERSION to go in the request/response header - SIP-T/1.0 ? Or is the message body is defined as having CONTENT-TYPE of multipart/mixed can you assume it is a SIP-T message ? I take it this too much to assume as there is no doubt other expansions of SIP that use this MIME format for multiple payloads, or is likely to be so in the future. Also, is it likely that multipart/mixed may just be used to carry the SDP information on its own instead of application/sdp ? Or is the only way to determine whether there is an ISUP payload is to delve into the message body and look for CONTENT-TYPE application/isup ? Finally, is it also tto much to assume that the SDP payload will always precede the ISUP payload in the message body ? Hopefully, I have not polluted your mailing list with my inane ramblings, but I have scoured your FAQ section and archives to no avail !! Thanks for any help anyone is prepared to give. Andy. ============================ Andrew S Duncan Agilent Technologies Tel: 0131 331 7822 Exten: 32822 Mailstop: SQFR&D3 ============================ _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Oct 26 09:51:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA11954 for ; Thu, 26 Oct 2000 09:51:02 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9462C44344; Thu, 26 Oct 2000 08:51:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from elektron.elka.pw.edu.pl (elektron.elka.pw.edu.pl [194.29.160.2]) by lists.bell-labs.com (Postfix) with ESMTP id AC89344342 for ; Thu, 26 Oct 2000 08:50:40 -0400 (EDT) Received: from po60.warszawa.cvx.ppp.tpnet.pl ([213.76.110.60]:1284 "EHLO elka.pw.edu.pl") by elektron.elka.pw.edu.pl with ESMTP id ; Thu, 26 Oct 2000 15:50:11 +0200 Message-ID: <39F836A4.2115E9A0@elka.pw.edu.pl> From: "Piotr S. Kossowski" Organization: Warsaw University of Technology - Institute of Telecommunications X-Mailer: Mozilla 4.7 [pl] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Subject: [SIP] message retransmission - a need clarification Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 26 Oct 2000 15:50:28 +0200 Content-Transfer-Encoding: 7bit Hi All, I need some clarification on support of message retransission on UAS side, because it isn't explicite wrote in the spec, i think. First of all: 10.1.1 of the rfc 2543bis-02: "Servers discard ISOMORPHIC requests, but first retransmit the appropriate response. (SIP requests are said to be idempotent, i.e., receiving more than one copy of a request does not change the server state.)" For me it means that if UAS gets a message what it have already got the last time it sends a response that it sent the last time, independable of its current state. I think, for yet, it's clear. According to 1.3: "Two requests or responses are defined to be ISOMORPHIC for the purposes of this document if they have the same values for the Call-ID, To, From and CSeq header fields. In addition, isomorphic requests have to have the same Request-URI and the same second branch parameter in their top-most Via header." So, by definition, retransmission generates always Isomorphic request. On the other hand, if, for example, UAC sends retransmitted message, but it adds e.g. Subject header, what means that it is not retransmission (it's not allowed without changing of CSeq, of course), for UAS this message is still ISOMORPHIC and must (should?) be treated as a retransmission. Is it true ? Next: Let's assume that after INVITE from UAC, UAS sent final 603 (Decline) response (without Retry-After), without eariler provisional response. It probably means that UAS' user will not accept any call from the UAC in the nearest future. Let's assume that this 603 message lost. Thus, UAC retransmit the INVITE. It causes that UAS' user will be bothered by incoming call again (it's of course implemmentation matter). Anyway, we don't want UAS to take up decission again (accept, reject, redirect). So, UAS should keep information about no longer existed calls in case of need of retransmission of response. And that's my questions: 1. Is it true ? 2. If yes, how long (as I noticed, the spec says only about proxies - 32 seconds. The only one such kind of timeout for UAS is on figure 12) ? The last: 10.1.1 (again): "If the request is accepted and matches an existing call leg, the server compares the CSeq header field value. If LESS than or equal to the current sequence number, the request is a retransmission. " It's said: LESS or equal. In case of equal - this message is ISOMORPHIC with last received message befor this one, and UAS sends again response. in case of LESS - ???. Should it retransmit something ? If yes, what is ISOMORPHIC with what and how many messages must 'remember" UAS ? Thank You, Piotr _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Oct 26 10:06:50 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA15505 for ; Thu, 26 Oct 2000 10:06:50 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C77D144360; Thu, 26 Oct 2000 09:02:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103]) by lists.bell-labs.com (Postfix) with ESMTP id C73444435A for ; Thu, 26 Oct 2000 09:01:23 -0400 (EDT) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id 435851E01D; Thu, 26 Oct 2000 10:01:15 -0400 (EDT) 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 KAA26821; Thu, 26 Oct 2000 10:01:12 -0400 (EDT) From: William Marshall Received: (from wtm@localhost) by fish-ha.research.att.com (980427.SGI.8.8.8/8.8.5) id KAA29548; Thu, 26 Oct 2000 10:01:12 -0400 (EDT) Message-Id: <200010261401.KAA29548@fish-ha.research.att.com> To: sip@lists.bell-labs.com Cc: jdrosen@dynamicsoft.com, Gonzalo.Camarillo@lmf.ericsson.se Subject: Re: FW: [SIP] Feedback on manyfolks Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 26 Oct 2000 10:01:12 -0400 (EDT) I'm lost in this discussion. Based on Jonathan's comments, with which I completely agree, I think we have third-party-call-control covered, with only the one simple clarification to the manyfolks draft (that a confirm in the SDP from the UAC requires a double COMET). Is there some other application of this procedure that should be covered and isn't? So let me try to recap, and see where we stand. I wrote (Wednesday): > > In enumerating the cases, I see the confirmation-tag choices as follows: > > UAC sends UAS sends result > 1. confirm 1 COMET, UAS->UAC, useless > 2. confirm confirm 2 COMETs, UAS->UAC, then UAC->UAS > 3. 0 COMETs > 4. confirm 1 COMET, UAC->UAS > > I've heard no argument to my proposal of dropping case (1). > > Third party call control wants to force choice (4), without going as far as > choice (2), thereby saving one round-trip time and one UAS->UAC message. > Jonathan wrote (Thursday) (responding to Gonzalo who responded to me): > > > > > > Third party call control wants to force choice (4), without > > > going as far as > > > choice (2), thereby saving one round-trip time and one > > > UAS->UAC message. > > > > > > > Yes, that's right. > > I don't follow this. For 3pcc, the controller needs to know when both UAs > have completed resource reservation. This is needed so it, in turn, knows > when to send a COMET back to them. This seems to imply that 3pcc really > requires case 2. The controller wants COMET from the UA's, and the UA's wait > to get COMET from the UAC. The problem described in > draft-camarillo-manyfolks-confirm is that there might case (1), that is: > > After (12), all the preconditions are met. However, the controller > does not send a COMET to B (16) until A has answered the INVITE > (15). Therefore, if A relied on mechanisms different than COMET > (such as ResvConf in RSVP) to check if the resource reservation was > already done third party call control mechanisms would fail, since A > would go on with the session establishment after (12), instead of > waiting for (15). Preconditions met confirmations must rely solely > on application layer mechanisms - SIP. > > But, as Bill has pointed out, the easier way to solve this is to forbid this > case when the UAS understands preconditions. In other words, if A requests > confirmation from B, and B understands the extension, B MUST include a > confirmation request in its 183 back to A. This seems to address the problem > you are describing. > But, when this was first proposed on Monday, Gonzalo wrote (Tuesday): > > There is one scenario you are missing. > > The UAC wants to send a COMET (UAC->UAS), but it is not interested in > receiving a COMET from the UAS. > > A scenario containing just one COMET from the UAC to the UAS is already > in the manyfolks draft, but there, the decision is made by the UAS. The > UAS is the one deciding that it whishes to receive the COMET from the > UAC. That's why it adds a confirm in the response. > > In the scenario I am after, the UAC is the one that makes the decision. > He wants the UAS to stop the session establishment until there is a > COMET from the UAC to the UAS. But he is not interested in the COMET in > the other direction. > > Your suggestion does not solve this problem. > So before considering this discussion closed, let me ask whether there is an application where the single-COMET decision can't be made by the UAS? It seems to me that the UAC requesting "sendrecv" QoS is stating exactly that as a precondition, that the QoS be established in both directions. RSVP only does one direction, so a UAS that uses RSVP will necessarily require a COMET in order to achieve bi-directional QoS before proceeding with the session. So the choices at the UAS are (1) a=qos:sendrecv confirm, or (2) respond with a=qos:send, or (3) use something other than RSVP to get bi-directional QoS. If the UAS does choice (3), there is no reason for a COMET, and the UAC should not require it. Bill Marshall wtm@research.att.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Oct 26 10:11:26 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA16520 for ; Thu, 26 Oct 2000 10:11:26 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 89FF84436B; Thu, 26 Oct 2000 09:02:14 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from topaz.3com.com (topaz.3com.com [192.156.136.158]) by lists.bell-labs.com (Postfix) with ESMTP id 3879D44336 for ; Wed, 25 Oct 2000 11:47:07 -0400 (EDT) Received: from opal.3com.com (opal.3com.com [139.87.50.117]) by topaz.3com.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id e9PGkOT13334; Wed, 25 Oct 2000 09:46:24 -0700 (PDT) Received: from hqoutbound.ops.3com.com (hqoutbound.OPS.3Com.COM [139.87.48.104]) by opal.3com.com (Switch-2.0.1/Switch-2.0.1) with SMTP id e9PGkwT17024; Wed, 25 Oct 2000 09:46:58 -0700 (PDT) Received: by hqoutbound.ops.3com.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 88256983.005C6092 ; Wed, 25 Oct 2000 09:49:00 -0700 X-Lotus-FromDomain: 3COM From: Anoop_Tripathi@3com.com To: "Adam B. Roach" Cc: sip@lists.bell-labs.com, sip-events@egroups.com Message-ID: <88256983.005C5FB3.00@hqoutbound.ops.3com.com> Subject: Re: [SIP] New SUBSCRIBE/NOTIFY draft available Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 25 Oct 2000 11:47:03 -0500 I have few comments on this draft. Was using a header in INVITE/REGISTER requests as a replacement of SUBSCRIBE request considered? So far I could only see two cases of using SUBSCRIBE. One during call. In that case we could send the subscribe information in INVITE/RE-INVITE requests. Second as part of registration. You register to Proxy, Voice-mail server etc and subscribe to events. So what is the motivation behind having a separate request? The NOTIFY request seems fine. By defining SUBSCRIBE/NOTIFY requests are we trying to achieve the similar functionality that exists in MEGACO/H.248. Is DTMF digit collection a valid usage of this scheme? Thanks, Anoop "Adam B. Roach" on 10/25/2000 10:57:28 AM Sent by: "Adam B. Roach" To: sip@lists.bell-labs.com, sip-events@egroups.com cc: (Anoop Tripathi/MW/US/3Com) Subject: [SIP] New SUBSCRIBE/NOTIFY draft available For some reason, I haven't seen the I-D action go by for the SUBSCRIBE/NOTIFY draft yet. Thanks to everyone who gave input while I was putting this together. Further comments are very welcome. If comments warrant and time permits, I may well release a -02 version of this draft in time for the 49th IETF meeting. --------------------------------------------------------------------------- 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 occurred. 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-01.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 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Oct 26 10:17:09 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA17794 for ; Thu, 26 Oct 2000 10:17:09 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id DFCE044378; Thu, 26 Oct 2000 09:02:23 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lists.bell-labs.com (Postfix) with ESMTP id B884044336 for ; Wed, 25 Oct 2000 11:58:34 -0400 (EDT) Received: from ms.uab.ericsson.se (ms.uab.ericsson.se [134.138.201.16]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id e9PGwRt18439 for ; Wed, 25 Oct 2000 18:58:27 +0200 (MEST) Received: from uabx04c384.uab.ericsson.se.uab.ericsson.se (uabx04c384 [134.138.229.144]) by ms.uab.ericsson.se (8.10.0/8.10.0/uab-2.26) with ESMTP id e9PGwRn10354 for ; Wed, 25 Oct 2000 18:58:27 +0200 (MET DST) Received: from uab.ericsson.se by uabx04c384.uab.ericsson.se.uab.ericsson.se (8.8.7/client-1.3uab1) id SAA09712; Wed, 25 Oct 2000 18:58:22 +0200 (MET DST) Message-ID: <39F71129.15B5A424@uab.ericsson.se> From: Bertil Engelholm Organization: Ericsson Utvecklings AB X-Mailer: Mozilla 4.74C-CCK-MCD [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: sv,en-US MIME-Version: 1.0 To: sip@lists.bell-labs.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] Transaction Identification, once again Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 25 Oct 2000 18:58:17 +0200 Content-Transfer-Encoding: 7bit Hi again, I'm sorry to bring this up again but I just can't get things to work in the correct way. I have read through the old threads regarding this matter and still don't understand how it is suppose to work. It's this example again : --------- -------- -------- | a@c1 | -- INV u1@p1 --> | (s1) | -- INV u2@p2 --> | | --------- (contact a@c1) | | | | | p1 | | p2 | --------- | | | | | b@c2 | <- INV b@c2 ---- | (s2) | <- INV u3@p1 --- | | --------- -------- -------- If P1 is stateful it might allocate one "call" state machine for each path the "call" takes in P1 (s1 and s2 in the picture). These two state machines are identified by the REQUEST-URI that came in the two INVITEs since that's the only thing that differs the two from each other. (topmost VIA also differs, more about that later) P1 will now include the REQUEST-URI in the branch value it generates so that the responses can be directed to the right state machine when they arrive. And when the ACK is sent the original REQUEST-URI from ROUTE is used. So no problems here. The problem I have is when b@C2 sends a new request (eg. BYE). According to the specification b should/must/may (or whatever) overwrite the REQUEST-URI in the ROUTE headers using the REQUEST-URI from CONTACT or FROM. So how should P1 now be able to differ the two (BYE) requests from each other ? The Original REQUEST-URI was the only thing that P1 had to identify the two state machines. When reading the old threads regarding this matter I saw something about using topmost VIA in some way, but how ? By using the topmost VIA you can see that they are two different requests but how do you identify which state machine should receive the first request. (Someone might argue that it doesn't matter but if P1 controls a firewall it DO matter. Maybe not for BYE but for a RE-INVITE it matters). -- Bertil Engelholm AXE Research and Development voice : +46 8 727 3499 SIP Security Fax : +46 8 647 8276 S-126 25 Stockholm Sweden E-mail: Bertil.Engelholm@uab.ericsson.se _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Oct 26 10:26:17 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA19769 for ; Thu, 26 Oct 2000 10:26:17 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A5A854437D; Thu, 26 Oct 2000 09:02:32 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from topaz.3com.com (topaz.3com.com [192.156.136.158]) by lists.bell-labs.com (Postfix) with ESMTP id E405C44336 for ; Wed, 25 Oct 2000 14:50:24 -0400 (EDT) Received: from opal.3com.com (opal.3com.com [139.87.50.117]) by topaz.3com.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id e9PJniT21092; Wed, 25 Oct 2000 12:49:44 -0700 (PDT) Received: from hqoutbound.ops.3com.com (hqoutbound.OPS.3Com.COM [139.87.48.104]) by opal.3com.com (Switch-2.0.1/Switch-2.0.1) with SMTP id e9PJoHT17057; Wed, 25 Oct 2000 12:50:17 -0700 (PDT) Received: by hqoutbound.ops.3com.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 88256983.006D2ADB ; Wed, 25 Oct 2000 12:52:23 -0700 X-Lotus-FromDomain: 3COM From: Anoop_Tripathi@3com.com To: "Adam B. Roach" Cc: sip@lists.bell-labs.com, sip-events@egroups.com Message-ID: <88256983.006D281F.00@hqoutbound.ops.3com.com> Subject: Re: [SIP] New SUBSCRIBE/NOTIFY draft available Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 25 Oct 2000 14:49:57 -0500 Hi Adam, Few comments : What is the difference between registering (REGISTER) for an event and subscribing (SUBSCRIBE) to an event? I REGISTER to a proxy server to receive INVITE for my calls or do I SUBSCRIBE to my proxy server to NOTIFY me of my calls. I see myself registering to receive invites to calls, receive voice mail notifications, and other notifications and similarly I see myself subscribing to these things also. All messages can be combined into one message and similary all headers can be broken into different messages. INFO method I can see used for carrying various informational messages during a call. All what I am trying to say is did we give enough thoughts in this case whether a header would suffice or a new message is required. As you mentioned it is a fine line between whether a new message or a new header is suitable. Did we do go through the process of deciding whether a new header is more suitable than a new message in case of SUBSCRIBE? If not, should we do that or not. The reason why I ask this question is if tomorrow I come up with a new concept what would be the deciding factors for enhancing REGISTER,SUBSCRIBE or adding a new method. Just like we teardown a session with a BYE method. Can we also teardown subscriptions using BYE/NOTIFY method. Thanks, Anoop "Adam B. Roach" on 10/25/2000 12:21:00 PM Sent by: "Adam B. Roach" To: Anoop Tripathi/MW/US/3Com cc: sip@lists.bell-labs.com, sip-events@egroups.com Subject: Re: [SIP] New SUBSCRIBE/NOTIFY draft available > Was using a header in INVITE/REGISTER requests as a replacement of SUBSCRIBE > request considered? No, this didn't come up as a suggestion so far. The SUBSCRIBE method dates back to February of 1998 (in spirit, at least), and has been incorporated into PINT and the "SIP for Presence" work. The intent of my draft was to provide a framework which allows multiple uses of the SUBSCRIBE and NOTIFY methods in such a way that the different uses didn't get in the way of each other. Using any method other than "SUBSCRIBE" would leave the current drafts somewhat orphaned. > So far I could only see two cases of using SUBSCRIBE. One > during call. In that case we could send the subscribe information in > INVITE/RE-INVITE requests. Second as part of registration. You register to > Proxy, Voice-mail server etc and subscribe to events. So what is the > motivation behind having a separate request? The short answer is: the same reason "INFO" isn't defined as "BYE" with a "Just-Kidding:" header. "SUBSCRIBE" isn't what "INVITE" means, in any remote sense; neither is it what "REGISTER" is intended to mean. It has been pointed out that all methods could be generalised to one method (e.g. replace "BYE" with "INVITE" and a special header indicating that you are inviting the other party to end the current session.) Defining such a system would be quite easy. It would also be patently ridiculous. Since asyncronous event subscription is a distinct action which has no ties to any of the other defined or proposed actions, it seems reasonable to define a new method. > By defining SUBSCRIBE/NOTIFY requests are we trying to achieve the similar > functionality that exists in MEGACO/H.248. Not really. the H.248 event notification, as I understand it, is more appropriate for terminal/endpoint events (e.g. hookflash, digit collection, etc). The SIP event notification has so far been proposed for tasks such as call status, user presence, and message waiting indication. > Is DTMF digit collection a valid usage of this scheme? That's a religious issue. Search your own soul and figure out what's true for you. If you want to read evangelical screeds on both sides of the issue, check the SIP working group mailing list archives. -- 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 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Oct 26 10:31:42 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA20964 for ; Thu, 26 Oct 2000 10:31:42 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C7D8044382; Thu, 26 Oct 2000 09:02:40 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id A676544336 for ; Wed, 25 Oct 2000 21:10:09 -0400 (EDT) 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 WAA15545 for ; Wed, 25 Oct 2000 22:10:03 -0400 (EDT) Message-ID: <39F7927C.1E4791D3@cs.columbia.edu> From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] Some brief comments on the SIP MIB Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 25 Oct 2000 22:10:04 -0400 Content-Transfer-Encoding: 7bit - The Hide configuration options are redundant; obviously, they are in RFC 2543, but I don't think it's useful to carry them forward. - All systems need to understand compact form, so I'm not sure why this is a variable. - ULS should probably at least mention LDAP as an example. - Supported URIs should probably say URI "schemes" rather than just URIs, as the current text can be read to imply to list all user SIP URIs managed by the server. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Oct 26 10:35:41 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA21829 for ; Thu, 26 Oct 2000 10:35:41 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5A4E744388; Thu, 26 Oct 2000 09:02:51 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by lists.bell-labs.com (Postfix) with ESMTP id 63E604433D for ; Thu, 26 Oct 2000 05:27:29 -0400 (EDT) Received: from mr5.exu.ericsson.se (mr5u3.ericy.com [208.237.135.124]) by imr1.ericy.com (8.9.3/8.9.3) with ESMTP id FAA21561; Thu, 26 Oct 2000 05:27:03 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr5.exu.ericsson.se (8.10.2/8.10.2) with ESMTP id e9QAPFk21555; Thu, 26 Oct 2000 05:25:15 -0500 (CDT) Received: from ericsson.com (kipe41.eraj.ericsson.se [147.214.68.41]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id FAA11554; Thu, 26 Oct 2000 05:27:00 -0500 (CDT) Message-ID: <39F806EF.22084F40@ericsson.com> From: Sean Olson Organization: Ericsson Inc. X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: "Vijay K. Gurbani" , "'Piotr S. Kossowski'" , sip@lists.bell-labs.com Subject: Re: [SIP] Multi-message UDP datagrams References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 26 Oct 2000 12:26:55 +0200 Content-Transfer-Encoding: 7bit I'm perfectly happy with the removing this from SIP. I was simply stating that the "complexity" of multiple SIP messages in a UDP datagram was not a strong argument against supporting it. Testing, interoperability, lack of utility, etc. ARE good arguments against supporting it. The complexity is comparable to the complexity of supporting TCP (from a parsing point of view). /sean -- Sean Olson Jonathan Rosenberg wrote: > A few comments here. > > First off, on the other thread about new-fangled way to do content-lengths - > no way. As Henning has pointed out, its way too late. Plus, there is proof > points that what we have now works fine. The mechanism is the one used by > both SIP and HTTP, and there are tons of clients and servers, thin and fat, > for both of these, and they work just fine. > > So, we are back to the original issue - should multiple SIP messages per > datagram stay or go. Sean is arguing here that it should stay because its > low hanging fruit. I would argue that "COULD" is different from "SHOULD". > That is, even if this were easy, if there is no reason or need, its not > worth it. Its simply yet-another-thing to test, to interoperate, to cerify > correctness, and to worry about. So, I would argue that it should stay only > if someone can give a good reason why it should. > > The only mention of a reason to date has been to save overhead. This, > however, is a bogus argument. The overhead of the UDP/IP headers compared to > the size of the SIP message is tiny. Multiple messages in one datagram has > an almost negligible savings for the vast majority of messages. Thus, I do > not see this as a valid argument. > > -Jonathan R. > > --- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > > > -----Original Message----- > > From: Sean Olson [mailto:sean.olson@ericsson.com] > > Sent: Monday, October 23, 2000 3:31 AM > > To: Vijay K. Gurbani > > Cc: Jonathan Rosenberg; 'Piotr S. Kossowski'; sip@lists.bell-labs.com > > Subject: Re: [SIP] Multi-message UDP datagrams > > > > > > I would strongly disagree with the complexity issue. You need > > to know where the > > end of a > > SIP message is. What happens if you receive garbage at the > > end of a UDP datagram? > > If you are going to take the time to deal with > > Content-Length: or multipart/*, > > then you've > > gone 99% of the way to supporting multiple messages in a > > single UDP datagram. > > Easy cheesy! This is not that complex. I would remove line > > folding before I > > messed > > with this. (Not that I'm suggesting we do this) > > > > -- > > Sean Olson > > > > "Vijay K. Gurbani" wrote: > > > > > Jonathan Rosenberg wrote: > > > > > > > > It was my view that receiving multiple messages in a > > single datagram was the > > > > same as if they were received in separate datagrams. In > > other words, there > > > > was no requirements for ordering or completion. The > > result of that was a > > > > simplification in the implementation of handling this > > case; UDP works just > > > > like TCP. Imposing transactional requirements adds > > significant burden. I'd > > > > rather not do that unless there was serious requirements > > or needs here. > > > > > > > > In fact, I would argue that multiple messages per > > datagram might be > > > > something to consider for removal. I've never seen it > > used. I'm not sure > > > > what the benefit is, in reality. There is little byte > > savings, and its just > > > > more complexity that is really needless. > > > > > > > > Lets simplify, not complicate. > > > [...] > > > > > > For whatever it is worth, I agree. In the bakeoff scenarios, I have > > > never > > > seen a SIP entity send multiple messages in the same datagram. > > > > > > Regards, > > > > > > - vijay > > > -- > > > Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} > > > Internet Software/IN Architecture Group > > > Lucent Technologies/Bell Labs Innovations 263 Shuman Blvd., > > Rm 1A-413 > > > Naperville, Illinois 60566 Voice: +1 630 224 0216 > > Fax: +1 630 713 > > > 0184 > > > > > > _______________________________________________ > > > SIP mailing list > > > SIP@lists.bell-labs.com > > > http://lists.bell-labs.com/mailman/listinfo/sip > > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Oct 26 10:43:16 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA23520 for ; Thu, 26 Oct 2000 10:43:16 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 18B804437C; Thu, 26 Oct 2000 09:28:06 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lists.bell-labs.com (Postfix) with ESMTP id 48B344436B for ; Thu, 26 Oct 2000 09:27:51 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id e9QERbZ06212; Thu, 26 Oct 2000 16:27:37 +0200 (MEST) Received: from lmf.ericsson.se (E005004B57CE1.lmf.ericsson.se [131.160.30.156]) by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id RAA05440; Thu, 26 Oct 2000 17:27:31 +0300 (EET DST) Message-ID: <39F83F4F.639D2BDB@lmf.ericsson.se> 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: William Marshall Cc: sip@lists.bell-labs.com, jdrosen@dynamicsoft.com Subject: Re: FW: [SIP] Feedback on manyfolks References: <200010261401.KAA29548@fish-ha.research.att.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 26 Oct 2000 17:27:27 +0300 Content-Transfer-Encoding: 7bit Hi, Bill writes: > So before considering this discussion closed, let me ask whether there > is an application where the single-COMET decision can't be made by the UAS? In some situations the UAC wants the UAS to "wait" until there is a COMET (UAC->UAS). This decision MUST be done by the UAC because the UAS does not have a clue about this need. You can find an example in http://search.ietf.org/internet-drafts/draft-camarillo-3pcc-qos-00.txt We have A, a transcoder and B. The media path will traverse the transcoder. The presence of a transcoder is transparent to B. The SDP of the INVITE from A to B contains the IP address of the transcoder. Thus, even when the QoS is granted in the transcoder-B leg, there is a need for QoS in the other leg (transcoder-A). B is completely unaware of this, so it is A (the UAC) the one that MUST require a COMET from UAC to UAS. This way, it can perform resource reservation between A and the transcoder and then send the COMET to B (that will resume session establishment). Note that in this example I use 2 COMETs between A and B, but actually COMET from B to A is not needed for anything. However, in the other leg (transcoder-A), 2 COMETs are needed. This illustrates that the UAC always has the information about how many COMETs are needed. OK, now, let me re-write my suggestion (it appears already in my previous mail): My suggestion is: UAC sends result comet sendrecv 2 COMETs, UAS->UAC, then UAC->UAS comet send 1 COMET, UAC->UAS 0 COMETs This mechanism includes all the comments received in this thread so far: 1) It is simple, because there is no negotiation of how many COMETs have to be sent. The UAC makes the decision and the UAS obeys. Question: Do you have any situation where the UAS would like to change the decision made by the UAC regarding the number of COMETs sent? I cannot think of any useful scenario. 2) It saves one RTT in the most common situation (just one COMET UAC->UAS). 3) The syntax is really "human readable". Direction tags are very easy to interpret. Even easier when they are already used in the a=QoS line. Do you have any objection against this approach? Practically this is the same mechanism described by Jonathan (where the UAC also makes the decision). I have just added the posibility of just one COMET (for saving bandwidth basically). Thanks, Best regards, Gonzalo -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland http://www.hut.fi/~gonzalo _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Oct 26 10:47:56 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA24504 for ; Thu, 26 Oct 2000 10:47:56 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id ABD01443A2; Thu, 26 Oct 2000 09:36:06 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 4A3FB44342 for ; Thu, 26 Oct 2000 09:00:31 -0400 (EDT) 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 KAA23165; Thu, 26 Oct 2000 10:00:24 -0400 (EDT) Message-ID: <39F838F8.886699A0@cs.columbia.edu> From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Multi-message UDP datagrams References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 26 Oct 2000 10:00:24 -0400 Content-Transfer-Encoding: 7bit I agree. It is also one of those features where bugs are hard to catch. For example, one could easily get into a situation where the receiver ignores the second request in a packet, causing a retransmission as a single-request-per-UDP packet. This "works", but now every request generates two packets. Having one request or message per UDP packet is also by far the dominant mode of operation for Internet protocols. I'm not aware of any protocol that doesn't follow this basic operational rule. Remember that we will have to find and test two independent interoperable implementation for every feature to progress SIP to Draft Standard. The more features, the longer this will take. Maybe we should institute a rule that every individual or organization that proposes a new feature will take it upon them to make this effort of finding and documenting interoperability. Indeed, it would be very nice if somebody or some group of volunteers could step forward to gather a feature check list and make this available during the bake-offs (bake-off is a registered trademark of the Pillsbury company and used here without permission). For systems with lots of messages exchanged, it is probably better to use TCP or SCTP, as that provides faster loss recovery for high-rate streams and, with TLS, easier security. I doubt that implementations will actually go through the trouble of gathering up messages for joint delivery, with all the timer hassles that implies. Jonathan Rosenberg wrote: > > A few comments here. > > First off, on the other thread about new-fangled way to do content-lengths - > no way. As Henning has pointed out, its way too late. Plus, there is proof > points that what we have now works fine. The mechanism is the one used by > both SIP and HTTP, and there are tons of clients and servers, thin and fat, > for both of these, and they work just fine. > > So, we are back to the original issue - should multiple SIP messages per > datagram stay or go. Sean is arguing here that it should stay because its > low hanging fruit. I would argue that "COULD" is different from "SHOULD". > That is, even if this were easy, if there is no reason or need, its not > worth it. Its simply yet-another-thing to test, to interoperate, to cerify > correctness, and to worry about. So, I would argue that it should stay only > if someone can give a good reason why it should. > > The only mention of a reason to date has been to save overhead. This, > however, is a bogus argument. The overhead of the UDP/IP headers compared to > the size of the SIP message is tiny. Multiple messages in one datagram has > an almost negligible savings for the vast majority of messages. Thus, I do > not see this as a valid argument. > -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Oct 26 10:51:06 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA25229 for ; Thu, 26 Oct 2000 10:51:06 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1135B4438C; Thu, 26 Oct 2000 09:02:59 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lists.bell-labs.com (Postfix) with ESMTP id 46BFA4435E for ; Thu, 26 Oct 2000 05:47:17 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16225; Thu, 26 Oct 2000 06:47:02 -0400 (EDT) Message-Id: <200010261047.GAA16225@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@lists.bell-labs.com From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: [SIP] I-D ACTION:draft-ietf-sip-isup-mime-05.txt Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 26 Oct 2000 06:47:02 -0400 --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 : MIME media types for ISUP and QSIG Objects Author(s) : E. Zimmerer, J. Peterson, A. Vemuri, L. Ong, M. Watson, M. Zonoun Filename : draft-ietf-sip-isup-mime-05.txt Pages : 7 Date : 25-Oct-00 This document describes MIME types for application/ISUP and application/QSIG objects for use in SIP applications, according to the rules defined in RFC 2048 [1]. These types can be used to identify ISUP and QSIG objects within a SIP message such as INVITE or INFO, as might be implemented when using SIP between legacy systems. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-isup-mime-05.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-isup-mime-05.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-isup-mime-05.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: <20001025095743.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-isup-mime-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-isup-mime-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001025095743.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Oct 26 11:46:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA07574 for ; Thu, 26 Oct 2000 11:46:02 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6A27544337; Thu, 26 Oct 2000 10:46:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from pentagon.cisco.com (pentagon.cisco.com [161.44.199.141]) by lists.bell-labs.com (Postfix) with ESMTP id A24B144336 for ; Thu, 26 Oct 2000 10:45:28 -0400 (EDT) Received: from cia.cisco.com (mirapoint@cia.cisco.com [161.44.199.157]) by pentagon.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA16208; Thu, 26 Oct 2000 11:45:18 -0400 (EDT) Received: from mhammer-nt.cisco.com (va-dhcp198-137.cisco.com [161.44.198.137]) by cia.cisco.com (Mirapoint) with ESMTP id ADH00875; Thu, 26 Oct 2000 11:45:17 -0400 (EDT) Message-Id: <4.3.2.7.2.20001026113610.00adcb50@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Anoop_Tripathi@3com.com, "Adam B. Roach" From: hammer michael Subject: Re: [SIP] New SUBSCRIBE/NOTIFY draft available Cc: sip@lists.bell-labs.com, sip-events@egroups.com In-Reply-To: <88256983.006D281F.00@hqoutbound.ops.3com.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 26 Oct 2000 11:50:31 -0700 My initial impression (I need to study in detail) was that these methods could be both session (call) associated and non-session (non-call) associated. Thus they may exist outside the scope of any session defined by event between INVITE and BYE, and could in fact span multiple sessions. Like subscription to mail-lists, they exist longer than any given thread of messages. I would suspect that the intent to communicate for a specific purpose could be registered, and if able to be discovered, could be subscribed to by those virtually wandering by. I assume that the purposes would be addressed in the message body and addressed by the IMPP folks. What is not clear to me is that assuming that someone has registered their presence, and another is interested in subscribing/initiating communications to that person, and the former's identity is not already known in some form to the latter, how does the latter search/browse to find the former? Is this assumed to be a directory operation outside the scope of SIP and IMPP? Mike At 02:49 PM 10/25/2000 -0500, Anoop_Tripathi@3com.com wrote: >Hi Adam, > >Few comments : > > What is the difference between registering (REGISTER) for an event and > subscribing (SUBSCRIBE) to an event? > I REGISTER to a proxy server to receive INVITE for my calls or do I >SUBSCRIBE to my proxy server to NOTIFY me of my calls. > I see myself registering to receive invites to calls, receive > voice mail >notifications, and other notifications and similarly I see myself >subscribing to >these things also. > > All messages can be combined into one message and similary all headers > can be > broken into different messages. > INFO method I can see used for carrying various informational messages >during a call. > All what I am trying to say is did we give enough thoughts in this > case >whether a header would suffice or a new message is required. > > As you mentioned it is a fine line between whether a new message or a new > header is suitable. > Did we do go through the process of deciding whether a new header > is more >suitable than a new message in case of SUBSCRIBE? > If not, should we do that or not. > > The reason why I ask this question is if tomorrow I come up with a new > concept what would be the deciding factors for enhancing > REGISTER,SUBSCRIBE > or adding a new method. > > Just like we teardown a session with a BYE method. Can we also teardown > subscriptions using BYE/NOTIFY method. > >Thanks, > >Anoop > > > > > >"Adam B. Roach" on 10/25/2000 12:21:00 PM > >Sent by: "Adam B. Roach" > > >To: Anoop Tripathi/MW/US/3Com >cc: sip@lists.bell-labs.com, sip-events@egroups.com >Subject: Re: [SIP] New SUBSCRIBE/NOTIFY draft available > > > > > Was using a header in INVITE/REGISTER requests as a replacement of > SUBSCRIBE > > request considered? > >No, this didn't come up as a suggestion so far. The SUBSCRIBE method >dates back to February of 1998 (in spirit, at least), and has been >incorporated into PINT and the "SIP for Presence" work. The intent >of my draft was to provide a framework which allows multiple uses >of the SUBSCRIBE and NOTIFY methods in such a way that the different >uses didn't get in the way of each other. Using any method other >than "SUBSCRIBE" would leave the current drafts somewhat orphaned. > > > So far I could only see two cases of using SUBSCRIBE. One > > during call. In that case we could send the subscribe information in > > INVITE/RE-INVITE requests. Second as part of registration. You > register to > > Proxy, Voice-mail server etc and subscribe to events. So what is the > > motivation behind having a separate request? > >The short answer is: the same reason "INFO" isn't defined as "BYE" with >a "Just-Kidding:" header. > >"SUBSCRIBE" isn't what "INVITE" means, in any remote sense; neither is >it what "REGISTER" is intended to mean. It has been pointed out that >all methods could be generalised to one method (e.g. replace "BYE" >with "INVITE" and a special header indicating that you are inviting >the other party to end the current session.) > >Defining such a system would be quite easy. It would also be patently >ridiculous. > >Since asyncronous event subscription is a distinct action which has >no ties to any of the other defined or proposed actions, it seems >reasonable to define a new method. > > > By defining SUBSCRIBE/NOTIFY requests are we trying to achieve the > similar > > functionality that exists in MEGACO/H.248. > >Not really. the H.248 event notification, as I understand it, is >more appropriate for terminal/endpoint events (e.g. hookflash, >digit collection, etc). The SIP event notification has so far >been proposed for tasks such as call status, user presence, >and message waiting indication. > > > Is DTMF digit collection a valid usage of this scheme? > >That's a religious issue. Search your own soul and figure out >what's true for you. If you want to read evangelical screeds on >both sides of the issue, check the SIP working group mailing >list archives. > >-- >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 > > > > > >_______________________________________________ >SIP mailing list >SIP@lists.bell-labs.com >http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Oct 26 12:02:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA11229 for ; Thu, 26 Oct 2000 12:02:02 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 913254433F; Thu, 26 Oct 2000 11:02:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cvis29.marconicomms.com (cvis29.marconicomms.com [195.99.244.61]) by lists.bell-labs.com (Postfix) with ESMTP id 883D94433D for ; Thu, 26 Oct 2000 11:01:58 -0400 (EDT) Received: from cvis01.gpt.co.uk (unverified) by cvis29.marconicomms.com (Content Technologies SMTPRS 4.1.5) with ESMTP id ; Thu, 26 Oct 2000 17:01:49 +0100 Received: from marconicomms.com by cvis01.gpt.co.uk with SMTP (8.8.8+Sun/cvms-28) id RAA16920; Thu, 26 Oct 2000 17:01:47 +0100 (BST) Received: by marconicomms.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 80256984.0057FF49 ; Thu, 26 Oct 2000 17:01:09 +0100 X-Lotus-FromDomain: MCMAIN@MCEXT From: "Keith Robinson" To: Jonathan Rosenberg Cc: "'Christer Holmberg'" , sip@lists.bell-labs.com, Igor Slepchin , sean.olson@ericsson.com Message-ID: <80256984.0057FEC8.00@marconicomms.com> Subject: RE: [SIP] Redirect server returning new From header Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 26 Oct 2000 17:01:14 +0100 With respect to the issue of delivering a calling line identity from a SIP user into the PSTN, consider the following. A SIP user wishes to be globally reachable; as this means he has to be reachable from a POTS subscriber in the PSTN who can only dial digits it follows that the SIP user must also be known by a dialled digit string. Therefore, the association of the SIP users URL and the dialled digit string to reach this URL must be fixed so therefore verifiable; if this were not the case then calls from the PSTN into SIP networks could not happen. If the association of a SIP URL to a dialled digit string is required to support calls from the PSTN into a SIP network, it is not unreasonable for this same digit string to be delivered when making calls from the SIP network into the PSTN. The UAC should not be allowed to supply the CLI; rather it is supplied by the network to which he is connected and it is the responsibility of the network to ensure that the person is who he says he is (verify FROM:) and ensure that the correct CLI is delivered. Regards, K. Robinson Jonathan Rosenberg on 26/10/2000 11:39:04 To: "'Christer Holmberg'" , sip@lists.bell-labs.com cc: Igor Slepchin , sean.olson@ericsson.com(bcc: Keith Robinson/MAIN/MC1) Subject: RE: [SIP] Redirect server returning new From header I thought we had put this issue to bed. As Henning pointed out previously, allowing a UAC to insert a telephone number into a request, which is then passed to the PSTN (via a gateway) as the originating number, is a recipe for a security disaster. Nothing stops me from inserting fake telephone numbers, and calling people pretending to be someone else. You can expect a call from the FCC about that one. So, in fact, this proposed used of the Also-From header is, in practice, unusable without a massive security/PKI infrastructure which really doesn't exist (you would need someone to certify that joe@foo.com owns the number 555-1212. I don't even know who would be able to adequately certify this, and I suspect no CA in their right mind would ever put this in a certificate). So, by corollary, having a proxy tell a UA what number it owns is even more of a security nightmare, and even less likely to ever work. Thus, the mechanics of how best to accomplish it are moot. Perhaps I sound harsh, but I am trying really hard to push back on everyones "lets add X to SIP" request. SIP is already an RFC, folks. We are obliged to carefully scrutinize everything that gets added, and only put things in when they are truly needed, broadly useful, and backwards compatible. This Also-From thing has only one proposed application, which is interoperation with the PSTN, and in this application is frought with serious security issues. -Jonathan R. > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > Sent: Wednesday, October 25, 2000 1:47 AM > To: sip@lists.bell-labs.com > Cc: Igor Slepchin; sean.olson@ericsson.com > Subject: Re: [SIP] Redirect server returning new From header > > > > Hi, > > >You can use URL headers to specify SIP message headers, > e.g., the Contact >in the 302 may look like > > > >Contact: sip:chirster@ericsson?from=tel:12345 > > > >It's then up to the UAC to trust your redirect server and > overwrite its > >default From header. See section 2 of 2543bis for details. > > True, but in this case the redirect server (what I mean by that is > actually any SIP node, server or UA, with redirect functionality...) > will not know if the UAC is going to use the new header or > not. For some > reason, the redirect server may behave in different ways > (maybe, in some > case, it won't even allow the UAC to contact a certain host if the > feature is not supported...) depending on if it can give the UAC a new > From header or not. > > But, if we have a new header for this, the UAC can indicate in the > Supported header that it supports this feature. Then, the redirect > server can add the new "Also-From" header in the response, > and indicate > in the Require header that the UAC must use it. Maybe this is possible > also in the case where you just add it to the Contact header, > but in any > case I think you would have to define a new Supported/Require > tag value > (?) --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Oct 26 13:03:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA23812 for ; Thu, 26 Oct 2000 13:03:02 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 28B3144337; Thu, 26 Oct 2000 12:03:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103]) by lists.bell-labs.com (Postfix) with ESMTP id 6DDEA44336 for ; Thu, 26 Oct 2000 12:02:06 -0400 (EDT) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id 933581E01D; Thu, 26 Oct 2000 13:02:01 -0400 (EDT) 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 NAA04465; Thu, 26 Oct 2000 13:01:58 -0400 (EDT) From: William Marshall Received: (from wtm@localhost) by fish-ha.research.att.com (980427.SGI.8.8.8/8.8.5) id NAA33983; Thu, 26 Oct 2000 13:01:58 -0400 (EDT) Message-Id: <200010261701.NAA33983@fish-ha.research.att.com> To: gonzalo.camarillo@lmf.ericsson.se Cc: jdrosen@dynamicsoft.com, sip@lists.bell-labs.com Subject: Re: FW: [SIP] Feedback on manyfolks Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 26 Oct 2000 13:01:58 -0400 (EDT) Gonzalo writes: > In some situations the UAC wants the UAS to "wait" until there is a > COMET (UAC->UAS). This decision MUST be done by the UAC because the UAS > does not have a clue about this need. > > You can find an example in > http://search.ietf.org/internet-drafts/draft-camarillo-3pcc-qos-00.txt > > We have A, a transcoder and B. The media path will traverse the > transcoder. > > The presence of a transcoder is transparent to B. The SDP of the INVITE > from A to B contains the IP address of the transcoder. Thus, even when > the QoS is granted in the transcoder-B leg, there is a need for QoS in > the other leg (transcoder-A). B is completely unaware of this, so it is > A (the UAC) the one that MUST require a COMET from UAC to UAS. > This way, it can perform resource reservation between A and the > transcoder and then send the COMET to B (that will resume session > establishment). > > Note that in this example I use 2 COMETs between A and B, but actually > COMET from B to A is not needed for anything. > > However, in the other leg (transcoder-A), 2 COMETs are needed. > > This illustrates that the UAC always has the information about how many > COMETs are needed. > I've gone through 3pcc-qos-00 (and also manyfolks-confirm-00, which repeats the first example from 3pcc-qos-00), and believe we already have all the cases covered. In the simple third-party-call-control case, the controller uses the "confirm" in the SDP sent with the INVITE, which causes a two-way COMET. The second example in 3pcc-qos-00 consists of a simple call from A to the transcoder, T, followed by A acting as a third-party-controller to establish a call from T to B. The second half of this example is covered by the previous. For the simple call from A to T, A inserts the SDP line a=qos:mandatory sendrecv" which T is willing to accept. But T can't do the send&recv QoS itself - it needs help from A for the A->T direction. (Note that T doesn't know whether A will be using RSVP, so it can't depend on using a RESV-CONF to do this trick). Therefore it needs to ask for the confirmation; without it T would be proceeding with the session establishment without fulfilling the preconditions. So it asks for the confirmation in the 183 response. Consider the case where T implements some other (i.e. non-RSVP) resource reservation protocol. If it can somehow get send&recv QoS from A to T by itself, then it can locally determine that it has met the preconditions. In this case there is no need for the COMET, and giving A the capability to demand one actually increases the call setup delay. > OK, now, let me re-write my suggestion (it appears already in my > previous mail): > My suggestion is: > UAC sends result > comet sendrecv 2 COMETs, UAS->UAC, then UAC->UAS > comet send 1 COMET, UAC->UAS > 0 COMETs > > This mechanism includes all the comments received in this thread so far: > 1) It is simple, because there is no negotiation of how many COMETs have > to be sent. The UAC makes the decision and the UAS obeys. > > Question: Do you have any situation where the UAS would like to change > the decision made by the UAC regarding the number of COMETs sent? I > cannot think of any useful scenario. If we consider that there are reservation protocols other than RSVP, and in particular ones that can make bi-directional reservations, then the UAS would be in a better position to decide the proper number of COMETs than the UAC. > > 2) It saves one RTT in the most common situation (just one COMET > UAC->UAS). > > 3) The syntax is really "human readable". Direction tags are very easy > to interpret. Even easier when they are already used in the a=QoS line. > > > Do you have any objection against this approach? > > Practically this is the same mechanism described by Jonathan (where the > UAC also makes the decision). I have just added the posibility of just > one COMET (for saving bandwidth basically). > My only real objection to this approach is that it duplicates a facility already provided in the manyfolks procedures, and I see no reason to require two ways to force the same behavior. A secondary objection (relatively minor) is that I always get confused when we use the terms "send" and "recv" between two parties that both "send" and "recv"; a "send" interpreted by one party is the "recv" of the other. Note that table 1 of section 4.2 of the current manyfolks draft has a glaring error due to the confusion, and this mistake has appeared in three versions before being caught. Bill Marshall wtm@research.att.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Oct 26 14:10:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA01814 for ; Thu, 26 Oct 2000 14:10:04 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8AF4E44337; Thu, 26 Oct 2000 13:10:06 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from pentagon.cisco.com (pentagon.cisco.com [161.44.199.141]) by lists.bell-labs.com (Postfix) with ESMTP id A0BD944336 for ; Thu, 26 Oct 2000 13:09:49 -0400 (EDT) Received: from cia.cisco.com (mirapoint@cia.cisco.com [161.44.199.157]) by pentagon.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA18410; Thu, 26 Oct 2000 14:09:42 -0400 (EDT) Received: from mhammer-nt.cisco.com (va-dhcp198-137.cisco.com [161.44.198.137]) by cia.cisco.com (Mirapoint) with ESMTP id ADH03085; Thu, 26 Oct 2000 14:09:41 -0400 (EDT) Message-Id: <4.3.2.7.2.20001026135909.00b373f0@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Adam B. Roach" , sip@lists.bell-labs.com, sip-events@egroups.com From: hammer michael Subject: Re: [SIP] New SUBSCRIBE/NOTIFY draft available In-Reply-To: <200010251557.KAA07949@b04a24.exu.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 26 Oct 2000 14:14:55 -0700 A couple minor comments: Sec 5.1.5, assume "must" = "MUST" Sec 5.1.6, para 7: Would immediate fetch while subscription pending be some type of 18x response? Sec 5.1.6, para 8: Implies that one must subscribe before one can subscribe, seems recursive. Could one assume that the resource to which one would be subscribing would have already registered and that the registration would have already defined the basis for access, e.g. restricted list or promiscuous (open to anyone)? Sec. 5.2.2, para 8: If the assumption is that configuration is done out of band, why not assume that the subscribe will be static provisioned and would therefore submit the SUBSCRIBE before the NOTIFY. That could obviate the need for Notify without Subscription. Sec 5.2.3: Could repeated non-ACK of Notifies be used before cancelling a subscription. It seems the subscription would be rather fragile under unreliable network conditions. That might be rather service-dependant. I would not want a long-running subscription to a non-call-related service to terminate just because I turned my computer off. In mobile environments, one could think of other cases where communications may be interrupted. Mike At 10:57 AM 10/25/2000 -0500, Adam B. Roach wrote: >For some reason, I haven't seen the I-D action go by for >the SUBSCRIBE/NOTIFY draft yet. Thanks to everyone who gave >input while I was putting this together. Further comments are >very welcome. If comments warrant and time permits, I may well >release a -02 version of this draft in time for the 49th >IETF meeting. > >--------------------------------------------------------------------------- >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 occurred. > > 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-01.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 > >_______________________________________________ >SIP mailing list >SIP@lists.bell-labs.com >http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Oct 26 14:12:40 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA02126 for ; Thu, 26 Oct 2000 14:12:40 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C00EC4436B; Thu, 26 Oct 2000 13:11:06 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from june.Broomfield1.level3.net (june.Broomfield1.Level3.net [209.245.18.7]) by lists.bell-labs.com (Postfix) with ESMTP id 3AE8B44336 for ; Thu, 26 Oct 2000 13:11:00 -0400 (EDT) Received: from f1ee40-19.idc1.level3.com (hme0.f1ee40-19.idc1.oss.level3.com [10.1.144.204]) by june.Broomfield1.level3.net (8.9.3/8.9.3) with ESMTP id SAA18808; Thu, 26 Oct 2000 18:10:54 GMT From: Aparna.Vemuri@Level3.com Received: from n0195idc1.oss.level3.com (localhost [127.0.0.1]) by f1ee40-19.idc1.level3.com (8.8.8+Sun/8.8.8) with ESMTP id SAA26747; Thu, 26 Oct 2000 18:10:53 GMT Received: by n0195idc1.oss.level3.com with Internet Mail Service (5.5.2650.21) id ; Thu, 26 Oct 2000 12:12:45 -0600 Message-ID: <350829A9DA9FD411841200508BF9F0600AB957@n0217idc1.oss.level3.com> To: andrew_s_duncan@agilent.com, sip@lists.bell-labs.com Subject: RE: [SIP] SIP and SIP-T distinction. MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 26 Oct 2000 12:13:12 -0600 Andy, Please see notes below. Aparna Hi, I realise that SIP-T is not a new protocol specification but simply details the methods, standards and tools necessary to enable MGC's to inter operate via the SIP protocol BUT is there an easy way to distinguish bewteen SIP and SIP-T messages (i.e. messages with encapsulated ISUP as well as SDP). For example, will a SIP-T message have its own SIP-VERSION to go in the request/response header - SIP-T/1.0 ? >>> No. As you yourself state, SIP-T is not a new protocol. No special analysis is required for processing these messages. SIP proxies (and in general, the IP network) do(es) not have to be aware of the fact that the 'signaling is SIP-T '. SIP UAs like MGC UAs and SIP-phones (as defined in the Contexts and Architectures document) are the elements that need to take the necessary measures to handle the ' SIP-T signaling ' (whether accept and generate ISUP or ignore or reject MIME multi-part, etc.) <<< Or is the message body is defined as having CONTENT-TYPE of multipart/mixed can you assume it is a SIP-T message ? I take it this too much to assume as there is no doubt other expansions of SIP that use this MIME format for multiple payloads, or is likely to be so in the future. Also, is it likely that multipart/mixed may just be used to carry the SDP information on its own instead of application/sdp ? >>> A multi-part/mixed payload is NOT sufficient to establish the identity of SIP-T and precisely for the reason you cite. <<< Or is the only way to determine whether there is an ISUP payload is to delve into the message body and look for CONTENT-TYPE application/isup ? Finally, is it also tto much to assume that the SDP payload will always precede the ISUP payload in the message body ? >>> I do not believe there are any rules that specify the order of the payloads. <<< Hopefully, I have not polluted your mailing list with my inane ramblings, but I have scoured your FAQ section and archives to no avail !! Thanks for any help anyone is prepared to give. Andy. ============================ Andrew S Duncan Agilent Technologies Tel: 0131 331 7822 Exten: 32822 Mailstop: SQFR&D3 ============================ _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Oct 26 15:42:11 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA12681 for ; Thu, 26 Oct 2000 15:42:10 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id ECA2D4433E; Thu, 26 Oct 2000 14:42:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mailwall.tti.net (216-86-19-5.caprock.net [216.86.19.5]) by lists.bell-labs.com (Postfix) with ESMTP id DDA354433B for ; Thu, 26 Oct 2000 14:41:48 -0400 (EDT) Received: from mailhost.ttiworld.com (unverified) by mailwall.tti.net (Content Technologies SMTPRS 4.1.2) with ESMTP id for ; Thu, 26 Oct 2000 14:41:42 -0500 Received: by mailhost.ttiworld.com with Internet Mail Service (5.5.2650.21) id ; Thu, 26 Oct 2000 14:41:13 -0500 Message-ID: <69DEAC407D3B6A48AA71F5D09966F7DB397D3B@mailhost.ttiworld.com> From: Kevin Summers To: sip@lists.bell-labs.com Subject: RE: [SIP] I-D ACTION:draft-ietf-sip-isup-mime-05.txt MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 26 Oct 2000 14:41:02 -0500 On page three, Content-Disposition is set to "session" ... was this a typo? It looks as though you've settled on "signal" as the default value here. Are there any other values for this header? Regards, Kevin -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Thursday, October 26, 2000 5:47 AM Cc: sip@lists.bell-labs.com Subject: [SIP] I-D ACTION:draft-ietf-sip-isup-mime-05.txt 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 : MIME media types for ISUP and QSIG Objects Author(s) : E. Zimmerer, J. Peterson, A. Vemuri, L. Ong, M. Watson, M. Zonoun Filename : draft-ietf-sip-isup-mime-05.txt Pages : 7 Date : 25-Oct-00 This document describes MIME types for application/ISUP and application/QSIG objects for use in SIP applications, according to the rules defined in RFC 2048 [1]. These types can be used to identify ISUP and QSIG objects within a SIP message such as INVITE or INFO, as might be implemented when using SIP between legacy systems. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-isup-mime-05.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-isup-mime-05.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-isup-mime-05.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. ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.inip.com ********************************************************************** _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Oct 26 16:11:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA16073 for ; Thu, 26 Oct 2000 16:11:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C5C964434A; Thu, 26 Oct 2000 15:11:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from elektron.elka.pw.edu.pl (elektron.elka.pw.edu.pl [194.29.160.2]) by lists.bell-labs.com (Postfix) with ESMTP id C98D34433B for ; Thu, 26 Oct 2000 15:10:32 -0400 (EDT) Received: from dial-barska11.warman.com.pl ([195.164.232.12]:1949 "EHLO elka.pw.edu.pl") by elektron.elka.pw.edu.pl with ESMTP id ; Thu, 26 Oct 2000 22:10:12 +0200 Message-ID: <39F88E0B.2DF663CF@elka.pw.edu.pl> From: "Piotr S. Kossowski" Organization: Warsaw University of Technology - Institute of Telecommunications X-Mailer: Mozilla 4.7 [pl] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: SIP disscussion list Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Subject: [SIP] possibly unintended recommendation for "tag" in 6.25 of the spec Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 26 Oct 2000 22:03:23 +0200 Content-Transfer-Encoding: 8bit Hello, During my studies on RFC2543bis-02, I've noticed following phrase: section 6.25: " The “tag” value MUST be globally unique and cryptographically random with at least 32 bits of randomness. A single user agent maintains the same tag at least within the same Call-ID, but it is RECOMMENDED to maintain the same tag across calls and instances of the UA application to allow restarting of a user agent. " On the one hand, we want tag to be globally unique to provide matching in case of forking, on the other, this RECOMMENDATION would damage to this tag-mechanism, in my opinion. Why ? As the spec. says, instances of UA should (in recommendation meaning) have the same tag. Let's assume that there are only ten "equal" vendors of SIP-UAs in the world. Eeach of them compiled its UA with cryptographically random tag. According to probability principles, 10% of UAs instances in the world WILL HAVE THE SAME TAG. It is probably NOT what we had on our mind. But, don't argue about numbers. I suppose, that author of this recommendation had on his mind instances in meaning pair: {1.ran executable code 2.host, on which this instance was run}, not {ran executable code} (common meaning). If yes, Such cryptographically random tag would not be fixed in the executable code, but could be computed on the base of data unique for the host instance e.g. hard disk capacity, its volume name, OS id, IP address etc. If It's what was wanted to be said in 6.25, please for acceptation of my inerpretation. To be honest, I would clarify a bit section 6.25 to avoid such emails in the future... :-) Thanks, Piotr _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Oct 26 18:09:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA18850 for ; Thu, 26 Oct 2000 18:09:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6706E4433B; Thu, 26 Oct 2000 17:09:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 47AF944338 for ; Thu, 26 Oct 2000 17:08:34 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id SAA11729; Thu, 26 Oct 2000 18:10:01 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <4WS2YAM6>; Thu, 26 Oct 2000 18:03:47 -0400 Message-ID: From: Igor Slepchin To: Jonathan Rosenberg , "'Baniel Uri-CUB001'" , sip@lists.bell-labs.com Subject: RE: [SIP] Stateful proxy MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 26 Oct 2000 18:03:39 -0400 Actually, proxies are required to retransmit final INVITE responses over TCP (see 10.5.2 in 2543bis). The problem happens in a slightly different scenario: TCP UDP UA1 -------- Proxy --------- UA2 Here, a stateless proxy has TCP on the upstream and UDP on the downstream. Since requests are not retransmitted over TCP, the stateless Proxy will never retransmit the requests over UDP link (Proxy->UA2). --- Igor Slepchin > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Thursday, October 26, 2000 4:41 AM > To: 'Baniel Uri-CUB001'; sip@lists.bell-labs.com > Subject: RE: [SIP] Stateful proxy > > > The situation comes up in a proxy which is TCP on the > downstream side and > UDP in the upstream side: > > UDP TCP > UA1 -------- Proxy --------- UA2 > > Lets assume that this proxy is stateless, meaning that it > holds the TCP > connection state but otherwise does not store transaction > state. According > to the specification, INVITE responses are not retransmitted > over TCP. So, > UA2 sends its non-200 response, say a 400, just once over that TCP > connection. The proxy receives this, and forwards it to UA1. > Its lost. UA2 > will not retransmit (since its TCP), and neither will the > proxy, since its > stateless, thus, the message is lost. > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Oct 26 19:51:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA26223 for ; Thu, 26 Oct 2000 19:51:02 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1B94944343; Thu, 26 Oct 2000 18:51:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mailsrv02.multitude.com (mailsrv02.firetalk.com [204.178.116.251]) by lists.bell-labs.com (Postfix) with ESMTP id 76FF544338 for ; Thu, 26 Oct 2000 18:50:07 -0400 (EDT) Received: from sbarber2k (s242.firetalk.com [204.178.116.242]) by mailsrv02.multitude.com (Rockliffe SMTPRA 3.4.2) with SMTP id for ; Thu, 26 Oct 2000 16:47:45 -0700 From: "Simon Barber" To: Subject: RE: [SIP] Redirect server returning new From header Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_002D_01C03F6D.19EA8940" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 26 Oct 2000 16:52:18 -0700 This is a multi-part message in MIME format. ------=_NextPart_000_002D_01C03F6D.19EA8940 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit > I thought we had put this issue to bed. > > As Henning pointed out previously, allowing a UAC to insert a telephone > number into a request, which is then passed to the PSTN (via a gateway) as > the originating number, is a recipe for a security disaster. Nothing stops > me from inserting fake telephone numbers, and calling people pretending to > be someone else. You can expect a call from the FCC about that one. > > So, in fact, this proposed used of the Also-From header is, in practice, > unusable without a massive security/PKI infrastructure which really doesn't > exist (you would need someone to certify that joe@foo.com owns the number > 555-1212. I don't even know who would be able to adequately certify this, > and I suspect no CA in their right mind would ever put this in a > certificate). This security infrastructure already exists in the current telephone network - although it is implemented in hardware rather than software. Phone companies have a network of trust with each other, and exchange ISUP messages with each other only secure lines setup along these lines of trust. Where signalling is exchanged with an end user (Q.931) checks are made to ensure the user is authorised to send the numbers he sends. A similar trust network is required if we want to have authenticated CLI in SIP. Currently SIP-T does require exactly the same (physical or secure VPN) trust network as regular ISUP telephony. Indeed this is probably one of the main constraining factors that limits whom SIP-T is available to. Your telephone company will be very well positioned to certify that you have the right to present your telephone number. I would suggest that it will be your phone company, or a third party acting on their behalf who will do so. Authenticated CLI in SIP may play a very important part in keeping SIP spamming down. Simon Barber ------=_NextPart_000_002D_01C03F6D.19EA8940 Content-Type: text/x-vcard; name="Simon Barber.vcf" Content-Disposition: attachment; filename="Simon Barber.vcf" Content-Transfer-Encoding: quoted-printable BEGIN:VCARD VERSION:2.1 N:Barber;Simon FN:Simon Barber ORG:Firetalk Communications, Inc. TEL;WORK;VOICE:(650) 636-1924 TEL;CELL;VOICE:(650) 743-1919 ADR;WORK:;;5000 Shoreline Court, Suite 200;South San = Francisco;CA;94080;United States of America LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:5000 Shoreline Court, Suite = 200=3D0D=3D0ASouth San Francisco, CA 94080=3D0D=3D0AUnit=3D ed States of America URL:http://www.firetalk.com URL:http://www.firetalk.com EMAIL;PREF;INTERNET:simon@firetalk.com REV:20000914T193921Z END:VCARD ------=_NextPart_000_002D_01C03F6D.19EA8940-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Oct 26 20:49:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA15421 for ; Thu, 26 Oct 2000 20:49:02 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1763A44356; Thu, 26 Oct 2000 19:49:06 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mail15b.boca15-verio.com (unknown [208.55.91.59]) by lists.bell-labs.com (Postfix) with SMTP id 1D0CA44338 for ; Thu, 26 Oct 2000 19:48:47 -0400 (EDT) Received: from www.snowshore.com (128.241.144.247) by mail15b.boca15-verio.com (RS ver 1.0.58s) with SMTP id 0183701 for ; Thu, 26 Oct 2000 20:48:27 -0400 (EDT) Reply-To: From: "Eric Burger" To: "'SIP discussion list'" Subject: RE: [SIP] Use of notes within the RFC bis draft Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: X-Loop-Detect: 1 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 26 Oct 2000 17:48:10 -0700 Content-Transfer-Encoding: 7bit We're talking about an issue of clarity here. Even though the text "conforms" with RFC 2119, it's by no means clear. For a good example of the use of NOTEs, see the MIME series (RFC 1521-1524). It's very clear what's normative and what's not. Moreover, the NOTEs are truly helpful. By obfuscating what's normative and what's not, one invites various implementations that "conform" with the RFC, yet don't interoperate. I'd much rather get clear, concise, straight-forward RFCs, WITH that added NOTE or three that makes everything make sense. I prefer this to a "well, you can figure it out by carefully parsing the MUSTS and SHOULDS, and if you get it wrong, too bad for you" posture. -----Original Message----- From: sip-admin@lists.bell-labs.com [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Jonathan Rosenberg Sent: Thursday, October 26, 2000 3:50 AM To: 'Drage, Keith (Keith)'; 'SIP discussion list' Subject: RE: [SIP] Use of notes within the RFC bis draft > -----Original Message----- > From: Drage, Keith (Keith) [mailto:drage@lucent.com] > Sent: Wednesday, October 25, 2000 9:52 AM > To: 'SIP discussion list' > Subject: [SIP] Use of notes within the RFC bis draft [snip] > > There are additionally a large number of sentences throughout > the text that > commence: "Note that...". Are these also notes. > > As there is a need for other standards organisations to reference the > resultant RFCs with a clear understanding of the difference between > normative (i.e. requirements and definitions) and informative > material (i.e. > notes), I would like to propose that this distinction is made > absolutely > clear. In particular, I propose: > > - add the word "Note:" at the start of all indented text. > - make all sentences starting with the words "Note that" > into indented > text comencing with the word "Note:". I don't think this is really needed. The IETF has a clearly defined syntax for describing normative behaviors (rfc2119), and this has sufficed for RFCs up till now. -Jonatan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Oct 27 10:33:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA10908 for ; Fri, 27 Oct 2000 10:33:03 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8B40844344; Fri, 27 Oct 2000 09:33:06 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from is1-55.antd.nist.gov (is1-50.antd.nist.gov [129.6.50.251]) by lists.bell-labs.com (Postfix) with ESMTP id 4B07844344 for ; Fri, 27 Oct 2000 09:32:09 -0400 (EDT) Received: from nist.gov (IDENT:mranga@stinkbug.antd.nist.gov [129.6.55.9]) by is1-55.antd.nist.gov (8.9.3/8.9.3) with ESMTP id KAA17472; Fri, 27 Oct 2000 10:27:25 -0400 (EDT) Message-ID: <39F991C8.3E472874@nist.gov> From: "M. Ranganathan" Reply-To: mranga@nist.gov Organization: NIST advanced networking technologies group X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Content-Type: text/plain; charset=iso-8859-1 Subject: [SIP] Forwarding SIP Invites -- how to decide transport. Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 27 Oct 2000 10:31:36 -0400 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id KAA10908 Greetings (and Happy Diwali if it applies to you) !! I have a simple question regarding how to choose between tcp and udp when forwarding invites. Lets say we have the following scenario: UAC A registers with a proxy P using the following REGISTER: REGISTER sip:129.6.55.9 SIP/2.0 Via: SIP/2.0/TCP 129.6.55.9:1030 Authorization: Digest username="mranga", realm="mranga@129.6.55.9", nonce="586272861@129.6.55.9737064510 REGISTERThu, 26 Oct 2000 23:29:15 GMT", uri="mranga@129.6.55.9", response="9ce52922ddc7504327e6d346a45a07bb", opaque="", algorithm=MD5 From: To: Contact: ;transport=tcp;q=0 Date: Thu, 26 Oct 2000 23:29:15 GMT CSeq: 737064510 REGISTER Expires: 3600 Call-ID: 586272861@129.6.55.9 Content-Length: 0 Later UAC B wants to call A and sends an INVITE to the Proxy P using the request INVITE sip:mranga@129.6.55.9 SIP/2.0 Via: SIP/2.0/TCP 129.6.55.9:1032 Date: Thu, 26 Oct 2000 23:30:49 GMT From: To: Subject: foobar Priority: normal Expires: 3600 CSeq: 598470646 INVITE Call-ID: 341996928@129.6.55.9 Contact: Content-Type: application/sdp Content-Length: 129 v=0 o=mranga 972603049 972603049 IN IP4 129.6.55.9 s=foobar c=IN IP4 129.6.55.9 t=3181591849 3181595449 m=chat 40000 UDP 0 Now assuming that P is a stateful proxy and it needs to forward the invite. It knows that the protocol to use is sip because the Contact header in the previous REGISTER from A says to use SIP. However, SIP can be over TCP or UDP. Here's where I have the question -- how does P know whether to use UDP or TCP to forward the invite? The Contact header of the REGISTER does not specify a protocol. Do I just use TCP as specified in the Via header of the REGISTER from A or do I use the default (UDP) protocol to forward the invote? Thank you Ranga. -- M.Ranganathan NIST Advanced Networking Technologies Group, 100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899. Tel: 301 975 3664 Fax: 301 590 0932 ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÒ ùšŠX§‚X¬µ"þX¬¶ÏÛzYÿ•¦ìýÊ&†ÛiÿÿåŠËlý·¥—ùZnÏÜ¢oæj)fjåŠËbú? From sip-admin@lists.bell-labs.com Fri Oct 27 10:37:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA11794 for ; Fri, 27 Oct 2000 10:37:03 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7984C4434C; Fri, 27 Oct 2000 09:37:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from is1-55.antd.nist.gov (is1-50.antd.nist.gov [129.6.50.251]) by lists.bell-labs.com (Postfix) with ESMTP id 3050E44349 for ; Fri, 27 Oct 2000 09:36:46 -0400 (EDT) Received: from nist.gov (IDENT:mranga@stinkbug.antd.nist.gov [129.6.55.9]) by is1-55.antd.nist.gov (8.9.3/8.9.3) with ESMTP id KAA17634; Fri, 27 Oct 2000 10:32:01 -0400 (EDT) Message-ID: <39F992F7.FEE9014B@nist.gov> From: "M. Ranganathan" Reply-To: mranga@nist.gov Organization: NIST advanced networking technologies group X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Subject: Re: [SIP] Forwarding SIP Invites -- how to decide transport. References: <39F991C8.3E472874@nist.gov> Content-Type: multipart/alternative; boundary="------------B6EDD513D997A379214300A4" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 27 Oct 2000 10:36:39 -0400 --------------B6EDD513D997A379214300A4 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: base64 Oops I goofed a bit on that one. The first REGISTER header does not specify a tranansport for the contact and it should be : REGISTER sip:129.6.55.9 SIP/2.0 Via: SIP/2.0/TCP 129.6.55.9:1030 Authorization: Digest username="mranga", realm="mranga@129.6.55.9", nonce="586272861@129.6.55.9737064510 REGISTERThu, 26 Oct 2000 23:29:15 GMT", uri="mranga@129.6.55.9", response="9ce52922ddc7504327e6d346a45a07bb", opaque="", algorithm=MD5 From: To: Contact: Date: Thu, 26 Oct 2000 23:29:15 GMT CSeq: 737064510 REGISTER Expires: 3600 Call-ID: 586272861@129.6.55.9 Content-Length: 0 Thanks Ranga. "M. Ranganathan" wrote: > Greetings (and Happy Diwali if it applies to you) !! > > I have a simple question regarding how to choose between tcp and udp > when forwarding invites. Lets say we have the following scenario: > > UAC A registers with a proxy P using the following REGISTER: > > REGISTER sip:129.6.55.9 SIP/2.0 > Via: SIP/2.0/TCP 129.6.55.9:1030 > Authorization: Digest username="mranga", realm="mranga@129.6.55.9", > nonce="586272861@129.6.55.9737064510 REGISTERThu, 26 Oct 2000 23:29:15 > GMT", uri="mranga@129.6.55.9", > response="9ce52922ddc7504327e6d346a45a07bb", opaque="", algorithm=MD5 > From: > To: > Contact: ;transport=tcp;q=0 > Date: Thu, 26 Oct 2000 23:29:15 GMT > CSeq: 737064510 REGISTER > Expires: 3600 > Call-ID: 586272861@129.6.55.9 > Content-Length: 0 > > Later UAC B wants to call A and sends an INVITE to the Proxy P using > the request > > INVITE sip:mranga@129.6.55.9 SIP/2.0 > Via: SIP/2.0/TCP 129.6.55.9:1032 > Date: Thu, 26 Oct 2000 23:30:49 GMT > From: > To: > Subject: foobar > Priority: normal > Expires: 3600 > CSeq: 598470646 INVITE > Call-ID: 341996928@129.6.55.9 > Contact: > Content-Type: application/sdp > Content-Length: 129 > > v=0 > o=mranga 972603049 972603049 IN IP4 129.6.55.9 > s=foobar > c=IN IP4 129.6.55.9 > t=3181591849 3181595449 > m=chat 40000 UDP 0 > > Now assuming that P is a stateful proxy and it needs to forward the > invite. It knows that the protocol to use is sip because the Contact > header in the previous REGISTER from A says to use SIP. However, SIP can > be over TCP or UDP. Here's where I have the question -- how does P know > whether to use UDP or TCP to forward the invite? The Contact header of > the REGISTER does not specify a protocol. Do I just use TCP as > specified in the Via header of the REGISTER from A or do I use the > default (UDP) protocol to forward the invote? > > Thank you > > Ranga. > > -- > M.Ranganathan > NIST Advanced Networking Technologies Group, > 100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899. > Tel: 301 975 3664 Fax: 301 590 0932 > > ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÒ ùsSX§,X¬µ"þX¬¶ÏÛzYÿ*¦ìýÊ&?ÛiÿÿåSËlý·¥-ùZnÏÜ¢oæj)fjåSËb?ú? -- M.Ranganathan NIST Advanced Networking Technologies Group, 100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899. Tel: 301 975 3664 Fax: 301 590 0932 --------------B6EDD513D997A379214300A4 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit  
Oops I goofed a bit on that one. The first REGISTER  header  does  not specify a tranansport for the contact and it should be :
 

REGISTER sip:129.6.55.9 SIP/2.0
Via: SIP/2.0/TCP 129.6.55.9:1030
Authorization: Digest username="mranga", realm="mranga@129.6.55.9",
    nonce="586272861@129.6.55.9737064510 REGISTERThu, 26 Oct 2000 23:29:15
    GMT", uri="mranga@129.6.55.9",  response="9ce52922ddc7504327e6d346a45a07bb", opaque="", algorithm=MD5
From: <sip:mranga@129.6.55.9>
To: <sip:mranga@129.6.55.9>
Contact: <sip:mranga@129.6.55.9:6060>
Date: Thu, 26 Oct 2000 23:29:15 GMT
CSeq: 737064510 REGISTER
Expires: 3600
Call-ID: 586272861@129.6.55.9
Content-Length: 0

Thanks

Ranga.

"M. Ranganathan" wrote:

Greetings  (and Happy Diwali if it applies to you)  !!

I have a simple question regarding how to choose between tcp and udp
when forwarding invites. Lets say we have the following scenario:

UAC   A  registers with a proxy P using the following REGISTER:

REGISTER sip:129.6.55.9 SIP/2.0
Via: SIP/2.0/TCP 129.6.55.9:1030
Authorization: Digest username="mranga", realm="mranga@129.6.55.9",
nonce="586272861@129.6.55.9737064510 REGISTERThu, 26 Oct 2000 23:29:15
GMT", uri="mranga@129.6.55.9",
response="9ce52922ddc7504327e6d346a45a07bb", opaque="", algorithm=MD5
From: <sip:mranga@129.6.55.9>
To: <sip:mranga@129.6.55.9>
Contact: <sip:mranga@129.6.55.9:6060>;transport=tcp;q=0
Date: Thu, 26 Oct 2000 23:29:15 GMT
CSeq: 737064510 REGISTER
Expires: 3600
Call-ID: 586272861@129.6.55.9
Content-Length: 0

Later UAC B  wants to call A and sends an INVITE to the Proxy P using
the request

INVITE sip:mranga@129.6.55.9 SIP/2.0
Via: SIP/2.0/TCP 129.6.55.9:1032
Date: Thu, 26 Oct 2000 23:30:49 GMT
From: <sip:vikram@129.6.55.9>
To: <sip:mranga@129.6.55.9>
Subject: foobar
Priority: normal
Expires: 3600
CSeq: 598470646 INVITE
Call-ID: 341996928@129.6.55.9
Contact: <sip:mranga@129.6.55.9>
Content-Type: application/sdp
Content-Length: 129

v=0
o=mranga 972603049 972603049 IN IP4 129.6.55.9
s=foobar
c=IN IP4 129.6.55.9
t=3181591849 3181595449
m=chat 40000 UDP 0

Now assuming that P is a stateful proxy and  it needs to forward the
invite. It knows that the protocol to use is sip because the Contact
header in the previous REGISTER from A says to use SIP. However, SIP can
be over TCP or UDP. Here's where I have the question -- how does P know
whether to use UDP or TCP  to forward the invite?  The Contact header of
the REGISTER does not specify a protocol.  Do I just use  TCP as
specified in the Via header of the REGISTER from A or do I use the
default (UDP)  protocol to forward the invote?

Thank you

Ranga.

--
M.Ranganathan
NIST Advanced Networking Technologies Group,
100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899.
Tel: 301 975 3664 Fax: 301 590 0932

ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÒ ùsSX§,X¬µ"þX¬¶ÏÛzYÿ*¦ìýÊ&?ÛiÿÿåSËlý·¥-ùZnÏÜ¢oæj)fjåSËb?ú?

-- 
M.Ranganathan
NIST Advanced Networking Technologies Group,
100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899. 
Tel: 301 975 3664 Fax: 301 590 0932
  --------------B6EDD513D997A379214300A4-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Oct 27 11:36:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA28588 for ; Fri, 27 Oct 2000 11:36:00 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 14E7144354; Fri, 27 Oct 2000 10:36:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ertpg14e1.nortelnetworks.com (ertpg14e1.nortelnetworks.com [47.234.0.35]) by lists.bell-labs.com (Postfix) with ESMTP id 02C3244340 for ; Fri, 27 Oct 2000 10:35:26 -0400 (EDT) Received: from zsc4c002.corpwest.baynetworks.com by ertpg14e1.nortelnetworks.com; Fri, 27 Oct 2000 10:04:58 -0400 Received: from zsc4c006.corpwest.baynetworks.com ([134.177.2.153]) by zsc4c002.corpwest.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id 4WSZVJBH; Fri, 27 Oct 2000 07:04:55 -0700 Received: from long-pc.corpwest.baynetworks.com (LONG-PC [47.81.5.83]) by zsc4c006.corpwest.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id VD9VT4G4; Fri, 27 Oct 2000 07:04:51 -0700 Message-Id: <4.2.2.20001027070558.00db2580@zsc4c006.corpwest.baynetworks.com> X-Sender: long@zsc4c006.corpwest.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 To: Kevin Summers , sip@lists.bell-labs.com From: "Lyndon Ong" Subject: RE: [SIP] I-D ACTION:draft-ietf-sip-isup-mime-05.txt In-Reply-To: <69DEAC407D3B6A48AA71F5D09966F7DB397D3B@mailhost.ttiworld.c om> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 27 Oct 2000 07:06:21 -0700 Whoops, sorry, that was a typo. It should be "signal". L. Ong At 12:41 PM 10/26/2000 -0700, Kevin Summers wrote: >On page three, Content-Disposition is set to "session" ... was this a typo? >It looks as though you've settled on "signal" as the default value here. Are >there any other values for this header? > >Regards, >Kevin > >-----Original Message----- >From: Internet-Drafts@ietf.org >[mailto:Internet-Drafts@ietf.org] >Sent: Thursday, October 26, 2000 5:47 AM >Cc: sip@lists.bell-labs.com >Subject: [SIP] I-D ACTION:draft-ietf-sip-isup-mime-05.txt > >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 : MIME media types for ISUP and QSIG Objects > Author(s) : E. Zimmerer, J. Peterson, A. Vemuri, > L. Ong, M. Watson, M. Zonoun > Filename : draft-ietf-sip-isup-mime-05.txt > Pages : 7 > Date : 25-Oct-00 > >This document describes MIME types for application/ISUP and >application/QSIG objects for use in SIP applications, according to >the rules defined in RFC 2048 [1]. These types can be used to identify >ISUP and QSIG objects within a SIP message such as INVITE or INFO, >as might be implemented when using SIP between legacy systems. > >A URL for this Internet-Draft is: >http:/ >/www.ietf.org/internet-drafts/draft-ietf-sip-isup-mime-05.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-isup-mime-05.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-isup-mime-05.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. > >********************************************************************** >This email and any files transmitted with it are confidential and >intended solely for the use of the individual or entity to whom they >are addressed. If you have received this email in error please notify >the system manager. > >This footnote also confirms that this email message has been swept by >MIMEsweeper for the presence of computer viruses. > >www.inip.com >********************************************************************** > >_______________________________________________ >SIP mailing list >SIP@lists.bell-labs.com >http://lists.bell-labs.com >/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Oct 27 12:04:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA10032 for ; Fri, 27 Oct 2000 12:04:02 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 598624433C; Fri, 27 Oct 2000 11:04:06 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cisco.com (uzura.cisco.com [161.44.3.77]) by lists.bell-labs.com (Postfix) with ESMTP id F04514433C for ; Fri, 27 Oct 2000 11:03:16 -0400 (EDT) Received: from cisco.com (klingle-ultra.cisco.com [161.44.53.27]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id MAA23530; Fri, 27 Oct 2000 12:02:18 -0400 (EDT) Message-ID: <39F9A718.C37F90A8@cisco.com> From: Kevin Lingle X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "Henning G. Schulzrinne" Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Some brief comments on the SIP MIB References: <39F7927C.1E4791D3@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 27 Oct 2000 12:02:32 -0400 Content-Transfer-Encoding: 7bit Henning, Thanks for the comments. I presume they are based on the draft-ietf-sip-mib-01.txt version of the I-D. "Henning G. Schulzrinne" wrote: > > - The Hide configuration options are redundant; obviously, they are in > RFC 2543, but I don't think it's useful to carry them forward. There are a couple of objects (in two different mib modules) that speak about hiding. SIP-COMMON-MIB... sipHideOperation - clearly references rfc 2543. SIP-SERVER-MIB... sipHideRespect. Are you suggesting we drop both of these objects? > > - All systems need to understand compact form, so I'm not sure why this > is a variable. I'll consider this object dropped in the next revision of the draft. > > - ULS should probably at least mention LDAP as an example. ULS has undergone some changes. We had a request to handle prioritzed backup addressess. I also got some comments that having one generic ULS address wasn't sufficient. Systems may have multiple resources they use to determine where users are. You can view the proposal on sip-mib@egroups.com archive [http://www.egroups.com/message/sip-mib/40]. There has been no feedback on the proposal yet (unfortunately that is typical). I would appreciate if you could take a quick look. Btw, the current proposal does not actualy handle prioritized addresses correctly (i need to consider that further). What is your view on having the ability to specify backup addresses ULS? Wrt your specific comment on LDAP as it might relate to the new proposal for ULS objects... (see proposal to understand the objects) One way to handle LDAP would be to have sipULSAddrSipEntity set to 'other' because LDAP is not a true sip entity and use the sipULSAddrSipEntityDescr object (a free form string description of the addressed entity) to reflect it's an address for a LDAP server. Actually, as I think about it, the names and semantics of some of these newly proposed object aren't a great fit for addressing non-sip entities. Maybe we need a 'nonSip' enumeration for the SipEntityType textual convention (specifies the range of values for sipULSAddrSipEntity object. And maybe the sipULSAddrSipEntityDescr object is better named sipULSAddrEntityDescr. In your LDAP scenario, then a row in the sipULSAddrTable would have objects w/ values like so: sipULSAddrIndex = 1 -- arbitrary sipULSAddrType = ipv4 -- InetAddressType textual convention from RFC 2851 sipULSAddr = 123.45.67.89 sipULSAddrSipEntity = nonSip sipULSAddrEntityDescr = "LDAP Server" > > - Supported URIs should probably say URI "schemes" rather than just > URIs, as the current text can be read to imply to list all user SIP URIs > managed by the server. I presume the comment relates to sipUriSupportedTable in SIP-COMMON-MIB, right? I'm not clear on exactly where you would like the description changed: in the sipUriSupportedTable description or in the description of the sipUriSupported object itself? Kevin > -- > Henning Schulzrinne http://www.cs.columbia.edu/~hgs > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Kevin R. Lingle 919.392.2029 checkout: http://wwwin-eng.cisco.com/Eng/IOS/SNMP_WWW/mib-police.html Sometimes I think I understand everything, then I regain consciousness. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Oct 27 14:55:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA00515 for ; Fri, 27 Oct 2000 14:55:03 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 340C94433A; Fri, 27 Oct 2000 13:55:06 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from eyeforthefuture.com (eyeforthefuture.com [216.122.88.93]) by lists.bell-labs.com (Postfix) with ESMTP id 2E44444338 for ; Thu, 26 Oct 2000 21:51:34 -0400 (EDT) Received: from [208.61.13.129] (adsl-61-13-129.mia.bellsouth.net [208.61.13.129]) by eyeforthefuture.com (8.9.3/8.9.3) with ESMTP id TAA03435; Thu, 26 Oct 2000 19:47:18 -0700 (PDT) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Subject: Re: [SIP] New SUBSCRIBE/NOTIFY draft available From: David Shrader To: , "Adam B. Roach" Cc: , Message-ID: In-Reply-To: <88256983.006D281F.00@hqoutbound.ops.3com.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 26 Oct 2000 22:44:22 -0400 Content-Transfer-Encoding: 7bit I was also thinking that a BYE would cancel a subscription. At least in the context of an interaction begun with an INVITE, maybe that is erroneous. When SUBSCRIBE is outside the context of a call, it is not so clear if BYE is appropriate since the SUBSCRIBE, expires 0, ... method would work like cancelling a registration. On another note, is there really even a need for the Event: header. Wouldn't it be more flexible to simply state that if no Event: header is present, then you are subscribing to any events that the object desires to expose? ---------------------------- David Shrader Master Consultant, Inc. dshrader@master-consultant.com http://www.EyeForTheFuture.com > From: Anoop_Tripathi@3com.com > Date: Wed, 25 Oct 2000 14:49:57 -0500 > To: "Adam B. Roach" > Cc: sip@lists.bell-labs.com, sip-events@egroups.com > Subject: Re: [SIP] New SUBSCRIBE/NOTIFY draft available > > > > > Hi Adam, > > Few comments : > > What is the difference between registering (REGISTER) for an event and > subscribing (SUBSCRIBE) to an event? > I REGISTER to a proxy server to receive INVITE for my calls or do I > SUBSCRIBE to my proxy server to NOTIFY me of my calls. > I see myself registering to receive invites to calls, receive voice mail > notifications, and other notifications and similarly I see myself subscribing > to > these things also. > > All messages can be combined into one message and similary all headers can be > broken into different messages. > INFO method I can see used for carrying various informational messages > during a call. > All what I am trying to say is did we give enough thoughts in this case > whether a header would suffice or a new message is required. > > As you mentioned it is a fine line between whether a new message or a new > header is suitable. > Did we do go through the process of deciding whether a new header is more > suitable than a new message in case of SUBSCRIBE? > If not, should we do that or not. > > The reason why I ask this question is if tomorrow I come up with a new > concept what would be the deciding factors for enhancing REGISTER,SUBSCRIBE > or adding a new method. > > Just like we teardown a session with a BYE method. Can we also teardown > subscriptions using BYE/NOTIFY method. > > Thanks, > > Anoop > > > > > > "Adam B. Roach" on 10/25/2000 12:21:00 PM > > Sent by: "Adam B. Roach" > > > To: Anoop Tripathi/MW/US/3Com > cc: sip@lists.bell-labs.com, sip-events@egroups.com > Subject: Re: [SIP] New SUBSCRIBE/NOTIFY draft available > > > >> Was using a header in INVITE/REGISTER requests as a replacement of SUBSCRIBE >> request considered? > > No, this didn't come up as a suggestion so far. The SUBSCRIBE method > dates back to February of 1998 (in spirit, at least), and has been > incorporated into PINT and the "SIP for Presence" work. The intent > of my draft was to provide a framework which allows multiple uses > of the SUBSCRIBE and NOTIFY methods in such a way that the different > uses didn't get in the way of each other. Using any method other > than "SUBSCRIBE" would leave the current drafts somewhat orphaned. > >> So far I could only see two cases of using SUBSCRIBE. One >> during call. In that case we could send the subscribe information in >> INVITE/RE-INVITE requests. Second as part of registration. You register to >> Proxy, Voice-mail server etc and subscribe to events. So what is the >> motivation behind having a separate request? > > The short answer is: the same reason "INFO" isn't defined as "BYE" with > a "Just-Kidding:" header. > > "SUBSCRIBE" isn't what "INVITE" means, in any remote sense; neither is > it what "REGISTER" is intended to mean. It has been pointed out that > all methods could be generalised to one method (e.g. replace "BYE" > with "INVITE" and a special header indicating that you are inviting > the other party to end the current session.) > > Defining such a system would be quite easy. It would also be patently > ridiculous. > > Since asyncronous event subscription is a distinct action which has > no ties to any of the other defined or proposed actions, it seems > reasonable to define a new method. > >> By defining SUBSCRIBE/NOTIFY requests are we trying to achieve the similar >> functionality that exists in MEGACO/H.248. > > Not really. the H.248 event notification, as I understand it, is > more appropriate for terminal/endpoint events (e.g. hookflash, > digit collection, etc). The SIP event notification has so far > been proposed for tasks such as call status, user presence, > and message waiting indication. > >> Is DTMF digit collection a valid usage of this scheme? > > That's a religious issue. Search your own soul and figure out > what's true for you. If you want to read evangelical screeds on > both sides of the issue, check the SIP working group mailing > list archives. > > -- > 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 > > > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Oct 27 14:56:34 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA01022 for ; Fri, 27 Oct 2000 14:56:34 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id F265544357; Fri, 27 Oct 2000 13:55:17 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from eyeforthefuture.com (eyeforthefuture.com [216.122.88.93]) by lists.bell-labs.com (Postfix) with ESMTP id 14F3D44338 for ; Thu, 26 Oct 2000 22:00:39 -0400 (EDT) Received: from [208.61.13.129] (adsl-61-13-129.mia.bellsouth.net [208.61.13.129]) by eyeforthefuture.com (8.9.3/8.9.3) with ESMTP id TAA06867; Thu, 26 Oct 2000 19:56:30 -0700 (PDT) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Subject: Re: [SIP] SIP and SIP-T distinction. From: David Shrader To: , , Message-ID: In-Reply-To: <350829A9DA9FD411841200508BF9F0600AB957@n0217idc1.oss.level3.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 26 Oct 2000 22:53:35 -0400 Content-Transfer-Encoding: 7bit I don't think we should be treating SIP-T as a separate protocol. There just happen to be additional components to the message and you either understand them or you don't. If you don't understand something and you don't need to understand, then ignore it. If you do need to understand it, then reject it. ---------------------------- David Shrader Master Consultant, Inc. dshrader@master-consultant.com http://www.EyeForTheFuture.com > From: Aparna.Vemuri@Level3.com > Date: Thu, 26 Oct 2000 12:13:12 -0600 > To: andrew_s_duncan@agilent.com, sip@lists.bell-labs.com > Subject: RE: [SIP] SIP and SIP-T distinction. > > Andy, > Please see notes below. > Aparna > > > > Hi, > > I realise that SIP-T is not a new protocol specification but simply details > the methods, standards and tools necessary to enable MGC's to inter operate > via the SIP protocol BUT is there an easy way to distinguish bewteen SIP and > SIP-T messages (i.e. messages with encapsulated ISUP as well as SDP). > > For example, will a SIP-T message have its own SIP-VERSION to go in the > request/response header - SIP-T/1.0 ? > >>>> > No. As you yourself state, SIP-T is not a new protocol. No special analysis > is required for processing these messages. SIP proxies (and in general, the > IP > network) do(es) not have to be aware of the fact that the 'signaling is > SIP-T '. > SIP UAs like MGC UAs and SIP-phones (as defined in the Contexts and > Architectures document) are the elements that need to take the necessary > measures to handle the ' SIP-T signaling ' (whether accept and generate ISUP > or > ignore or reject MIME multi-part, etc.) > <<< > > Or is the message body is defined as having CONTENT-TYPE of multipart/mixed > can you assume it is a SIP-T message ? I take it this too much to assume as > there is no doubt other expansions of SIP that use this MIME format for > multiple payloads, or is likely to be so in the future. Also, is it likely > that multipart/mixed may just be used to carry the SDP information on its > own instead of application/sdp ? > >>>> > A multi-part/mixed payload is NOT sufficient to establish the identity of > SIP-T and > precisely for the reason you cite. > <<< > > Or is the only way to determine whether there is an ISUP payload is to delve > into the message body and look for CONTENT-TYPE application/isup ? > > Finally, is it also tto much to assume that the SDP payload will always > precede the ISUP payload in the message body ? > >>>> > I do not believe there are any rules that specify the order of the payloads. > <<< > > Hopefully, I have not polluted your mailing list with my inane ramblings, > but I have scoured your FAQ section and archives to no avail !! > > Thanks for any help anyone is prepared to give. > > Andy. > ============================ > Andrew S Duncan > Agilent Technologies > Tel: 0131 331 7822 Exten: 32822 > Mailstop: SQFR&D3 > ============================ > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Oct 27 14:58:51 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA01746 for ; Fri, 27 Oct 2000 14:58:51 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C902E44362; Fri, 27 Oct 2000 13:55:27 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by lists.bell-labs.com (Postfix) with ESMTP id 595F244336 for ; Fri, 27 Oct 2000 02:46:47 -0400 (EDT) Received: from mr5.exu.ericsson.se (mr5u3.ericy.com [208.237.135.124]) by imr1.ericy.com (8.9.3/8.9.3) with ESMTP id CAA08860; Fri, 27 Oct 2000 02:46:41 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr5.exu.ericsson.se (8.10.2/8.10.2) with ESMTP id e9R7iqk11794; Fri, 27 Oct 2000 02:44:52 -0500 (CDT) Received: from ericsson.com (kipe41.eraj.ericsson.se [147.214.68.41]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id CAA12999; Fri, 27 Oct 2000 02:46:39 -0500 (CDT) Message-ID: <39F932DD.F8D390BE@ericsson.com> From: Sean Olson Organization: Ericsson Inc. X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: confctrl@isi.edu, sip@lists.bell-labs.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] New I-D on SDP and IPv6 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 27 Oct 2000 09:46:37 +0200 Content-Transfer-Encoding: 7bit Hello, There is a new Internet-Draft available on the use of IPv6 addresses in SDP. The I-D simply clarifies the syntax to use for representing an IPv6 address in an SDP description. Any comments are welcome. http://www.ietf.org/internet-drafts/draft-olson-sdp-ipv6-00.txt Regards, Sean Olson _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Oct 27 15:01:25 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA02560 for ; Fri, 27 Oct 2000 15:01:25 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7F0A24436A; Fri, 27 Oct 2000 13:55:38 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by lists.bell-labs.com (Postfix) with ESMTP id E54FF44336 for ; Fri, 27 Oct 2000 09:00:39 -0400 (EDT) Received: from mr5.exu.ericsson.se (mr5u3.ericy.com [208.237.135.124]) by imr1.ericy.com (8.9.3/8.9.3) with ESMTP id JAA28652; Fri, 27 Oct 2000 09:00:31 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr5.exu.ericsson.se (8.10.2/8.10.2) with ESMTP id e9RDwfk12480; Fri, 27 Oct 2000 08:58:41 -0500 (CDT) Received: from ericsson.com (kipe41.eraj.ericsson.se [147.214.68.41]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id JAA28538; Fri, 27 Oct 2000 09:00:28 -0500 (CDT) Message-ID: <39F98A78.6FB1ABBE@ericsson.com> From: Sean Olson Organization: Ericsson Inc. X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: "'Drage, Keith (Keith)'" , "'SIP discussion list'" Subject: Re: [SIP] Potential definitions required References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 27 Oct 2000 16:00:24 +0200 Content-Transfer-Encoding: 7bit > > Looking at the bis draft from a readability viewpoint I > > considered that a > > number of additional definitions at the start of the document > > would improve > > things. Could I therefore make a request that definitions are > > drafted for > > the following: > > > > stateful proxy (server) > > stateless proxy (server) Based on the text in Section 12.3 of the bis-02 draft: ====================================================== " A stateful proxy acts similar to a virtual UAS/UAC, but cannot be viewed as just a UAS and UAC glued together at the back. (In particular, it does not originate requests except ACK and CANCEL.) It implements the server state machine when receiving requests, and the client state machine for generating outgoing requests, with the exception of receiving a 2xx response to an INVITE. Instead of generating an ACK, the 2xx response is always forwarded upstream towards the caller. Furthermore, ACK's for 200 responses to INVITE's are always proxied downsteam towards the UAS, as they would be for a stateless proxy A stateless proxy forwards every request it receives downstream, and every response it receives upstream." And based on the FAQ answer to the difference between a stateful and stateless proxy at: http://www.cs.columbia.edu/sip/faq/cache/36.html ================================================ "Stateless proxies forget about the SIP request once it has been forwarded. Stateful proxies remember the request after it has been forwarded, so they can associate the response with some internal state. In other words, stateful proxies maintain transaction state. Stateful implies transaction state, not call state. Stateless proxies scale very well, and can be very fast. They are good for network cores. Stateful proxies can do more (they can fork, for example, see the next question) and can provide services stateless ones can't (call forward busy, for example). They don't scale as much as stateless ones. An admininstrator gets to decide which to use. These are also logical entities; a physical proxy is likely to act as a stateless proxy for some calls, stateful for others, and as a redirect server for even others. Neither stateful nor stateless proxies need to maintain call state, although they can, but will need to make sure that they are part of subsequent transactions via the Record-Route header. A proxy must be stateful if one of the following conditions hold: 1. It uses TCP, 2. It uses multicast, 3. It forks. " I would suggest the following definitions for a stateless and stateful proxy. Stateless Proxy: A logical entity that does not maintain state for a SIP transaction. A stateless proxy forwards every request it receives downstream and every response it receives upstream. ["downstream" and "upstream" are defined in section 1.3 of the bis draft] Stateful Proxy: A logical entity that maintains state information at least for the duration of a SIP transaction. The behavior of a stateful proxy is further defined in section 12.3. These definitions are intentionally lean as I think they are more accurate that way. The key aspects are that these are logical entities. One maintains transaction state, the other does not. /sean -- Sean Olson Ericsson _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Oct 27 15:03:43 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA03079 for ; Fri, 27 Oct 2000 15:03:43 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id BA7D244371; Fri, 27 Oct 2000 13:55:47 -0400 (EDT) Delivered-To: sip@share.research.bell-labs.com Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by lists.bell-labs.com (Postfix) with SMTP id 7C0E444336 for ; Fri, 27 Oct 2000 10:06:07 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Fri Oct 27 11:04:58 EDT 2000 Received: by lists.bell-labs.com (Postfix) id F0BF744380; Fri, 27 Oct 2000 10:51:49 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ans.ih.lucent.com (ans.ih.lucent.com [135.2.78.5]) by lists.bell-labs.com (Postfix) with SMTP id A50B34437D for ; Fri, 27 Oct 2000 10:51:48 -0400 (EDT) Received: by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id JAA24198; Fri, 27 Oct 2000 09:51:45 -0500 Cc: sip@lists.bell-labs.com Received: from lucent.com by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id JAA24162; Fri, 27 Oct 2000 09:51:43 -0500 Message-ID: <39F9967D.220EAC04@lucent.com> From: "Vijay K. Gurbani" Reply-To: vkg@lucent.com Organization: Intelligent Network/Messaging Systems & Internet Software Group X-Mailer: Mozilla 4.61 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: mranga@nist.gov Original-CC: sip@lists.bell-labs.com Subject: Re: [SIP] Forwarding SIP Invites -- how to decide transport. References: <39F991C8.3E472874@nist.gov> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 27 Oct 2000 09:51:41 -0500 Content-Transfer-Encoding: 7bit "M. Ranganathan" wrote: > > Greetings (and Happy Diwali if it applies to you) !! Yes, it does. Same to you as well :-) > I have a simple question regarding how to choose between tcp and udp > when forwarding invites. Lets say we have the following scenario: [...] >Oops I goofed a bit on that one. The first REGISTER header does not >specify a tranansport for the contact and it should be : > >REGISTER sip:129.6.55.9 SIP/2.0 >Via: SIP/2.0/TCP 129.6.55.9:1030 [...] >Contact: [...] Take a look at the section 1.4.2 (bis) -- it details the steps on locating a SIP server. Since your example uses IP addresses directly, P should try UDP first; if that attempt failed, it should try TCP. Re- call that proxies MUST support both TCP and UDP, so before failing the call entirely, P should try both transports (and SCTP if it supports it). If your example did not have IP addresses, P could have queried DNS for SRV records for all transports supported by it and ordered these based on priority (see step 5 in section 1.4.2). BTW, your earlier Contact header's syntax was in error, I think. It was listed as: Contact: ;transport=tcp;q=0 It should be: Contact: ;q=0 Contact does not have transport parameter, addr-spec does. Contact only has q, action, expires and contact-extension parameters (I suppose you could make the case that transport=tcp was a contact-extension parameter...) Regards, - vijay -- Vijay K. Gurbani vkg@lucent.com vkg@research.bell-labs.com vkg@acm.org Internet Software Group/Intelligent Network and Messaging Systems Lucent Technologies/Bell Labs Innovations, 263 Shuman Blvd, Rm 1A-413 Naperville, Illinois 60566 Voice: +1 630 224 0216 Fax: +1 630 713 0184 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Oct 27 16:41:13 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA25290 for ; Fri, 27 Oct 2000 16:41:13 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id EB54B44345; Fri, 27 Oct 2000 15:41:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mail-dns1-nj.dialogic.com (mail-dns1-nj.dialogic.com [146.152.228.10]) by lists.bell-labs.com (Postfix) with ESMTP id 4198444336 for ; Fri, 27 Oct 2000 15:40:15 -0400 (EDT) Received: from mail4.dialogic.com ([146.152.6.40]) by mail-dns1-nj.dialogic.com (8.9.1a+p1/8.9.1/d: dialogic.m4,v 1.3 2000/05/05 13:56:23 dmccart Exp $) with ESMTP id UAA02200 for ; Fri, 27 Oct 2000 20:44:25 GMT Received: from exchange3nj.dialogic.com (mailnj.dialogic.com [146.152.3.18]) by mail4.dialogic.com (8.9.3+Sun/8.9.3) with ESMTP id QAA08119 for ; Fri, 27 Oct 2000 16:39:57 -0400 (EDT) Received: by mailnj.dialogic.com with Internet Mail Service (5.5.2650.21) id ; Fri, 27 Oct 2000 16:40:07 -0400 Message-ID: From: "Goutam, Gayathri" To: "'SIP@lists.bell-labs.com'" Subject: [SIP] un-subscribe MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 27 Oct 2000 16:40:15 -0400 un-subscribe > -----Original Message----- > From: Oughton, Andre [mailto:aoughton@comversens.com] > Sent: Wednesday, October 18, 2000 1:55 PM > To: 'SIP@lists.bell-labs.com' > Subject: [SIP] un-subscribe > > > un-subscribe > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Oct 27 17:08:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA01291 for ; Fri, 27 Oct 2000 17:08:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7C5DA44358; Fri, 27 Oct 2000 16:08:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lists.bell-labs.com (Postfix) with ESMTP id EEE3F44336 for ; Fri, 27 Oct 2000 16:07:55 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id e9RL7iZ19623; Fri, 27 Oct 2000 23:07:44 +0200 (MEST) 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 AAA26913; Sat, 28 Oct 2000 00:07:43 +0300 (EET DST) Received: from lmf.ericsson.se (E0080C77A56E4.lmf.ericsson.se [131.160.105.66]) by greymse1.lmf.ericsson.se (8.9.3 (PHNE_18979)/8.8.6) with ESMTP id AAA15353; Sat, 28 Oct 2000 00:07:40 +0300 (EETDST) Message-ID: <39F9EE89.80A5B991@lmf.ericsson.se> From: Gonzalo Camarillo Organization: Ericsson X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: William Marshall Cc: jdrosen@dynamicsoft.com, sip@lists.bell-labs.com Subject: Re: FW: [SIP] Feedback on manyfolks References: <200010261701.NAA33983@fish-ha.research.att.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sat, 28 Oct 2000 00:07:21 +0300 Content-Transfer-Encoding: 7bit Hi Bill, William Marshall wrote: > For the simple call from A to T, A inserts the SDP line a=qos:mandatory > sendrecv" which T is willing to accept. But T can't do the send&recv QoS > itself - it needs help from A for the A->T direction. > (Note that T doesn't know whether A will be using RSVP, so it can't > depend on using a RESV-CONF to do this trick). So, T does not know whether A uses RSVP or not... Is there a negotiation of the QoS reservation scheme used? That is, my terminal sends an INVITE with SDP preconditions (sendrecv), and I get the 183 with the same preconditions (sendrecv). What should my terminal do? Should it use RSVP to reserve resources in the recv direction and expect the other end to do the same in the other direction? Should it reserve resources for send&recv over its radio access and expect the other end to perform also resorce reservation on its access (maybe an ethernet)? You mention also bi-directional resource reservation schemes. Should my terminal use its bi-directional resource reservation mechanism and perform the sendrecv reservation? Who decides which resource reservation mechanism is to be used? Do we need negotiation of the reservation mechanism? Therefore it needs > to ask for the confirmation; without it T would be proceeding with the > session establishment without fulfilling the preconditions. So it > asks for the confirmation in the 183 response. > > Consider the case where T implements some other (i.e. non-RSVP) resource > reservation protocol. If it can somehow get send&recv QoS from A to T > by itself, then it can locally determine that it has met the preconditions. > In this case there is no need for the COMET, and giving A the capability > to demand one actually increases the call setup delay. > > > OK, now, let me re-write my suggestion (it appears already in my > > previous mail): > > My suggestion is: > > UAC sends result > > comet sendrecv 2 COMETs, UAS->UAC, then UAC->UAS > > comet send 1 COMET, UAC->UAS > > 0 COMETs > > > > This mechanism includes all the comments received in this thread so far: > > 1) It is simple, because there is no negotiation of how many COMETs have > > to be sent. The UAC makes the decision and the UAS obeys. > > > > Question: Do you have any situation where the UAS would like to change > > the decision made by the UAC regarding the number of COMETs sent? I > > cannot think of any useful scenario. > > If we consider that there are reservation protocols other than RSVP, > and in particular ones that can make bi-directional reservations, > then the UAS would be in a better position to decide the proper number > of COMETs than the UAC. > > > > > 2) It saves one RTT in the most common situation (just one COMET > > UAC->UAS). > > > > 3) The syntax is really "human readable". Direction tags are very easy > > to interpret. Even easier when they are already used in the a=QoS line. > > > > > > Do you have any objection against this approach? > > > > Practically this is the same mechanism described by Jonathan (where the > > UAC also makes the decision). I have just added the posibility of just > > one COMET (for saving bandwidth basically). > > > > My only real objection to this approach is that it duplicates a facility > already provided in the manyfolks procedures, and I see no reason to > require two ways to force the same behavior. > I am proposing to go for just one mechanism. That's why we are discussing which one is the best. Once we have consensus, we implement just one. > A secondary objection (relatively minor) is that I always get confused > when we use the terms "send" and "recv" between two parties that both "send" > and "recv"; a "send" interpreted by one party is the "recv" of the other. If you are serious about this objection, let's change also the direction tag of the QoS line, because it uses the same mechanism. I believe that if sendrecv kind of tags are already used in the QoS line, they can be used as a direcion tag for the confirm also. Best regards, 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 31 18 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Oct 27 17:29:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA06349 for ; Fri, 27 Oct 2000 17:29:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B80EA4433A; Fri, 27 Oct 2000 16:29:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from rwcxch02.clarent.com (unknown [208.205.112.2]) by lists.bell-labs.com (Postfix) with ESMTP id 4F19444336 for ; Fri, 27 Oct 2000 16:28:38 -0400 (EDT) Received: by rwcxch02.clarent.com with Internet Mail Service (5.5.2650.21) id <4V3F3KK5>; Fri, 27 Oct 2000 14:26:16 -0700 Message-ID: <6374EFC78443D41197DD00508B5C35DD017A8820@rwcxch02.clarent.com> From: Jean-Francois Mule To: James_Renkel@3com.com, ietf-fax@imc.org Cc: sip@lists.bell-labs.com MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] RE: Request for information on using T.30/T.37/T.38 with SIP/SDP/ RTP Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 27 Oct 2000 14:26:16 -0700 Jim, There is an Internet-Draft on SIP and T.38 fax calls at http://search.ietf.org/internet-drafts/draft-mule-sip-t38callflows-00.txt It deals with how to negotiate a t.38 fax calls using sip as a signaling protocol (including switch over from audio/rtp to data/t38), the SDP attributes that itu-t sg-8 has registered with IANA. Comments are appreciated on this Internet-Draft. > o specification of T.30/T.37/T.38 payload formats for RTP and other > transport > protocols; and To my knowledge, T.38 and T.37 recommendations do not rely on RTP encapsulation. For T.38, see itu-t t.38 specification (t.38 IFP fax packets can be carried over TCP or UDP and for UDP, the t.38 spec defines a UDP transport layer UDPTL) > o specification of the above media stream types in SDP/SIP. This is covered in the ITU-T document sent by sg-8 to IANA and summarized in the above Internet Draft for reference only. This is a first draft and comments are welcome. Jean-Francois Mule Clarent Corporation > -----Original Message----- > From: James_Renkel@3com.com [mailto:James_Renkel@3com.com] > Sent: Friday, October 27, 2000 9:33 AM > To: ietf-fax@imc.org > Subject: Request for information on using T.30/T.37/T.38 with > SIP/SDP/RTP > > > > > The 3Com Carrier Networks Business System Engineering group is working > on > extending and integrating some of our products to achieve greater > functionality > and better interworking in the areas of store-and-forward and > real-time > facsimile transmission. Products in this area include facsimile > applications > systems and PSTN-Internet interworking gateways. > > Does anyone know of any work that has been done or is being done or > anyone that > has done or is doing work in the areas of: > o specification of T.30/T.37/T.38 payload formats for RTP and other > transport > protocols; and > o specification of the above media stream types in SDP/SIP. > > Any information you have on this would be greatly > approciated. Thank you > in > advance for your attention to this. > > Jim Renkel > Director, Advanced Technology & System Engineering > 3Com Carrier Networks Business > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Oct 27 18:11:00 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA15613 for ; Fri, 27 Oct 2000 18:11:00 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D08114433A; Fri, 27 Oct 2000 17:11:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14]) by lists.bell-labs.com (Postfix) with ESMTP id 97EFF44336 for ; Fri, 27 Oct 2000 17:10:45 -0400 (EDT) Received: from fokus.gmd.de (dhcp082 [195.37.78.210]) by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id AAA03479 for ; Sat, 28 Oct 2000 00:10:40 +0200 (MET DST) Message-ID: <39F9FD53.113F64AB@fokus.gmd.de> From: Jiri Kuthan Organization: GMD Fokus X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: SIP@lists.bell-labs.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] Status of SIP Games Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sat, 28 Oct 2000 00:10:27 +0200 Content-Transfer-Encoding: 7bit Back in August I saw an anouncement on the SIP mailing list to bring SIP to network games. Is anybody working on it? Jiri _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Oct 27 18:29:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA19505 for ; Fri, 27 Oct 2000 18:29:02 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 67A4A44337; Fri, 27 Oct 2000 17:29:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by lists.bell-labs.com (Postfix) with SMTP id 00C4C44336 for ; Fri, 27 Oct 2000 17:28:35 -0400 (EDT) Received: from 157.54.9.104 by mail2.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 27 Oct 2000 15:28:27 -0700 (Pacific Daylight Time) Received: by INET-IMC-02 with Internet Mail Service (5.5.2651.58) id ; Fri, 27 Oct 2000 15:28:25 -0700 Message-ID: From: Christian Huitema To: "'Sean Olson'" , confctrl@isi.edu, sip@lists.bell-labs.com Subject: RE: [SIP] New I-D on SDP and IPv6 X-Mailer: Internet Mail Service (5.5.2651.58) Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 27 Oct 2000 15:28:09 -0700 Why are you trying to syntactically prevent the use of IPv4 class E addresses, or IPv4 addresses that terminate in ".0" ? These may not be terribly useful, but a syntax description is the wrong place to do this kind of controls. Besides, I can see why I would want in some cases to use a null address, or an experimental anycast address. Besides, the whole thing does not seem consistent. You don't spend the same amount of effort to qualify the fact that there shall be at most 8 hexparts in the IPv6 address, or that the IPv6 multicast addresses start with a well known prefix. I believe it would be much simpler to simply use the definitions: IP6-address = hexpart [ ":" IP4-address ] IP4-address = decimal-uchar 3*( "." decimal-uchar ) IP4-unicast = IP4-address IP6-unicast = IP6-address IP4-multicast = IP4-address IP6-multicast = IP6-address And do the test "is this a multicast address" later, not during parsing. > -----Original Message----- > From: Sean Olson [mailto:sean.olson@ericsson.com] > Sent: Friday, October 27, 2000 12:47 AM > To: confctrl@isi.edu; sip@lists.bell-labs.com > Subject: [SIP] New I-D on SDP and IPv6 > > > Hello, > > There is a new Internet-Draft available on the use of IPv6 > addresses in SDP. The I-D simply clarifies the syntax to use > for representing an IPv6 address in an SDP description. > Any comments are welcome. > > http://www.ietf.org/internet-drafts/draft-olson-sdp-ipv6-00.txt > > Regards, > Sean Olson > > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Oct 27 18:36:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA21003 for ; Fri, 27 Oct 2000 18:36:03 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3E09A44343; Fri, 27 Oct 2000 17:36:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 6FBFE44337 for ; Fri, 27 Oct 2000 17:35:22 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id SAA21477; Fri, 27 Oct 2000 18:37:09 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <4WS2YCK0>; Fri, 27 Oct 2000 18:30:53 -0400 Message-ID: From: Jonathan Rosenberg To: "'David Shrader'" , Aparna.Vemuri@level3.com, andrew_s_duncan@agilent.com, sip@lists.bell-labs.com Subject: RE: [SIP] SIP and SIP-T distinction. MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 27 Oct 2000 18:30:52 -0400 > -----Original Message----- > From: David Shrader [mailto:dshrader@master-consultant.com] > Sent: Thursday, October 26, 2000 10:54 PM > To: Aparna.Vemuri@level3.com; andrew_s_duncan@agilent.com; > sip@lists.bell-labs.com > Subject: Re: [SIP] SIP and SIP-T distinction. > > > I don't think we should be treating SIP-T as a separate > protocol. There just > happen to be additional components to the message and you > either understand > them or you don't. If you don't understand something and you > don't need to > understand, then ignore it. If you do need to understand it, > then reject it. And make sure that, in the case of a body you don't understand, this rejection contains an Accept header listing allowed bodies, so that the UAC (a softswitch in this case), can resubmit the request without the additional data. It is critical that basic call establishment between any basic SIP entities be possible. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Oct 27 18:47:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA23356 for ; Fri, 27 Oct 2000 18:47:02 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B7E1044343; Fri, 27 Oct 2000 17:47:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mail.speedventures.com (unknown [212.75.74.99]) by lists.bell-labs.com (Postfix) with ESMTP id CCB9344336 for ; Fri, 27 Oct 2000 17:46:32 -0400 (EDT) Received: from superjudge (212.28.214.254 [212.28.214.254]) by mail.speedventures.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id V4SZ264S; Sat, 28 Oct 2000 00:42:13 +0200 Message-ID: <018201c04067$b128e3b0$fed61cd4@superjudge> From: "Johan Liseborn" To: "Jiri Kuthan" , References: <39F9FD53.113F64AB@fokus.gmd.de> Subject: Re: [SIP] Status of SIP Games MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sat, 28 Oct 2000 00:46:01 +0200 Content-Transfer-Encoding: 7bit > Back in August I saw an anouncement on the SIP mailing list > to bring SIP to network games. Is anybody working on it? Yes, we are currently working on a draft for network games using SIP and SDP. We hope to be able to present something before the next IETF meeting. We do also have some working implementations for setting up games such as Quake using our SIP clients. /johan -- Johan Liseborn CTO, Hotsip AB _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Oct 27 18:50:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA24014 for ; Fri, 27 Oct 2000 18:50:02 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E608D44343; Fri, 27 Oct 2000 17:50:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id CFB3744337 for ; Fri, 27 Oct 2000 17:49:33 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id SAA21550; Fri, 27 Oct 2000 18:51:38 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <4WS2YCLR>; Fri, 27 Oct 2000 18:45:22 -0400 Message-ID: From: Jonathan Rosenberg To: "'David Shrader'" , Anoop_Tripathi@3com.com, "Adam B. Roach" Cc: sip@lists.bell-labs.com, sip-events@egroups.com Subject: RE: [SIP] New SUBSCRIBE/NOTIFY draft available MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 27 Oct 2000 18:45:21 -0400 > -----Original Message----- > From: David Shrader [mailto:dshrader@master-consultant.com] > Sent: Thursday, October 26, 2000 10:44 PM > To: Anoop_Tripathi@3com.com; Adam B. Roach > Cc: sip@lists.bell-labs.com; sip-events@egroups.com > Subject: Re: [SIP] New SUBSCRIBE/NOTIFY draft available > > > I was also thinking that a BYE would cancel a subscription. > At least in the > context of an interaction begun with an INVITE, maybe that is > erroneous. > When SUBSCRIBE is outside the context of a call, it is not so > clear if BYE > is appropriate since the SUBSCRIBE, expires 0, ... method > would work like > cancelling a registration. No. BYE ends a session established by an INVITE. Thats it. SIP processing code becomes spagetti and impossible to maintain when the method has totally different semantics depending on the context. It is for this reason as well that I disagree with Adam's differing semantics of SUBSCRIBE for in call and out of call methods. SUBSCRIBE means one thing, and one thing only - I want to receive NOTIFYs on the changes in state of the object described in the request. > > On another note, is there really even a need for the Event: > header. Wouldn't > it be more flexible to simply state that if no Event: header > is present, > then you are subscribing to any events that the object > desires to expose? The event header is needed since a single entity can support publication of numerous types of data that depend on the context. In fact, differing servers might even be responsible for handling notifications and subscriptions to the data depending on its broad type. Having an Event header establishes a context of the subscription. It defines the basic meaning of the subscription in the absence of a body that further qualifies it. It needs to be a header since it can affect SIP routing. It helps tremendously to unify the various disparate uses of subscribe/notify we currently have. Michael Hammer writes: > What is not clear to me is that assuming that someone has > registered their > presence, and another is interested in subscribing/initiating > communications to that person, and the former's identity is > not already > known in some form to the latter, how does the latter > search/browse to find > the former? Is this assumed to be a directory operation > outside the scope > of SIP and IMPP? Yes, this is a directory issue outside of SIP. You have the same exact problem for email, and even for phone numbers. Thats why there is a white pages. But, white pages aren't part of SS7, and neither is LDAP corporate directories part of SMTP. Same here. Anoop Tripathi writes: > What is the difference between registering (REGISTER) for > an event and > subscribing (SUBSCRIBE) to an event? > I REGISTER to a proxy server to receive INVITE for my > calls or do I > SUBSCRIBE to my proxy server to NOTIFY me of my calls. No. SUBSCRIBE is not REGISTER. REGISTER has a very specific meaning - it establishes address bindings used in call routing, and sometimes acts as a form of configuration of initial user data (like uploading CPL). SUBSCRIBE means something different - I want to receive NOTIFYs of changes in the state of the SUBSCRIBEd object. I would strongly discourage overloading of any of the existing methods to be used for SUBSCRIBE. > All what I am trying to say is did we give enough > thoughts in this case > whether a header would suffice or a new message is required. None of the existing methods ask a server to send you NOTIFY messages when the state of an object changes. That is the semantic needed for a subscription. Thus, a new method is needed. > The reason why I ask this question is if tomorrow I come > up with a new > concept what would be the deciding factors for enhancing > REGISTER,SUBSCRIBE > or adding a new method. Headers can only qualify the behavior defined by the method. Think of it as a software excercise. When do you make somthing a class method, and when is it an argument to that method? Would you write a pub/sub API that looked like: action(SUBSCRIBE, targetname) or subscribe(targetname) I think any good software engineer would prefer the latter. Same is the case here. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sat Oct 28 18:39:11 2000 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA23561 for ; Sat, 28 Oct 2000 18:39:11 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1933F44337; Sat, 28 Oct 2000 17:39:06 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 2ECC844336 for ; Sat, 28 Oct 2000 17:38:39 -0400 (EDT) Received: from dynamicsoft.com (3Cust194.tnt18.tpa2.da.uu.net [63.21.176.194]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id SAA23443; Sat, 28 Oct 2000 18:40:44 -0400 (EDT) Message-ID: <39FB5484.5A7C94CE@dynamicsoft.com> From: Chris Harris Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: jainsip@sun.com Cc: sip@lists.bell-labs.com, discussion@sipforum.org Content-Type: multipart/alternative; boundary="------------853BAB417A8D87B9ACAA75F6" Subject: [SIP] JAIN SIP Meeting Results Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sat, 28 Oct 2000 15:34:44 -0700 --------------853BAB417A8D87B9ACAA75F6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear SIP community, The JAIN SIP Expert Group met on 24th October to discuss the comments that have been received since the specification moved into public review. One of the several issues discussed was whether to use classes of interfaces to define JAIN SIP messages and headers. The feeling in the meeting was that classes were either acceptable, but several other important pros and cons for each approach have been raised since then. I have included a summary of the pros and cons for the use of classes pointed out so far: Pros of Classes Cons of Classes Classes force implementation to Classes are better for application fully parse messages and headers portability because behaviour is before creating events - even if an fully defined in class. Interfaces application is only interested in may lead to subtle differences in one header. Interfaces allow behaviour if the API is not clear implementation to use optimisations enough in the underlying objects (differentiation between JAIN SIP products) Serialization of events can be defined correctly for all Classes force implementations to implementations with classes convert between proprietary objects (application can be in separate JVMand JAIN SIP objects, and determine to provider). Interfaces may make the implementation to a large serialized events very large extent - interfaces allow a wrapper (especially if optimisations such approach where the class hierrchy as delayed parsing are used by an is not determined by the API. implementation) An application can create messages and headers easily, since the classes are defined in the API. If interfaces are used, a factory is needed (but a factory mechanism is used anyway to obtain the particular JainSipStack implementation, so that problem exists either way) Other JAIN protocol API's use classes not interfaces - makes a more consistent architecture (But is this a good enough reason? maybe interfaces should have been used in other APIs?) If classes are used, Message can directly extend java.util.EventObject, but if Message is an interface, we need to create a MessageEvent class (which contains a Message) There are more pros for classes in this table, but they are not necessarily very good pros, and the cons could cause some serious problems. I personally find the interface approach more appropriate. I am hoping to get feedback on this issue soon. Regards, Chris --------------853BAB417A8D87B9ACAA75F6 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Dear SIP community,

The JAIN SIP Expert Group met on 24th October to discuss the comments that have been received since the specification moved into public review. One of the several issues discussed was whether to use classes of interfaces to define JAIN SIP messages and headers. The feeling in the meeting was that classes were either acceptable, but several other important pros and cons for each approach have been raised since then. I have included a summary of the pros and cons for the use of classes pointed out so far:
 

Pros of Classes Cons of Classes
Classes are better for application portability because behaviour is fully defined in class. Interfaces may lead to subtle differences in behaviour if the API is not clear enough Classes force implementation to fully parse messages and headers before creating events - even if an application is only interested in one header. Interfaces allow implementation to use optimisations in the underlying objects (differentiation between JAIN SIP products)
Serialization of events can be defined correctly for all implementations with classes (application can be in separate JVM to provider). Interfaces may make serialized events very large (especially if optimisations such as delayed parsing are used by an implementation)  Classes force implementations to convert between proprietary objects and JAIN SIP objects, and determine the implementation to a large extent - interfaces allow a wrapper approach where the class hierrchy is not determined by the API.
An application can create messages and headers easily, since the classes are defined in the API. If interfaces are used, a factory is needed (but a factory mechanism is used anyway to obtain the particular JainSipStack implementation, so that problem exists either way)
Other JAIN protocol API's use classes not interfaces - makes a more consistent architecture (But is this a good enough reason? maybe interfaces should have been used in other APIs?)
If classes are used, Message can directly extend java.util.EventObject, but if 
Message is an interface, we need to create a MessageEvent class (which contains a Message)

There are more pros for classes in this table, but they are not necessarily very good pros, and the cons could cause some serious problems. I personally find the interface approach more appropriate. I am hoping to get feedback on this issue soon.

Regards,
Chris --------------853BAB417A8D87B9ACAA75F6-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sun Oct 29 07:17:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA15505 for ; Sun, 29 Oct 2000 07:17:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9133A44337; Sun, 29 Oct 2000 06:17:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from prserv.net (out5.prserv.net [32.97.166.35]) by lists.bell-labs.com (Postfix) with ESMTP id 9867E44336 for ; Sun, 29 Oct 2000 05:02:44 -0500 (EST) Received: from attglobal.net ([139.92.151.66]) by prserv.net (out5) with SMTP id <20001029110225205026j4ige>; Sun, 29 Oct 2000 11:02:26 +0000 Message-ID: <39FC2651.A1F63A99@attglobal.net> From: Henning Schulzrinne Reply-To: hgschul@attglobal.net X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Kevin Lingle Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Some brief comments on the SIP MIB References: <39F7927C.1E4791D3@cs.columbia.edu> <39F9A718.C37F90A8@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sun, 29 Oct 2000 05:29:53 -0800 Content-Transfer-Encoding: 7bit Kevin Lingle wrote: > > Henning, > > Thanks for the comments. I presume they are based on the > draft-ietf-sip-mib-01.txt version of the I-D. Indeed. > > "Henning G. Schulzrinne" wrote: > > > > - The Hide configuration options are redundant; obviously, they are in > > RFC 2543, but I don't think it's useful to carry them forward. > > There are a couple of objects (in two different mib modules) that speak > about hiding. > > SIP-COMMON-MIB... sipHideOperation - clearly references rfc 2543. > SIP-SERVER-MIB... sipHideRespect. > > Are you suggesting we drop both of these objects? Yes. > > > > - ULS should probably at least mention LDAP as an example. > > ULS has undergone some changes. We had a request to handle prioritzed > backup addressess. I also got some comments that having one generic > ULS address wasn't sufficient. Systems may have multiple resources they > use to determine where users are. > > You can view the proposal on sip-mib@egroups.com archive > [http://www.egroups.com/message/sip-mib/40]. There has been no > feedback on the proposal yet (unfortunately that is typical). > I would appreciate if you could take a quick look. Btw, the > current proposal does not actualy handle prioritized addresses > correctly (i need to consider that further). What is your view > on having the ability to specify backup addresses ULS? Probably needs discussion by those building proxies, as I can primarily speak from our own experience. In our server, locations are derived from several different sources - LDAP - an SQL database for registrations - a set of user-configurable scripts that provide mappings from SIP user ids to other user id's, e.g., resolution of email aliases. While being able to change the LDAP URL via the management console is useful, I doubt that describing or changing the others is particularly helpful (and not likely to be feasible, given that just connecting to a different SQL server just doesn't magically make the table definitions appear there). Beyond the definition, the question is whether order matters. In our case, the order of resolution is given by the internal logic, basically variations on "if not found there, try the next one". > > > > - Supported URIs should probably say URI "schemes" rather than just > > URIs, as the current text can be read to imply to list all user SIP URIs > > managed by the server. > > I presume the comment relates to sipUriSupportedTable in SIP-COMMON-MIB, right? > I'm not clear on exactly where you would like the description changed: > in the sipUriSupportedTable description or in the description of the > sipUriSupported object itself? I think it was just the description. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sun Oct 29 09:43:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA11752 for ; Sun, 29 Oct 2000 09:43:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id EEB2D44337; Sun, 29 Oct 2000 08:43:05 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mars.hss.co.in (unknown [202.54.26.197]) by lists.bell-labs.com (Postfix) with ESMTP id 9A26D44336 for ; Sun, 29 Oct 2000 08:42:44 -0500 (EST) Received: from sampark.hss.hns.com (sampark [139.85.229.22]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id e9TEhFC26848 for ; Sun, 29 Oct 2000 20:13:17 +0530 (IST) Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 65256987.005127C2 ; Sun, 29 Oct 2000 20:16:25 +0530 X-Lotus-FromDomain: HSSBLR From: airoy@hss.hns.com To: sip@lists.bell-labs.com Message-ID: <65256987.005126F1.00@sampark.hss.hns.com> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [SIP] (no subject) Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sun, 29 Oct 2000 20:16:23 +0530 hi! I have a question on the syntax of the Referred-By header in draft-sip-cc-transfer-01.txt dated September 2000. The syntax for this is, ("Referred-By"|"b")":" referrer-url ";" referenced-url [";" ref-signature] referrer-url = SIP URL referenced-url = "ref" "="URL i am having a problem parsing this....Since referrer-url is SIP URL it can have urlparams which are semicolon separated "ref=" invariably maps to url params There is no way of knowing where the url parameters end. Is it possible to simplify the rule..like change that separator to a comma ?....normally only parameters within a header are semicolon separated, multiple fields of a similar structure within the same header are comma separated....going by this convention we could justify a shift form a semicolon separator to a comma separator in the referred-by header, to ensure consistency across the SIP ABNF. Or is the use of url params in this particular header allowed?..... regards, Ashok >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ashok I. Roy @hss.hns.com <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sun Oct 29 15:10:00 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA10093 for ; Sun, 29 Oct 2000 15:10:00 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0F36C44337; Sun, 29 Oct 2000 14:10:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id C72A444336 for ; Sun, 29 Oct 2000 14:09:44 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id PAA01087; Sun, 29 Oct 2000 15:10:40 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <4WS2YC9M>; Sun, 29 Oct 2000 15:04:20 -0500 Message-ID: From: Jonathan Rosenberg To: Igor Slepchin , "'Baniel Uri-CUB001'" , "'sip@lists.bell-labs.com'" Subject: RE: [SIP] Stateful proxy MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sun, 29 Oct 2000 15:04:15 -0500 You are correct. Thanks. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com > -----Original Message----- > From: Igor Slepchin > Sent: Thursday, October 26, 2000 6:04 PM > To: Jonathan Rosenberg; 'Baniel Uri-CUB001'; sip@lists.bell-labs.com > Subject: RE: [SIP] Stateful proxy > > > Actually, proxies are required to retransmit final INVITE > responses over TCP (see 10.5.2 in 2543bis). > > The problem happens in a slightly different scenario: > > TCP UDP > UA1 -------- Proxy --------- UA2 > > Here, a stateless proxy has TCP on the upstream and UDP on > the downstream. Since requests are not retransmitted over > TCP, the stateless Proxy will never retransmit the requests > over UDP link (Proxy->UA2). > > --- > Igor Slepchin > > > > -----Original Message----- > > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > Sent: Thursday, October 26, 2000 4:41 AM > > To: 'Baniel Uri-CUB001'; sip@lists.bell-labs.com > > Subject: RE: [SIP] Stateful proxy > > > > > > The situation comes up in a proxy which is TCP on the > > downstream side and > > UDP in the upstream side: > > > > UDP TCP > > UA1 -------- Proxy --------- UA2 > > > > Lets assume that this proxy is stateless, meaning that it > > holds the TCP > > connection state but otherwise does not store transaction > > state. According > > to the specification, INVITE responses are not retransmitted > > over TCP. So, > > UA2 sends its non-200 response, say a 400, just once over that TCP > > connection. The proxy receives this, and forwards it to UA1. > > Its lost. UA2 > > will not retransmit (since its TCP), and neither will the > > proxy, since its > > stateless, thus, the message is lost. > > > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sun Oct 29 15:57:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA20093 for ; Sun, 29 Oct 2000 15:57:01 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4FAD944337; Sun, 29 Oct 2000 14:57:05 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 8519844336 for ; Sun, 29 Oct 2000 14:56:07 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id PAA01126; Sun, 29 Oct 2000 15:58:10 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <4WS2YC94>; Sun, 29 Oct 2000 15:51:50 -0500 Message-ID: From: Jonathan Rosenberg To: "'Piotr S. Kossowski'" , SIP disscussion list Subject: RE: [SIP] possibly unintended recommendation for "tag" in 6.25 of the spec MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sun, 29 Oct 2000 15:51:45 -0500 > -----Original Message----- > From: Piotr S. Kossowski [mailto:P.Kossowski@elka.pw.edu.pl] > Sent: Thursday, October 26, 2000 4:03 PM > To: SIP disscussion list > Subject: [SIP] possibly unintended recommendation for "tag" in 6.25 of > the spec > > > Hello, > > During my studies on RFC2543bis-02, I've noticed following phrase: > > section 6.25: > > " The "tag" value MUST be globally unique and > cryptographically random > with at least 32 bits of randomness. A single user agent maintains the > same tag at least within the same Call-ID, but it is RECOMMENDED to > maintain the same tag across calls and instances of the UA > application > to allow restarting of a user agent. " > > On the one hand, we want tag to be globally unique to provide > matching in case of forking, on the other, this RECOMMENDATION would > damage to this tag-mechanism, in my opinion. Why ? As the spec. says, > instances of UA should (in recommendation meaning) have the same > tag. Let's assume that there are only ten "equal" vendors of > SIP-UAs in > the world. Eeach of them compiled its UA with cryptographically random > tag. According to probability principles, 10% of UAs instances in the > world WILL HAVE THE SAME TAG. It is probably NOT what we had > on our mind. > > But, don't argue about numbers. > I suppose, that author of this recommendation had on his mind > instances in meaning pair: {1.ran executable code 2.host, on which > this instance was run}, not {ran executable code} (common meaning). The meaning of instance is that if two UAs from the same vendor run on two machines, there are two instances. I'd ideally like that to be true even if two processes ran on the same machine, but the notion of maintaining tags across restarts doesn't make sense in such a context. Thus, computing the tag as a function of a machine specific invariant (IP address is a bad example, actually, since it might change on restart of the machine) is what you want. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sun Oct 29 16:06:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA22019 for ; Sun, 29 Oct 2000 16:06:01 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 10B9C44357; Sun, 29 Oct 2000 15:06:05 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 0232F44337 for ; Sun, 29 Oct 2000 15:05:04 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id QAA01143; Sun, 29 Oct 2000 16:07:13 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <4WS2YC9Y>; Sun, 29 Oct 2000 16:00:53 -0500 Message-ID: From: Jonathan Rosenberg To: "'Piotr S. Kossowski'" , sip@lists.bell-labs.com Subject: RE: [SIP] message retransmission - a need clarification MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sun, 29 Oct 2000 16:00:51 -0500 > -----Original Message----- > From: Piotr S. Kossowski [mailto:P.Kossowski@elka.pw.edu.pl] > Sent: Thursday, October 26, 2000 9:26 AM > To: sip@lists.bell-labs.com > Subject: [SIP] message retransmission - a need clarification > > > Hi All, > > I need some clarification on support of message retransission > on UAS side, > because it isn't explicite wrote in the spec, i think. > > First of all: > > 10.1.1 of the rfc 2543bis-02: > > "Servers discard ISOMORPHIC requests, but first retransmit > the appropriate > response. (SIP requests are said to be idempotent, i.e., > receiving more > than one copy of a request does not change the server state.)" > > For me it means that if UAS gets a message what it have already got > the last time it sends a response that it sent the last time, > independable of its current state. I think, for yet, it's clear. > > According to 1.3: > > "Two requests or responses are defined to be ISOMORPHIC for > the purposes > of this document if they have the same values for the > Call-ID, To, From > and CSeq header fields. In addition, isomorphic requests have to have > the same Request-URI and the same second branch parameter in their > top-most Via header." > > So, by definition, retransmission generates always Isomorphic request. > On the other hand, if, for example, UAC sends retransmitted message, > but it adds e.g. Subject header, what means that it is not > retransmission (it's not allowed without changing of CSeq, of > course), > for UAS this message is still ISOMORPHIC and must (should?) be > treated as a retransmission. Is it true ? Headers are not supposed to change on retransmissions. THus, if a UAC changes the subject or something, but keeps the Call_ID, To, From, CSeq, R-URI and top Via the same, the UAS or proxy still treats it as a retransmission, which means that the message with the modified Subject will not get forwarded downstream. > > Next: > > Let's assume that after INVITE from UAC, UAS sent final 603 (Decline) > response (without Retry-After), without eariler provisional response. > It probably means that UAS' user will not accept any call from the UAC > in the nearest future. Let's assume that this 603 message lost. > Thus, UAC retransmit the INVITE. It causes that UAS' user will be > bothered by incoming call again (it's of course > implemmentation matter). > Anyway, we don't want UAS to take up decission again (accept, reject, > redirect). So, UAS should keep information about no longer existed > calls in case of need of retransmission of response. And that's my > questions: > 1. Is it true ? Yes. > 2. If yes, how long (as I noticed, the spec says only about proxies > - 32 seconds. The only one such kind of timeout for UAS is > on figure > 12) ? Figure 12 explains it quite clearly, I think. You wait around for ACK, and then after that, 32 seconds. > > The last: > > 10.1.1 (again): > > "If the request is accepted and matches an existing call leg, > the server > compares the CSeq header field value. If LESS than or equal > to the current > sequence number, the request is a retransmission. > " > > It's said: LESS or equal. In case of equal - this message is > ISOMORPHIC > with last received message befor this one, and UAS sends > again response. > in case of LESS - ???. Should it retransmit something ? If yes, > what is ISOMORPHIC with what and how many messages must > 'remember" UAS ? It is a retramsission of a previous request, so you would follow the rules for that state machine for that request - if you're in the failure state, retransmit the response. In confirmed and completed, do nothing. Does this mean you need to remember the state machines for all requests always? Of course not. Once the machine has moved to completed, you know that the appropriate action is always "do nothing", so for any request with a CSeq less than the last received message, for which there is no state machine, do nothing. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sun Oct 29 22:32:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA16007 for ; Sun, 29 Oct 2000 22:32:01 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8358244337; Sun, 29 Oct 2000 21:32:05 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 6829044336 for ; Sun, 29 Oct 2000 21:31:29 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id WAA01660; Sun, 29 Oct 2000 22:33:22 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <4WS2YDCH>; Sun, 29 Oct 2000 22:27:01 -0500 Message-ID: From: Jonathan Rosenberg To: "'Adam Roach'" , Steve Donovan Cc: "'adam.roach@ericsson.com'" , "'sip@lists.bell-labs.com'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Subject: [SIP] RE: draft-ietf-sip-session-timer-02.txt Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sun, 29 Oct 2000 22:26:58 -0500 I know this email is ancient, but I am finally getting around to updating this. So, here are some comments: > -----Original Message----- > From: Adam Roach [mailto:adamr@yahoo.com] > Sent: Monday, July 31, 2000 4:01 PM > To: sdonovan@dynamicsoft.com; Jonathan Rosenberg > Cc: adam.roach@ericsson.com; sip@lists.bell-labs.com > Subject: draft-ietf-sip-session-timer-02.txt > > > In section 3, the draft specifies that the > exiration for delta times are defined as > "[the] delta time plus the time at which the > header is observed in a response." Presumably, > you mean "final response," right? It should > probably be more explict; further, some note > should be made about "Session-Expires" in > 1xx messages (if only to say that they are > disallowed). Updated to forbid Session-Expires in 1xx messages. > > In section 4, you specify that the lack of > require and session-timer headers in an > INVITE response imply that the UAC has no > further actions to take. This is somewhat > misleading. If, for example, the UAC sends > a "Supported: timer" header and a "Session-Expires" > header, but receives no timer indication in the > response, he still should be responsible for > initiating the periodic re-INVITEs for his > own use. I disagree. In this case, neither proxies nor the UAS are interested in the timer. Why send periodic re-INVITES if no one cares? > > The combination of the recommendation that BYE > is sent ten seconds before the end of the session > expires and the recommendation that sessions > be refreshed at halfway through the expiration > period leads to the conlusion that refresh periods > must be larger than 20 seconds. If this is an > acceptable consequence (and I think it is), it > should probably be stated that these refresh > periods should be large enough to accomodate these > plus some slop. I suggest that the draft > recommend that timeouts are no smaller than > 30 seconds. Hmm. I suspect some of the more telco-ish folks might think 30s is too long to detect failure of a call. I'll recommend 30s, but adjust the algorithm to make sure it still works for any arbitrarily small interval. > > The callflow that spans pages 11 and 12 shows > a circumstance where the calling UA requests > a timed session, and the SPS agrees to it. > You say that, after 120 seconds, the calling > UA decides not to refresh. However, since the > called UA understands the timer and agreed to > it (Require: timer), wouldn't he generally have > sent a BYE after 110 seconds? Am I missing > something? No, you're right. I changed it to 110 seconds. > > Section 8.6 shows a callflow that has no basis > in any description of the draft. I think you mean 8.7. > How, for > example, does the calling UA handle the > 420 response? Yes, this is fairly straightforward, > but I really think it should be outlined in > the text of the draft. Good point. This scenario is likely to be confusing for the UAC. Thats because it doesn't know session timer, didn't put a Require in the request, yet gets back a 420 Bad Extension. I recall we discussed this on the list and several people felt strongly about having the ability of proxies to put in Require despite this problem. > > Editorial comments: > > - The first paragraph on page 4 includes the phrase > "UAC and UAC" -- one of these should be "UAS." Fixed. > - Table 1 and Table 4 should be labeled. (What > happend to tables 2 and 3?) Fixed. > - On page 8, the paragraph starting "If the final > response..." contans the phrase "...and the proxy > remembers that the proxy did not support session > timer..." I imagine that the second "proxy" should > be "client." Fixed. > - Section 8.4, the first message from the SPS > to the called UA should have a "Require" header > in it (I think). No. Proxy insertion of Require is not recommended. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sun Oct 29 23:14:00 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA25947 for ; Sun, 29 Oct 2000 23:14:00 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 73B9044337; Sun, 29 Oct 2000 22:14:05 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mars.hss.co.in (unknown [202.54.26.197]) by lists.bell-labs.com (Postfix) with ESMTP id CEF4B44336 for ; Sun, 29 Oct 2000 22:13:49 -0500 (EST) Received: from sandesh.hss.hns.com (sandesh [139.85.242.35]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id e9U4EMC00107 for ; Mon, 30 Oct 2000 09:44:22 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256988.00163B66 ; Mon, 30 Oct 2000 09:32:49 +0530 X-Lotus-FromDomain: HSS From: apathak@hss.hns.com To: "'SIP discussion list'" Message-ID: <65256988.00163A25.00@sandesh.hss.hns.com> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [SIP] un-subscribe Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 30 Oct 2000 09:38:22 +0530 un-subscribe _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 30 00:32:30 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA08574 for ; Mon, 30 Oct 2000 00:32:24 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id EB4E444337; Sun, 29 Oct 2000 23:32:05 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from ms1.yeah.net (unknown [202.106.185.103]) by lists.bell-labs.com (Postfix) with ESMTP id BC50A44336 for ; Sun, 29 Oct 2000 23:31:04 -0500 (EST) Received: by ms1.yeah.net (Postfix, from userid 60001) id 74BF61C82FD6B; Mon, 30 Oct 2000 13:30:29 +0800 (CST) MIME-Version: 1.0 Message-Id: <39FD0775.01997@ms2> From: wang_aihua@yeah.net To: SIP@lists.bell-labs.com X-Priority: 3 X-Originating-IP: [211.100.33.212] Subject: [SIP] un_subscribe Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 30 Oct 2000 13:30:29 +0800 (CST) un_subscribe »¶Ó­Ê¹ÓÃÍøÒ×ÐÂÒ»´úËÑË÷ÒýÇæ http://search.163.com ÍøÒ×ÒýÇæ--Íø¾Û×ÊѶ¶¯Á¦£¡ _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 30 09:12:10 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA04066 for ; Mon, 30 Oct 2000 09:12:08 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1FA8C44337; Mon, 30 Oct 2000 08:12:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from eyeforthefuture.com (eyeforthefuture.com [216.122.88.93]) by lists.bell-labs.com (Postfix) with ESMTP id 6A74844336 for ; Sun, 29 Oct 2000 11:40:08 -0500 (EST) Received: from [208.61.13.129] (adsl-61-13-129.mia.bellsouth.net [208.61.13.129]) by eyeforthefuture.com (8.9.3/8.9.3) with ESMTP id JAA12734; Sun, 29 Oct 2000 09:35:49 -0800 (PST) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Subject: Re: [SIP] New SUBSCRIBE/NOTIFY draft available From: David Shrader To: Jonathan Rosenberg , SIP List , SIP Events List Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sun, 29 Oct 2000 12:32:21 -0500 Content-Transfer-Encoding: 7bit Jonathan Rosenberg writes: > BYE ends a session established by an INVITE. Thats it. SIP processing code > becomes spagetti and impossible to maintain when the method has totally > different semantics depending on the context. It is for this reason as well > that I disagree with Adam's differing semantics of SUBSCRIBE for in call and > out of call methods. SUBSCRIBE means one thing, and one thing only - I want > to receive NOTIFYs on the changes in state of the object described in the > request. What if the object being monitored ceases to exist? That is, I choose to monitor a call leg (from, to, call-id) and I am not a member of that call leg and the call ends. Does my subscription get cancelled? What if I subscribe to an object with a certain event package and the object (or its server) knows that the object has progressed to a certain state in which none of the events in the package can occur? Does anything happen to the subscription, or does it just sit in limbo? I think this is a more general version of the "object no longer exists" case above. Any thoughts? Perhaps both of these are solved on re-subscription. The recipient of the subscription request might reject the renewal if the object no longer exists or if the events can no longer occur. Of course, this reject code would only be possible when the subscription would have been authorized, otherwise we are potentially giving away state information to unauthorized requestors. David ---------------------------- David Shrader Master Consultant, Inc. dshrader@master-consultant.com http://www.EyeForTheFuture.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 30 09:14:07 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA04515 for ; Mon, 30 Oct 2000 09:14:06 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id EC24744356; Mon, 30 Oct 2000 08:12:14 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by lists.bell-labs.com (Postfix) with ESMTP id 07EE144336 for ; Sun, 29 Oct 2000 13:37:03 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5u3.ericy.com [208.237.135.124]) by imr1.ericy.com (8.9.3/8.9.3) with ESMTP id NAA22913; Sun, 29 Oct 2000 13:36:55 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr5.exu.ericsson.se (8.10.2/8.10.2) with ESMTP id e9TJZ3k07574; Sun, 29 Oct 2000 13:35:03 -0600 (CST) Received: from ericsson.com (arael25m062.ericsson.se [130.100.251.191]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id NAA02762; Sun, 29 Oct 2000 13:36:52 -0600 (CST) Message-ID: <39FC7C54.6A593069@ericsson.com> From: Sean Olson Organization: Ericsson Inc. X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Christian Huitema Cc: confctrl@isi.edu, sip@lists.bell-labs.com Subject: Re: [SIP] New I-D on SDP and IPv6 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sun, 29 Oct 2000 20:36:52 +0100 Content-Transfer-Encoding: 7bit > Christian Huitema wrote: > Why are you trying to syntactically prevent the use of IPv4 class E > addresses, or IPv4 addresses that terminate in ".0" ? These may not be > terribly useful, but a syntax description is the wrong place to do this kind > of controls. Besides, I can see why I would want in some cases to use a null > address, or an experimental anycast address. This is based on current text in RFC2327. I wasn't trying to be more restrictive or more liberal in what was allowed in an IPv4 address in SDP. The original ABNF was: IP4-address = b1 "." decimal-uchar "." decimal-uchar "." b4 b1 = decimal-uchar ;less than "224"; not "0" or "127" b4 = decimal-uchar ;not "0" I'm perfectly happy to remove these restrictions, but this is not the aim of this Internet-Draft. > > > Besides, the whole thing does not seem consistent. You don't spend the same > amount of effort to qualify the fact that there shall be at most 8 hexparts > in the IPv6 address, or that the IPv6 multicast addresses start with a well > known prefix. This was a compromise. It is easier to specify this for IPv4 than it is for IPv6 :) This is not the focus of the I-D either. I would be happy to simplify the v4 ABNF to its original form. > I believe it would be much simpler to simply use the > definitions: > > IP6-address = hexpart [ ":" IP4-address ] > IP4-address = decimal-uchar 3*( "." decimal-uchar ) > IP4-unicast = IP4-address > IP6-unicast = IP6-address > IP4-multicast = IP4-address > IP6-multicast = IP6-address I believe the distinction between the unicast and multicast syntax should be made clearer. I would be happy to revert to a simpler syntax as long as this distinction is highlighted. > > And do the test "is this a multicast address" later, not during parsing. > This is an implementation issue. The presence of the more restrictive ABNF is not an attempt to dictate the implementation of the parser. (In fact, as you note, it would be a poor implementation choice to strictly use the ABNF as posed for a parser.) But, the more precise ABNF is intended to clarify the distinction between the multicast and unicast syntax. Thanks for the comments. /sean > > > -----Original Message----- > > From: Sean Olson [mailto:sean.olson@ericsson.com] > > Sent: Friday, October 27, 2000 12:47 AM > > To: confctrl@isi.edu; sip@lists.bell-labs.com > > Subject: [SIP] New I-D on SDP and IPv6 > > > > > > Hello, > > > > There is a new Internet-Draft available on the use of IPv6 > > addresses in SDP. The I-D simply clarifies the syntax to use > > for representing an IPv6 address in an SDP description. > > Any comments are welcome. > > > > http://www.ietf.org/internet-drafts/draft-olson-sdp-ipv6-00.txt > > > > Regards, > > Sean Olson _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 30 09:22:53 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA06887 for ; Mon, 30 Oct 2000 09:22:53 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 70BC44435A; Mon, 30 Oct 2000 08:12:24 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cybertron.div8.net (el05-24-131-150-91.ce.mediaone.net [24.131.150.91]) by lists.bell-labs.com (Postfix) with ESMTP id 89FD444336 for ; Sun, 29 Oct 2000 23:17:24 -0500 (EST) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for sip@lists.bell-labs.com; Sun, 29 Oct 2000 23:17:01 -0600 (CST) From: Billy Biggs To: Henning Schulzrinne Cc: SIP List , "Piotr S. Kossowski" Subject: Re: [SIP] possibly unintended recommendation for "tag" in 6.25 of the spec Message-ID: <20001029231701.B30274@div8.net> References: <39F88E0B.2DF663CF@elka.pw.edu.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i In-Reply-To: <39F88E0B.2DF663CF@elka.pw.edu.pl>; from P.Kossowski@elka.pw.edu.pl on Thu, Oct 26, 2000 at 10:03:23PM +0200 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sun, 29 Oct 2000 23:17:01 -0600 Piotr S. Kossowski: > During my studies on RFC2543bis-02, I've noticed following phrase: > > section 6.25: > > "The "tag" value MUST be globally unique and cryptographically random > with at least 32 bits of randomness. A single user agent maintains the > same tag at least within the same Call-ID, but it is RECOMMENDED to > maintain the same tag across calls and instances of the UA application > to allow restarting of a user agent." Ouch. I would highly recommend removing the recommendation from the bis draft, since it breaks when you call yourself. Also, changing the local tag when following a redirect is a useful way of protecting against UAs which don't add tags. Also, as Piotr noted, I would be really scared that UAs would be more likely to choose the same tag if it was recommended that they try and preserve them across restarts. -- Billy Biggs, 3Com Email: Billy_Biggs@3com.com http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 30 09:28:47 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA08457 for ; Mon, 30 Oct 2000 09:28:46 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id AC5C044363; Mon, 30 Oct 2000 08:12:33 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lists.bell-labs.com (Postfix) with ESMTP id CFD0A44336 for ; Mon, 30 Oct 2000 02:18:28 -0500 (EST) Received: from ms.uab.ericsson.se (ms.uab.ericsson.se [134.138.201.16]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id e9U8IMt01610 for ; Mon, 30 Oct 2000 09:18:22 +0100 (MET) Received: from uabx04c384.uab.ericsson.se.uab.ericsson.se (uabx04c384 [134.138.229.144]) by ms.uab.ericsson.se (8.10.0/8.10.0/uab-2.26) with ESMTP id e9U8IMn06471 for ; Mon, 30 Oct 2000 09:18:22 +0100 (MET) Received: from uab.ericsson.se by uabx04c384.uab.ericsson.se.uab.ericsson.se (8.8.7/client-1.3uab1) id JAA18278; Mon, 30 Oct 2000 09:18:17 +0100 (MET) Message-ID: <39FD2EC3.D60B74EE@uab.ericsson.se> From: Bertil Engelholm Organization: Ericsson Utvecklings AB X-Mailer: Mozilla 4.74C-CCK-MCD [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: sv,en-US MIME-Version: 1.0 To: SIP@lists.bell-labs.com Subject: Re: [SIP] Transaction Identification, once again References: <8t9q4j$chb$1@lux2.datacom-lab.uab.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 30 Oct 2000 09:18:11 +0100 Content-Transfer-Encoding: 7bit Sofar noone have commented this "problem". So I send it again and hope someone can atleast say if it is regarded as a problem or if I have missed something. /Bertil Bertil Engelholm wrote: > > Hi again, > > I'm sorry to bring this up again but I just can't get things > to work in the correct way. I have read through the old threads > regarding this matter and still don't understand how it is > suppose to work. > > It's this example again : > > --------- -------- -------- > | a@c1 | -- INV u1@p1 --> | (s1) | -- INV u2@p2 --> | | > --------- (contact a@c1) | | | | > | p1 | | p2 | > --------- | | | | > | b@c2 | <- INV b@c2 ---- | (s2) | <- INV u3@p1 --- | | > --------- -------- -------- > > If P1 is stateful it might allocate one "call" state machine for > each path the "call" takes in P1 (s1 and s2 in the picture). > These two state machines are identified by the REQUEST-URI > that came in the two INVITEs since that's the only thing that > differs the two from each other. (topmost VIA also differs, > more about that later) > > P1 will now include the REQUEST-URI in the branch value it > generates so that the responses can be directed to the right > state machine when they arrive. And when the ACK is sent the > original REQUEST-URI from ROUTE is used. So no problems here. > > The problem I have is when b@C2 sends a new request (eg. BYE). > According to the specification b should/must/may (or whatever) > overwrite the REQUEST-URI in the ROUTE headers using the > REQUEST-URI from CONTACT or FROM. > > So how should P1 now be able to differ the two (BYE) requests > from each other ? The Original REQUEST-URI was the only thing > that P1 had to identify the two state machines. > > When reading the old threads regarding this matter I saw > something about using topmost VIA in some way, but how ? > > By using the topmost VIA you can see that they are two different > requests but how do you identify which state machine should receive > the first request. (Someone might argue that it doesn't matter but if > P1 controls a firewall it DO matter. Maybe not for BYE but for a > RE-INVITE it matters). > > -- > Bertil Engelholm > AXE Research and Development voice : +46 8 727 3499 > SIP Security Fax : +46 8 647 8276 > S-126 25 Stockholm Sweden E-mail: > Bertil.Engelholm@uab.ericsson.se > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip -- Bertil Engelholm AXE Research and Development voice : +46 8 727 3499 SIP Security Fax : +46 8 647 8276 S-126 25 Stockholm Sweden E-mail: Bertil.Engelholm@uab.ericsson.se _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 30 10:33:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA29584 for ; Mon, 30 Oct 2000 10:33:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3830044341; Mon, 30 Oct 2000 09:33:05 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from kahuna.westwave.com (gate.westwave.com [206.58.248.194]) by lists.bell-labs.com (Postfix) with ESMTP id 53AF244337 for ; Mon, 30 Oct 2000 09:32:04 -0500 (EST) Received: from westwave.com ([10.13.10.172]) by kahuna.westwave.com (Netscape Messaging Server 3.6) with ESMTP id AAA2520 for ; Mon, 30 Oct 2000 07:31:56 -0800 Message-ID: <39FD95CA.EF52D65E@westwave.com> From: "Chandra Kasinathan" Organization: Westwave Communications X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: SIP@lists.bell-labs.com Subject: [SIP] un-subscribe Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 30 Oct 2000 09:37:46 -0600 Content-Transfer-Encoding: 7bit un-subscribe _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 30 11:23:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA13077 for ; Mon, 30 Oct 2000 11:23:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2B3C544362; Mon, 30 Oct 2000 10:23:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by lists.bell-labs.com (Postfix) with ESMTP id 8A3D044361 for ; Mon, 30 Oct 2000 10:22:51 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5u3.ericy.com [208.237.135.124]) by imr1.ericy.com (8.9.3/8.9.3) with ESMTP id KAA00325; Mon, 30 Oct 2000 10:22:45 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr5.exu.ericsson.se (8.10.2/8.10.2) with ESMTP id e9UGKpk15574; Mon, 30 Oct 2000 10:20:51 -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 KAA26692; Mon, 30 Oct 2000 10:22:44 -0600 (CST) Received: (from eusadam@localhost) by b04a24.exu.ericsson.se (8.9.1/8.9.1) id KAA17756; Mon, 30 Oct 2000 10:22:47 -0600 (CST) Message-Id: <200010301622.KAA17756@b04a24.exu.ericsson.se> To: jdrosen@dynamicsoft.com (Jonathan Rosenberg) Cc: adamr@yahoo.com ('Adam Roach'), sdonovan@dynamicsoft.com (Steve Donovan), sip@lists.bell-labs.com ('sip@lists.bell-labs.com') In-Reply-To: from "Jonathan Rosenberg" at Oct 29, 2000 10:26:58 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 Subject: [SIP] Re: draft-ietf-sip-session-timer-02.txt Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 30 Oct 2000 10:22:46 -0600 (CST) Content-Transfer-Encoding: 7bit > I know this email is ancient, but I am finally > getting around to updating > this. So, here are some comments: ... > > > > In section 4, you specify that the lack of > > require and session-timer headers in an > > INVITE response imply that the UAC has no > > further actions to take. This is somewhat > > misleading. If, for example, the UAC sends > > a "Supported: timer" header and a > "Session-Expires" > > header, but receives no timer indication in the > > response, he still should be responsible for > > initiating the periodic re-INVITEs for his > > own use. > > I disagree. In this case, neither proxies nor the > UAS are interested in the > timer. Why send periodic re-INVITES if no one cares? Because the *UAC* is interested in knowing if the far side goes down. Perhaps a subtle point that isn't even necessarily related to the draft. > > Section 8.6 shows a callflow that has no basis > > in any description of the draft. > > I think you mean 8.7. Whoops! Yes, 8.7. > > How, for > > example, does the calling UA handle the > > 420 response? Yes, this is fairly straightforward, > > but I really think it should be outlined in > > the text of the draft. > > Good point. This scenario is likely to be confusing > for the > UAC. Thats because it doesn't know session timer, > didn't put > a Require in the request, yet gets back a 420 Bad > Extension. > I recall we discussed this on the list and several > people felt > strongly about having the ability of proxies to put > in Require > despite this problem. Yes. If you dig back in the archives to find the thread that started the whole session-refresh bit, you'll find that the entire initial motivation was to allow call-stateful proxies to have a sure-fire way to tell whether a call is up. Remember the proposal for the "PING" method? This is what came of those discussions. If the final result is that proxies cannot insist on some mechnanism to determine liveness of a call (not just a UA -- a *call* in particular), then this has been an academic exercise, as far as I'm concerned. The point I was attempting to make by this comment is that you should probably explicitly point out that the UAC will treat this 420 as any other 4xx class failure, and the call will not be set up. > > - Section 8.4, the first message from the SPS > > to the called UA should have a "Require" header > > in it (I think). > > No. Proxy insertion of Require is not recommended. "Since the proxy requires session timer..." would seem to imply that the proxy requires (not desires) a session timer. If the called party doesn't support the session timer, we need to have appropriate handling. I guess that this could be done by having the proxy note whether the response from the UAS contains the "Session-Expires" header, and adding it back in if not present. This situation (UAS doesn't support timer, UAC does, and proxy requires it) probably warrants its own call flow. In any case, shouldn't the called UA to SPS message contain a "Required" header to indicate that the timer is being used for this session? I thought this was the way that feature negotiation worked. -- 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 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 30 11:28:49 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA14397 for ; Mon, 30 Oct 2000 11:28:48 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6D94544369; Mon, 30 Oct 2000 10:24:05 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from is1-55.antd.nist.gov (is1-50.antd.nist.gov [129.6.50.251]) by lists.bell-labs.com (Postfix) with ESMTP id A428944368 for ; Mon, 30 Oct 2000 10:23:26 -0500 (EST) Received: from nist.gov (IDENT:mranga@stinkbug.antd.nist.gov [129.6.55.9]) by is1-55.antd.nist.gov (8.9.3/8.9.3) with ESMTP id LAA11619; Mon, 30 Oct 2000 11:18:29 -0500 (EST) Message-ID: <39FDA06C.838982AB@nist.gov> From: "M. Ranganathan" Reply-To: mranga@nist.gov Organization: NIST advanced networking technologies group X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: Chris Harris Cc: jainsip@sun.com, sip@lists.bell-labs.com, discussion@sipforum.org Subject: Re: [SIP] JAIN SIP Meeting Results References: <39FB5484.5A7C94CE@dynamicsoft.com> Content-Type: multipart/alternative; boundary="------------D096D5567C937F6BB006286C" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 30 Oct 2000 11:23:09 -0500 --------------D096D5567C937F6BB006286C Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: base64 Hi Chris: Thanks for posting this table. If we are taking a vote here, I vote for interfaces. If we want JAIN-SIP to propagate, we need to reduce the entry barrier for people who already have SIP implementations who may want to build a wrapper to make it JAIN-SIP compliant. (Your reason number 2 below in the right column.) I think this is the single most important reason to adopt interfaces. The first observation is also an interesting offshoot of using interfaces that I had not thought of. Unless I don't follow the argument, I don't think Reason #1 for pro's of classes is valid. Even with classes, there can be differences in implementation. There is a large semantic component in the design / implementation which a class cannot capture (and neither can an interface). That is precisely what a conformance test suite is good for. For Point # 2, column 1, where would serialization of events be used? I don't understand the second sentence either (why would interfaces make serialized events very large). Point #3, column 1 (using a factory for getting headers) is true but I don't see this as being a major hassle. Fundamentally, I would argue that Interfaces are the accepted Java mechanism for specifying design. It works remarkably well elsewhere so why break the paradigm? Another question - was there any discussion on where to put transaction support in the JAIN-SIP architecture (should this be part of the Stack or in a separate (optional) set of utility API. ? ) If there was consensus on this question then if possible, could you let me know what you all decided. Thanks Regards, Ranga. Chris Harris wrote: > Dear SIP community, > > The JAIN SIP Expert Group met on 24th October to discuss the comments > that have been received since the specification moved into public > review. One of the several issues discussed was whether to use classes > of interfaces to define JAIN SIP messages and headers. The feeling in > the meeting was that classes were either acceptable, but several other > important pros and cons for each approach have been raised since then. > I have included a summary of the pros and cons for the use of classes > pointed out so far: > > Pros of Classes Cons of Classes Classes force implementation to Classes are better for application fully parse messages and headers portability because behaviour is before creating events - even if an fully defined in class. Interfaces application is only interested in may lead to subtle differences in one header. Interfaces allow behaviour if the API is not clear implementation to use optimisations enough in the underlying objects (differentiation between JAIN SIP products) Serialization of events can be defined correctly for all Classes force implementations to implementations with classes convert between proprietary objects (application can be in separate JVM and JAIN SIP objects, and determine to provider). Interfaces may make the implementation to a large serialized events very large extent - interfaces allow a wrapper (especially if optimisations such approach where the class hierrchy as delayed parsing are used by an is not determined by the API. implementation) An application can create messages and headers easily, since the classes are defined in the API. If interfaces are used, a factory is needed (but a factory mechanism is used anyway to obtain the particular JainSipStack implementation, so that problem exists either way) Other JAIN protocol API's use classes not interfaces - makes a more consistent architecture (But is this a good enough reason? maybe interfaces should have been used in other APIs?) If classes are used, Message can directly extend java.util.EventObject, but if Message is an interface, we need to create a MessageEvent class (which contains a Message) > > There are more pros for classes in this table, but they are not > necessarily very good pros, and the cons could cause some serious > problems. I personally find the interface approach more appropriate. I > am hoping to get feedback on this issue soon. > > Regards, > Chris -- M.Ranganathan NIST Advanced Networking Technologies Group, 100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899. Tel: 301 975 3664 Fax: 301 590 0932 --------------D096D5567C937F6BB006286C Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Chris:

Thanks for posting this table.

If we are taking a vote here, I vote for interfaces.  If we want JAIN-SIP to propagate, we need to reduce the entry barrier for people who already have SIP implementations who may want to build a wrapper to make it JAIN-SIP compliant.  (Your reason number 2 below in the right column.)  I think this is the single most important reason to adopt interfaces.   The first observation is also an interesting offshoot of using interfaces that I had not thought of.

Unless I don't follow the argument,  I don't think Reason #1 for pro's of classes is valid. Even with classes,  there can be differences in implementation.  There is a large semantic component in the design / implementation which a class cannot capture (and neither can an interface). That is precisely what a conformance test suite is good for.

For Point # 2,  column 1, where would serialization of events be used?  I don't understand the second sentence either (why would interfaces make serialized events very large).

Point #3, column 1 (using a factory for getting headers)  is true but I don't see this as being a major hassle.

Fundamentally, I would argue that Interfaces are the accepted Java mechanism for specifying design. It works remarkably well elsewhere so why break the paradigm?

Another question - was there any discussion on where to put transaction support in the JAIN-SIP architecture (should this be part of the Stack  or in a separate (optional) set of  utility API. ? ) If there was consensus on this question then if possible, could you let me know what you all decided.

Thanks

Regards,

Ranga.
 

Chris Harris wrote:

Dear SIP community,

The JAIN SIP Expert Group met on 24th October to discuss the comments that have been received since the specification moved into public review. One of the several issues discussed was whether to use classes of interfaces to define JAIN SIP messages and headers. The feeling in the meeting was that classes were either acceptable, but several other important pros and cons for each approach have been raised since then. I have included a summary of the pros and cons for the use of classes pointed out so far:
 

Pros of Classes Cons of Classes
Classes are better for application portability because behaviour is fully defined in class. Interfaces may lead to subtle differences in behaviour if the API is not clear enough Classes force implementation to fully parse messages and headers before creating events - even if an application is only interested in one header. Interfaces allow implementation to use optimisations in the underlying objects (differentiation between JAIN SIP products)
Serialization of events can be defined correctly for all implementations with classes (application can be in separate JVM to provider). Interfaces may make serialized events very large (especially if optimisations such as delayed parsing are used by an implementation)  Classes force implementations to convert between proprietary objects and JAIN SIP objects, and determine the implementation to a large extent - interfaces allow a wrapper approach where the class hierrchy is not determined by the API.
An application can create messages and headers easily, since the classes are defined in the API. If interfaces are used, a factory is needed (but a factory mechanism is used anyway to obtain the particular JainSipStack implementation, so that problem exists either way)
Other JAIN protocol API's use classes not interfaces - makes a more consistent architecture (But is this a good enough reason? maybe interfaces should have been used in other APIs?)
If classes are used, Message can directly extend java.util.EventObject, but if 
Message is an interface, we need to create a MessageEvent class (which contains a Message)

There are more pros for classes in this table, but they are not necessarily very good pros, and the cons could cause some serious problems. I personally find the interface approach more appropriate. I am hoping to get feedback on this issue soon.

Regards,
Chris

-- 
M.Ranganathan
NIST Advanced Networking Technologies Group,
100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899. 
Tel: 301 975 3664 Fax: 301 590 0932
  --------------D096D5567C937F6BB006286C-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 30 11:39:35 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA17345 for ; Mon, 30 Oct 2000 11:39:35 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2A46244369; Mon, 30 Oct 2000 10:39:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by lists.bell-labs.com (Postfix) with ESMTP id 6EE3444361 for ; Mon, 30 Oct 2000 10:38:14 -0500 (EST) Received: from mr4u3.ericy.com (mr4u3.ericy.com [208.237.135.127]) by imr1.ericy.com (8.9.3/8.9.3) with ESMTP id KAA10932; Mon, 30 Oct 2000 10:38:08 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr4u3.ericy.com (8.9.3/8.9.3) with ESMTP id KAA27530; Mon, 30 Oct 2000 10:38:08 -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 KAA29560; Mon, 30 Oct 2000 10:38:07 -0600 (CST) Received: (from eusadam@localhost) by b04a24.exu.ericsson.se (8.9.1/8.9.1) id KAA17849; Mon, 30 Oct 2000 10:38:12 -0600 (CST) Message-Id: <200010301638.KAA17849@b04a24.exu.ericsson.se> Subject: Re: [sip-events] Re: [SIP] New SUBSCRIBE/NOTIFY draft available To: sip-events@egroups.com Cc: jdrosen@dynamicsoft.com (Jonathan Rosenberg), sip@lists.bell-labs.com (SIP List) In-Reply-To: from "David Shrader" at Oct 29, 2000 12:32:21 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: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 30 Oct 2000 10:38:11 -0600 (CST) Content-Transfer-Encoding: 7bit David Shrader writes: >What if the object being monitored ceases to exist? That is, I choose to >monitor a call leg (from, to, call-id) and I am not a member of that call >leg and the call ends. Does my subscription get cancelled? This problem appears to be solved if we add a general mechanism by which notifiers can send a general "this subscription is now over" NOTIFY message, as has been proposed. I intend to add this mechanism to future version of the draft. -- 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 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 30 12:21:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA26882 for ; Mon, 30 Oct 2000 12:21:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1689E44358; Mon, 30 Oct 2000 11:21:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from is1-55.antd.nist.gov (is1-50.antd.nist.gov [129.6.50.251]) by lists.bell-labs.com (Postfix) with ESMTP id A919144348 for ; Mon, 30 Oct 2000 11:20:48 -0500 (EST) Received: from nist.gov (IDENT:mranga@stinkbug.antd.nist.gov [129.6.55.9]) by is1-55.antd.nist.gov (8.9.3/8.9.3) with ESMTP id MAA12834; Mon, 30 Oct 2000 12:16:00 -0500 (EST) Message-ID: <39FDADE7.66C2350A@nist.gov> From: "M. Ranganathan" Reply-To: mranga@nist.gov Organization: NIST advanced networking technologies group X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: vkg@lucent.com Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Forwarding SIP Invites -- how to decide transport. References: <39F991C8.3E472874@nist.gov> <39F9967D.220EAC04@lucent.com> Content-Type: multipart/alternative; boundary="------------B674BAF6D4D0610E77E94DCD" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 30 Oct 2000 12:20:39 -0500 --------------B674BAF6D4D0610E77E94DCD Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: base64 Vijay, Thanks for your reply. The section you refer to says (forgive me if I sound like a lawyer here!) : (For socket-based programs: For TCP, connect() returns ECONNREFUSED if the client could not connect to a server at that address. For UDP, the socket needs to be bound to the destination address using connect() rather than sendto() or similar so that a second write() fails with ECONNREFUSED if there is no server listening) If the client finds the server is not reachable at a particular address, it SHOULD behave as if it had received a 400-class error response to that request. So the proxy is supposed to send UDP packets with a connect and a send and then do a *second* send and then use TCP if the UDP attempt fails? How does it know the UDP attempt has failed (especially when the ACK can bypass the proxy) ? I thought UDP connect was just a programming convenience (maybe I am wrong) and does not check to see if there is a client on the recieving end that will get the udp packet. Thanks Regards, Ranga. "Vijay K. Gurbani" wrote: > "M. Ranganathan" wrote: > > > > Greetings (and Happy Diwali if it applies to you) !! > > Yes, it does. Same to you as well :-) > > > I have a simple question regarding how to choose between tcp and udp > > when forwarding invites. Lets say we have the following scenario: > [...] > >Oops I goofed a bit on that one. The first REGISTER header does not >specify a tranansport for the contact and it should be : > > > >REGISTER sip:129.6.55.9 SIP/2.0 > >Via: SIP/2.0/TCP 129.6.55.9:1030 > [...] > >Contact: > [...] > > Take a look at the section 1.4.2 (bis) -- it details the steps on > locating a SIP server. Since your example uses IP addresses directly, > P should try UDP first; if that attempt failed, it should try TCP. Re- > call that proxies MUST support both TCP and UDP, so before failing the > call entirely, P should try both transports (and SCTP if it supports > it). If your example did not have IP addresses, P could have queried > DNS for SRV records for all transports supported by it and ordered these > based on priority (see step 5 in section 1.4.2). > > BTW, your earlier Contact header's syntax was in error, I think. It was > listed as: > > Contact: ;transport=tcp;q=0 > > It should be: > > Contact: ;q=0 > > Contact does not have transport parameter, addr-spec does. Contact > only has q, action, expires and contact-extension parameters (I suppose > you could make the case that transport=tcp was a contact-extension > parameter...) > > Regards, > > - vijay > -- > Vijay K. Gurbani vkg@lucent.com vkg@research.bell-labs.com vkg@acm.org > Internet Software Group/Intelligent Network and Messaging Systems > Lucent Technologies/Bell Labs Innovations, 263 Shuman Blvd, Rm 1A-413 > Naperville, Illinois 60566 Voice: +1 630 224 0216 Fax: +1 630 713 0184 -- M.Ranganathan NIST Advanced Networking Technologies Group, 100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899. Tel: 301 975 3664 Fax: 301 590 0932 --------------B674BAF6D4D0610E77E94DCD Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Vijay,

Thanks for your reply.  The section you refer to says  (forgive me if I sound like a lawyer here!) :
 

 (For socket-based
   programs: For TCP, connect() returns ECONNREFUSED if the client could
   not connect to a server at that address. For UDP, the socket needs to
   be bound to the destination address using connect() rather than
   sendto() or similar so that a second write() fails with ECONNREFUSED
   if there is no server listening) If the client finds the server is
   not reachable at a particular address, it SHOULD behave as if it had
   received a 400-class error response to that request.
 

So the proxy is supposed to send UDP packets with a connect and a send and then do a *second* send and then use TCP if the UDP attempt fails? How does it know the UDP attempt has failed (especially when the ACK can bypass the proxy) ?
 

I thought UDP connect was just a programming convenience (maybe I am wrong) and does not check to see if there is a client on the recieving end that will get the udp packet.

Thanks

Regards,

Ranga.
 

"Vijay K. Gurbani" wrote:

"M. Ranganathan" wrote:
>
> Greetings  (and Happy Diwali if it applies to you)  !!

Yes, it does.  Same to you as well :-)

> I have a simple question regarding how to choose between tcp and udp
> when forwarding invites. Lets say we have the following scenario:
[...]
>Oops I goofed a bit on that one. The first REGISTER  header  does  not >specify a tranansport for the contact and it should be :
>
>REGISTER sip:129.6.55.9 SIP/2.0
>Via: SIP/2.0/TCP 129.6.55.9:1030
[...]
>Contact: <sip:mranga@129.6.55.9:6060>
[...]

Take a look at the section 1.4.2 (bis) -- it details the steps on
locating a SIP server.  Since your example uses IP addresses directly,
P should try UDP first; if that attempt failed, it should try TCP.  Re-
call that proxies MUST support both TCP and UDP, so before failing the
call entirely, P should try both transports (and SCTP if it supports
it).  If your example did not have IP addresses, P could have queried
DNS for SRV records for all transports supported by it and ordered these
based on priority (see step 5 in section 1.4.2).

BTW, your earlier Contact header's syntax was in error, I think.  It was
listed as:

  Contact: <sip:mranga@129.6.55.9:6060>;transport=tcp;q=0

It should be:

  Contact: <sip:mranga@129.6.55.9:6060;transport=tcp>;q=0

Contact does not have transport parameter, addr-spec does.  Contact
only has q, action, expires and contact-extension parameters (I suppose
you could make the case that transport=tcp was a contact-extension
parameter...)

Regards,

- vijay
--
Vijay K. Gurbani  vkg@lucent.com vkg@research.bell-labs.com vkg@acm.org
Internet Software Group/Intelligent Network and Messaging Systems
Lucent Technologies/Bell Labs Innovations, 263 Shuman Blvd, Rm 1A-413
Naperville, Illinois 60566  Voice: +1 630 224 0216 Fax: +1 630 713 0184

-- 
M.Ranganathan
NIST Advanced Networking Technologies Group,
100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899. 
Tel: 301 975 3664 Fax: 301 590 0932
  --------------B674BAF6D4D0610E77E94DCD-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 30 12:52:06 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA03836 for ; Mon, 30 Oct 2000 12:52:06 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 357A444348; Mon, 30 Oct 2000 11:52:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by lists.bell-labs.com (Postfix) with ESMTP id 87D8544337 for ; Mon, 30 Oct 2000 11:51:14 -0500 (EST) Received: from mr4u3.ericy.com (mr4u3.ericy.com [208.237.135.127]) by imr1.ericy.com (8.9.3/8.9.3) with ESMTP id LAA00178; Mon, 30 Oct 2000 11:51:05 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr4u3.ericy.com (8.9.3/8.9.3) with ESMTP id LAA12437; Mon, 30 Oct 2000 11:51:04 -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 LAA04524; Mon, 30 Oct 2000 11:51:03 -0600 (CST) Received: (from eusadam@localhost) by b04a24.exu.ericsson.se (8.9.1/8.9.1) id LAA18029; Mon, 30 Oct 2000 11:20:12 -0600 (CST) Message-Id: <200010301720.LAA18029@b04a24.exu.ericsson.se> Subject: Re: [SIP] New SUBSCRIBE/NOTIFY draft available To: mhammer@cisco.com (hammer michael) Cc: sip@lists.bell-labs.com, sip-events@egroups.com In-Reply-To: <4.3.2.7.2.20001026135909.00b373f0@cia.cisco.com> from "hammer michael" at Oct 26, 2000 02:14:55 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: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 30 Oct 2000 11:20:12 -0600 (CST) Content-Transfer-Encoding: 7bit >Sec 5.1.5, assume "must" = "MUST" Thanks. This is going away with the distinction beween third-party and call-party subscriptions. >Sec 5.1.6, para 7: Would immediate fetch while subscription pending be >some type of 18x response? No. It would be a 200 response, as in a normal subscription refresh. >Sec 5.1.6, para 8: Implies that one must subscribe before one can >subscribe, seems recursive. Could one assume that the resource to which >one would be subscribing would have already registered and that the >registration would have already defined the basis for access, e.g. >restricted list or promiscuous (open to anyone)? I'm not sure what you mean by this. If I have a client running, and you want to subscribe to some state in it, I might expect it to interactively ask me, for each subscription, if I wish to allow the subscription to be processed. I would assume you mean this paragraph: "Note that privacy concerns may require that notifiers either use access lists or ask the user on a per-subscription basis whether a particular remote node is allowed to subscribe to a certain set of events. If such authorization fails, the notifier should reply to the request with a "403 Forbidden" request. See section 7." Perhaps your confusion stems from what, exactly, is meant by "user." In this context, I meant the owner of the node that is being asked to act as a notifier. You may have read it such that it means the owner of the node acting as a subscriber. I'll attempt to clarify this text in the next draft. >Sec. 5.2.2, para 8: If the assumption is that configuration is done out of >band, why not assume that the subscribe will be static provisioned and >would therefore submit the SUBSCRIBE before the NOTIFY. That could obviate >the need for Notify without Subscription. This mechanism is based on the same concept as third-party REGISTER messages. My client may never send a SUBSCRIBE, but might receive NOTIFY responses. I'm merely pointing out that such a mechanism makes sense. >Sec 5.2.3: Could repeated non-ACK of Notifies be used before cancelling a >subscription. It seems the subscription would be rather fragile under >unreliable network conditions. That might be rather service-dependant. I >would not want a long-running subscription to a non-call-related service to >terminate just because I turned my computer off. In mobile environments, >one could think of other cases where communications may be interrupted. This is solved by periodic subscription refreshes, just like registrations. In the situation you cite (turning your computer off), the subscription will be re-instantiated by your client when you start it up again. -- 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 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 30 12:53:47 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA04223 for ; Mon, 30 Oct 2000 12:53:46 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8032744371; Mon, 30 Oct 2000 11:52:18 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by lists.bell-labs.com (Postfix) with ESMTP id 80E3244337 for ; Mon, 30 Oct 2000 11:51:21 -0500 (EST) Received: from mr4u3.ericy.com (mr4u3.ericy.com [208.237.135.127]) by imr1.ericy.com (8.9.3/8.9.3) with ESMTP id LAA00208; Mon, 30 Oct 2000 11:51:10 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr4u3.ericy.com (8.9.3/8.9.3) with ESMTP id LAA12447; Mon, 30 Oct 2000 11:51:05 -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 LAA04528; Mon, 30 Oct 2000 11:51:05 -0600 (CST) Received: (from eusadam@localhost) by b04a24.exu.ericsson.se (8.9.1/8.9.1) id LAA17983; Mon, 30 Oct 2000 11:03:15 -0600 (CST) Message-Id: <200010301703.LAA17983@b04a24.exu.ericsson.se> Subject: Re: [SIP] New SUBSCRIBE/NOTIFY draft available To: jdrosen@dynamicsoft.com (Jonathan Rosenberg) Cc: huitema@microsoft.com, sip@lists.bell-labs.com, sip-events@egroups.com In-Reply-To: from "Jonathan Rosenberg" at Oct 26, 2000 06:11:27 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: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 30 Oct 2000 11:03:13 -0600 (CST) Content-Transfer-Encoding: 7bit >> >1) the IMPP draft defines that "SUBSCRIBE" creates a >> subscription session, >> >identified by its own Call-Id. The session expires when the >> life time of the >> >subscribe expires before being renewed by another subscribe >> for the same >> >call-id, or if the subscriber sends a subscribe with a null >> lifetime. >> >> This is what I describe as "third-party" subscriptions. ... >I agree with Christian on this one - that is, I think the semantics of a >subscription are always the same. A subscription may or may not appear with >the same To/From/Call-ID as an existing call leg, and that does not change >at all how one subscribes to something. The body always specifies details of >the thing being subscribed to, within the context of the package defined in >the Event header. What you are doing here with call-leg related >subscriptions is a short cut mechanism to describe the event you are >subscribing to. I'd rather keep everything uniform. Okay, this appears to be a popular sentiment. In the interest of making implementations cleaner, I believe I'll remove this distinction in future versions of the draft. If anyone has any objections to removing this, speak up now. >> >4) In the IMMP discussion, we also agreed that the >> publisher/presentity >> >should be able to terminate a subscription at any time, and >> should be able >> >to report this event in a Notify. >> >> Thank you; this is apparently a feature I overlooked. I will add >> this in an upcoming version of the draft. > >Its actually not specified right now in draft-rosenberg-impp-presence, but >is rather something that has been discussed on the lists and other places. It makes certain issues much more palatable (e.g. what happens at the end of a call if there are call-related subscriptions pending?) Once again, popular sentiment appears to go against the distinction between call-related an non-call-related event subscriptions. I'll remove it. This does raise the issue of whether legs which are used for an ongoing session can be used for SUBSCRIBE/NOTIFY messages. The presence draft prohibits them, although the rationale isn't described. >> My hope is that, once the events draft is complete, the presence >> draft will be somewhat thinner, and have the luxury of concentrating >> on presence instead of event notification. If you feel that there >> are any generally applicable features included in the presence >> draft which I have failed to clearly incorporate in my draft, please >> point them out. > >I believe that, in general, your draft is more or less the distillation of >the presence draft, modulo the above issues plus one more. > >That additional issue centers around your statement: > > > Since forking proxies pass all 200 responses upstream, it is > expected that these "From" fields will not contain any tags which > are unknown to the subscriber. However, to make the subscription > mechanism more robust, subscribers SHOULD be prepared to receive > notifications with previously unknown tags in the "From" field. > >Your assumption here is false. For non-INVITE methods, there is only a >single 200 OK passed upstream. This was changed between the bis-00 and bis-01 drafts. I will update my draft to reflect this change. Compare section 12.4, "Forking Proxies": "2xx: The proxy MUST forward the response upstream towards the client, without sending an ACK downstream." ...versus... "2xx: If the request was an INVITE, the proxy MUST forward the response upstream towards the client, without sending an ACK downstream. For other requests, it should only forward the response upstream if it has not forwarded any other responses upstream." Note that this has the horrible, horrible side effect that I can receive a 6xx (or, in timeout situations, even 4xx-5xx responses) to a SUBSCRIBE request, never see a 200, and still have valid outstanding subscriptions. I dislike this behaviour. Why do we do something so radically different for INVITE than for anything else? Yes, I know it's needed for cleaner ACK handling, but what harm comes from *always* proxying 200-class responses regardless of the method? As none of us know what the nature of future methods might be, I beleive this is folly. >Besides this issue, and the ones above regarding call-leg specific >subscriptions, I believe there is nothing different between the two (to put >it in Adam's terms, the presence draft is a concrete implementation of the >abstract class defined in his draft, without overriding any of its methods >:) ) I need to go over both with a fine tooth comb to be sure, however. Actually, I think the presence draft still has a bunch of behavior which I didn't capture, but still needs to be described somewhere. The descripiton of presentities that serve as representives of UAs for the purpose of user presence is still a concept that needs to be defined. Several similar issues dealing explicity with presence (and not async events in general) were also intentionally left behind. -- 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 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 30 13:11:10 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA08798 for ; Mon, 30 Oct 2000 13:11:09 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E5CA044377; Mon, 30 Oct 2000 12:11:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 05A2844370 for ; Mon, 30 Oct 2000 12:10:40 -0500 (EST) Received: from dynamicsoft.com (useraa67.ie.uudial.com [212.120.133.68]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id NAA07126; Mon, 30 Oct 2000 13:12:36 -0500 (EST) Message-ID: <39FDB8A9.5BE28985@dynamicsoft.com> From: Chris Harris Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: mranga@nist.gov Cc: jainsip@sun.com, sip@lists.bell-labs.com, discussion@sipforum.org Subject: Re: [SIP] JAIN SIP Meeting Results References: <39FB5484.5A7C94CE@dynamicsoft.com> <39FDA06C.838982AB@nist.gov> Content-Type: multipart/alternative; boundary="------------A7BC668A142D2C31327364F8" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 30 Oct 2000 18:06:34 +0000 --------------A7BC668A142D2C31327364F8 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Ranga, Thanks for the feedback - comments below. Chris "M. Ranganathan" wrote: > Hi Chris: > > Thanks for posting this table. > > If we are taking a vote here, I vote for interfaces. If we want > JAIN-SIP to propagate, we need to reduce the entry barrier for people > who already have SIP implementations who may want to build a wrapper > to make it JAIN-SIP compliant. (Your reason number 2 below in the > right column.) I think this is the single most important reason to > adopt interfaces. The first observation is also an interesting > offshoot of using interfaces that I had not thought of. > > Unless I don't follow the argument, I don't think Reason #1 for pro's > of classes is valid. Even with classes, there can be differences in > implementation. There is a large semantic component in the design / > implementation which a class cannot capture (and neither can an > interface). That is precisely what a conformance test suite is good > for. Absolutely true. > > > For Point # 2, column 1, where would serialization of events be > used? I don't understand the second sentence either (why would > interfaces make serialized events very large). I was thinking about the case where the Provider and Listener are not in the same JVM. But then the Listener/Provider model doesn't really handle multiple JVMs very well anyway. > > > Point #3, column 1 (using a factory for getting headers) is true but > I don't see this as being a major hassle. > > Fundamentally, I would argue that Interfaces are the accepted Java > mechanism for specifying design. It works remarkably well elsewhere so > why break the paradigm? > > Another question - was there any discussion on where to put > transaction support in the JAIN-SIP architecture (should this be part > of the Stack or in a separate (optional) set of utility API. ? ) If > there was consensus on this question then if possible, could you let > me know what you all decided. The current mechanism of having transaction id's generated by the Provider was considered reasonable - except that the id should be an int rather than a String - since it is completely opaque to the application anyway, and int comparisons are more efficient. It was concluded that the number of SIP applications not interested in transactions is a tiny fraction (stateless proxy being the only example we came up with - and JAIN SIP would certainly not be use to write this) > > > Thanks > > Regards, > > Ranga. > > > Chris Harris wrote: > >> Dear SIP community, >> >> The JAIN SIP Expert Group met on 24th October to discuss the >> comments that have been received since the specification moved into >> public review. One of the several issues discussed was whether to >> use classes of interfaces to define JAIN SIP messages and headers. >> The feeling in the meeting was that classes were either acceptable, >> but several other important pros and cons for each approach have >> been raised since then. I have included a summary of the pros and >> cons for the use of classes pointed out so far: >> >> Pros of Classes Cons of Classes Classes force implementation to Classes are better for application fully parse messages and headers portability because behaviour is before creating events - even if an fully defined in class. Interfaces application is only interested in may lead to subtle differences in one header. Interfaces allow behaviour if the API is not clear implementation to use optimisations enough in the underlying objects (differentiation between JAIN SIP products) Serialization of events can be defined correctly for all Classes force implementations to implementations with classes convert between proprietary objects (application can be in separate JVM and JAIN SIP objects, and determine to provider). Interfaces may make the implementation to a large serialized events very large extent - interfaces allow a wrapper (especially if optimisations such approach where the class hierrchy as delayed parsing are used by an is not determined by the API. implementation) An application can create messages and headers easily, since the classes are defined in the API. If interfaces are used, a factory is needed (but a factory mechanism is used anyway to obtain the particular JainSipStack implementation, so that problem exists either way) Other JAIN protocol API's use classes not interfaces - makes a more consistent architecture (But is this a good enough reason? maybe interfaces should have been used in other APIs?) If classes are used, Message can directly extend java.util.EventObject, but if Message is an interface, we need to create a MessageEvent class (which contains a Message) >> >> There are more pros for classes in this table, but they are not >> necessarily very good pros, and the cons could cause some serious >> problems. I personally find the interface approach more appropriate. >> I am hoping to get feedback on this issue soon. >> >> Regards, >> Chris > > -- > M.Ranganathan > NIST Advanced Networking Technologies Group, > 100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899. > Tel: 301 975 3664 Fax: 301 590 0932 > > --------------A7BC668A142D2C31327364F8 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Ranga,

Thanks for the feedback - comments below.

Chris

"M. Ranganathan" wrote:

Hi Chris:

Thanks for posting this table.

If we are taking a vote here, I vote for interfaces.  If we want JAIN-SIP to propagate, we need to reduce the entry barrier for people who already have SIP implementations who may want to build a wrapper to make it JAIN-SIP compliant.  (Your reason number 2 below in the right column.)  I think this is the single most important reason to adopt interfaces.   The first observation is also an interesting offshoot of using interfaces that I had not thought of.

Unless I don't follow the argument,  I don't think Reason #1 for pro's of classes is valid. Even with classes,  there can be differences in implementation.  There is a large semantic component in the design / implementation which a class cannot capture (and neither can an interface). That is precisely what a conformance test suite is good for.

Absolutely true.
 

For Point # 2,  column 1, where would serialization of events be used?  I don't understand the second sentence either (why would interfaces make serialized events very large).

I was thinking about the case where the Provider and Listener are not in the same JVM. But then the Listener/Provider model doesn't really handle multiple JVMs very well anyway.
 

Point #3, column 1 (using a factory for getting headers)  is true but I don't see this as being a major hassle.

Fundamentally, I would argue that Interfaces are the accepted Java mechanism for specifying design. It works remarkably well elsewhere so why break the paradigm?

Another question - was there any discussion on where to put transaction support in the JAIN-SIP architecture (should this be part of the Stack  or in a separate (optional) set of  utility API. ? ) If there was consensus on this question then if possible, could you let me know what you all decided.

The current mechanism of having transaction id's generated by the Provider was considered reasonable - except that the id should be an int rather than a String - since it is completely opaque to the application anyway, and int comparisons are more efficient. It was concluded that the number of SIP applications not interested in transactions is a tiny fraction (stateless proxy being the only example we came up with - and JAIN SIP would certainly not be use to write this)
 

Thanks

Regards,

Ranga.
 

Chris Harris wrote:

Dear SIP community,

The JAIN SIP Expert Group met on 24th October to discuss the comments that have been received since the specification moved into public review. One of the several issues discussed was whether to use classes of interfaces to define JAIN SIP messages and headers. The feeling in the meeting was that classes were either acceptable, but several other important pros and cons for each approach have been raised since then. I have included a summary of the pros and cons for the use of classes pointed out so far:
 

Pros of Classes Cons of Classes
Classes are better for application portability because behaviour is fully defined in class. Interfaces may lead to subtle differences in behaviour if the API is not clear enough Classes force implementation to fully parse messages and headers before creating events - even if an application is only interested in one header. Interfaces allow implementation to use optimisations in the underlying objects (differentiation between JAIN SIP products)
Serialization of events can be defined correctly for all implementations with classes (application can be in separate JVM to provider). Interfaces may make serialized events very large (especially if optimisations such as delayed parsing are used by an implementation)  Classes force implementations to convert between proprietary objects and JAIN SIP objects, and determine the implementation to a large extent - interfaces allow a wrapper approach where the class hierrchy is not determined by the API.
An application can create messages and headers easily, since the classes are defined in the API. If interfaces are used, a factory is needed (but a factory mechanism is used anyway to obtain the particular JainSipStack implementation, so that problem exists either way)
Other JAIN protocol API's use classes not interfaces - makes a more consistent architecture (But is this a good enough reason? maybe interfaces should have been used in other APIs?)
If classes are used, Message can directly extend java.util.EventObject, but if 
Message is an interface, we need to create a MessageEvent class (which contains a Message)

There are more pros for classes in this table, but they are not necessarily very good pros, and the cons could cause some serious problems. I personally find the interface approach more appropriate. I am hoping to get feedback on this issue soon.

Regards,
Chris

-- 
M.Ranganathan
NIST Advanced Networking Technologies Group,
100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899. 
Tel: 301 975 3664 Fax: 301 590 0932
 
--------------A7BC668A142D2C31327364F8-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 30 13:26:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA13164 for ; Mon, 30 Oct 2000 13:26:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1160A44348; Mon, 30 Oct 2000 12:26:05 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from pigeon.vovida.com (a98.vovida.com [209.237.8.98]) by lists.bell-labs.com (Postfix) with ESMTP id 0EE8244337 for ; Mon, 30 Oct 2000 12:25:34 -0500 (EST) Received: from vovida.com ([209.237.8.113]) by pigeon.vovida.com (Netscape Messaging Server 4.15) with ESMTP id G399FD00.VDA for ; Mon, 30 Oct 2000 10:16:25 -0800 Message-ID: <39FDBD19.FADCE8A1@vovida.com> From: Sunitha Kumar Organization: Vovida Networks X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14 i686) X-Accept-Language: en MIME-Version: 1.0 To: sip bell labs Content-Type: multipart/alternative; boundary="------------00976267C912270164090FE8" Subject: [SIP] proposal of draft in SIP security Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 30 Oct 2000 10:25:29 -0800 --------------00976267C912270164090FE8 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear SIP folks: Vovida is planning on proposing a draft in the area of SIP security, and essentially the idea will be to use public key cryptography to exchange symmetric keys. And, then perform encryption using symmetric keys. Wanted to find out if this idea has been tossed around already. thanks. -- Sunitha Kumar http://www.vovida.com --------------00976267C912270164090FE8 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Dear SIP folks:

Vovida is planning on proposing a draft in the area of SIP security, and essentially the idea will be to use public key cryptography to exchange symmetric keys.  And, then perform encryption using symmetric keys.
Wanted to find out if this idea has been tossed around already.
 

thanks. 

-- 
Sunitha Kumar
http://www.vovida.com
  --------------00976267C912270164090FE8-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 30 13:37:07 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA14953 for ; Mon, 30 Oct 2000 13:37:07 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9F22244383; Mon, 30 Oct 2000 12:37:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from pentagon.cisco.com (pentagon.cisco.com [161.44.199.141]) by lists.bell-labs.com (Postfix) with ESMTP id 2034344370 for ; Mon, 30 Oct 2000 12:36:40 -0500 (EST) Received: from cia.cisco.com (mirapoint@cia.cisco.com [161.44.199.157]) by pentagon.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA12448; Mon, 30 Oct 2000 13:36:31 -0500 (EST) Received: from mhammer-nt.cisco.com (va-dhcp198-137.cisco.com [161.44.198.137]) by cia.cisco.com (Mirapoint) with ESMTP id ADN02563; Mon, 30 Oct 2000 13:36:29 -0500 (EST) Message-Id: <4.3.2.7.2.20001030130617.00b3e1f0@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Adam B. Roach" From: hammer michael Subject: Re: [SIP] New SUBSCRIBE/NOTIFY draft available Cc: sip@lists.bell-labs.com, sip-events@egroups.com In-Reply-To: <200010301720.LAA18029@b04a24.exu.ericsson.se> References: <4.3.2.7.2.20001026135909.00b373f0@cia.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 30 Oct 2000 13:41:49 -0800 See further comments. Mike At 11:20 AM 10/30/2000 -0600, Adam B. Roach wrote: > >Sec 5.1.5, assume "must" = "MUST" > >Thanks. This is going away with the distinction beween third-party >and call-party subscriptions. > > >Sec 5.1.6, para 7: Would immediate fetch while subscription pending be > >some type of 18x response? > >No. It would be a 200 response, as in a normal subscription refresh. If you send a 200, then is your statement that the "subscription is pending" still valid? > >Sec 5.1.6, para 8: Implies that one must subscribe before one can > >subscribe, seems recursive. Could one assume that the resource to which > >one would be subscribing would have already registered and that the > >registration would have already defined the basis for access, e.g. > >restricted list or promiscuous (open to anyone)? > >I'm not sure what you mean by this. If I have a client running, and >you want to subscribe to some state in it, I might expect it to >interactively ask me, for each subscription, if I wish to allow >the subscription to be processed. > >I would assume you mean this paragraph: > > "Note that privacy concerns may require that notifiers either use > access lists or ask the user on a per-subscription basis whether > a particular remote node is allowed to subscribe to a certain set > of events. If such authorization fails, the notifier should reply > to the request with a "403 Forbidden" request. See section 7." > >Perhaps your confusion stems from what, exactly, is meant by "user." >In this context, I meant the owner of the node that is being asked >to act as a notifier. You may have read it such that it means the >owner of the node acting as a subscriber. I'll attempt to clarify >this text in the next draft. I think is was the "per-subscription basis" that threw me. I was thinking that you were deciding whether to allow the subscription based on the presence of a subscription list. Re-reading it, you seem to say that the subscription determines whether to get more information or make the decision with the current information. I was attempting to make some distinction between the purpose of the Register (which could contain out-of-band information, and which would by its presence be an offer to communications conditioned on events, albeit with some caveats or controls) and the Subscription which appears to be the agreement to the offer and request to be notified of those events. Essentially, this appears to be a brokering type of arrangement. I guess in the above instance you are either pre-approved or a "credit-check" is performed. > >Sec. 5.2.2, para 8: If the assumption is that configuration is done out of > >band, why not assume that the subscribe will be static provisioned and > >would therefore submit the SUBSCRIBE before the NOTIFY. That could obviate > >the need for Notify without Subscription. > >This mechanism is based on the same concept as third-party REGISTER >messages. My client may never send a SUBSCRIBE, but might receive >NOTIFY responses. I'm merely pointing out that such a mechanism makes >sense. My point was that it might be just as easy to statically configure the subscriber as the notifier, as either could be done out-of-band. One additional concern might be that blindly sending Notifies, when you are not even sure someone is there might be a waste of bandwidth. How does one know when the subscriber is "present" on the network? In a mobile network, the registration expires, the user de-registers, or a registration could be overwritten if it is the oldest. > >Sec 5.2.3: Could repeated non-ACK of Notifies be used before cancelling a > >subscription. It seems the subscription would be rather fragile under > >unreliable network conditions. That might be rather service-dependant. I > >would not want a long-running subscription to a non-call-related service to > >terminate just because I turned my computer off. In mobile environments, > >one could think of other cases where communications may be interrupted. > >This is solved by periodic subscription refreshes, just like registrations. >In the situation you cite (turning your computer off), the subscription >will be re-instantiated by your client when you start it up again. The concern that a Notify is not ack'd could still terminate a subscription still holds. >-- >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 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 30 13:41:07 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA15484 for ; Mon, 30 Oct 2000 13:41:07 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B309044383; Mon, 30 Oct 2000 12:38:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cybertron.div8.net (el05-24-131-150-91.ce.mediaone.net [24.131.150.91]) by lists.bell-labs.com (Postfix) with ESMTP id A253A44361 for ; Mon, 30 Oct 2000 10:47:14 -0500 (EST) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for sip@lists.bell-labs.com; Mon, 30 Oct 2000 10:47:06 -0600 (CST) From: Billy Biggs To: Chris Harris Cc: sip@lists.bell-labs.com Subject: Re: [SIP] JAIN SIP Meeting Results Message-ID: <20001030104706.A30908@div8.net> References: <39FB5484.5A7C94CE@dynamicsoft.com> <39FDA06C.838982AB@nist.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i In-Reply-To: <39FDA06C.838982AB@nist.gov>; from mranga@nist.gov on Mon, Oct 30, 2000 at 11:23:09AM -0500 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 30 Oct 2000 10:47:06 -0600 M. Ranganathan (mranga@nist.gov): > Thanks for posting this table. If we are taking a vote here, I vote for > interfaces. [...] If there is another public mailing list for these JAIN discussions, can this thread be continued there? If not, maybe one should be created. The SIP list gets enough messages about protocol operation. -- Billy Biggs, 3Com Email: Billy_Biggs@3com.com http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 30 13:47:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA16159 for ; Mon, 30 Oct 2000 13:47:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B033D4438C; Mon, 30 Oct 2000 12:38:15 -0500 (EST) Delivered-To: sip@share.research.bell-labs.com Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by lists.bell-labs.com (Postfix) with SMTP id 4B04D44377 for ; Mon, 30 Oct 2000 12:04:07 -0500 (EST) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Mon Oct 30 13:02:08 EST 2000 Received: by lists.bell-labs.com (Postfix) id ADC5F44380; Mon, 30 Oct 2000 12:48:57 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from ans.ih.lucent.com (ans.ih.lucent.com [135.2.78.5]) by lists.bell-labs.com (Postfix) with SMTP id 6EF1D4437D for ; Mon, 30 Oct 2000 12:48:57 -0500 (EST) Received: by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id LAA17906; Mon, 30 Oct 2000 11:48:53 -0600 Cc: sip@lists.bell-labs.com Received: from lucent.com by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id LAA17898; Mon, 30 Oct 2000 11:48:52 -0600 Message-ID: <39FDB47F.32454334@lucent.com> From: "Vijay K. Gurbani" Reply-To: vkg@lucent.com Organization: Intelligent Network/Messaging Systems & Internet Software Group X-Mailer: Mozilla 4.61 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: mranga@nist.gov Original-CC: sip@lists.bell-labs.com Subject: Re: [SIP] Forwarding SIP Invites -- how to decide transport. References: <39F991C8.3E472874@nist.gov> <39F9967D.220EAC04@lucent.com> <39FDADE7.66C2350A@nist.gov> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 30 Oct 2000 11:48:47 -0600 Content-Transfer-Encoding: 7bit Ranga: Please see embedded comments: "M. Ranganathan" wrote: > > Vijay, > > Thanks for your reply. The section you refer to says (forgive me if > I sound like a lawyer here!) : > > > (For socket-based > programs: For TCP, connect() returns ECONNREFUSED if the client > could not connect to a server at that address. For UDP, the socket > needs to be bound to the destination address using connect() rather > than sendto() or similar so that a second write() fails with > ECONNREFUSED if there is no server listening) If the client finds the > server is not reachable at a particular address, it SHOULD behave as > if it had received a 400-class error response to that request. > > > So the proxy is supposed to send UDP packets with a connect and a send > and then do a *second* send and then use TCP if the UDP attempt fails? Yes. If the proxy sends a request downstream over a UDP transport, it has to set its retransmission timer so that if if it does not get a response by the time the retransmission timer has run down, it will retransmit the request. On proxying the request the second time, it will get a ECONNREFUSED on the connected UDP socket. Then, it should try TCP. > How does it know the UDP attempt has failed (especially when the ACK > can bypass the proxy) ? Um, let's see...the ACK comes much later. Since you mention the ACK, I presume you are talking about proxying an INVITE downstream. Let's work with that scenario. A proxy gets an INVITE request from upstream UAC. It looks into its registrations and sees that the entity being invited to is registered (IP address is in registration database, transport is NOT). So, it proxies the INVITE to the downstream UAS using UDP as the first transport choice. When that fails (see ECONNREFUSED discussion in the above paragraph), it tries TCP. If TCP connect attempt succeeds, the request is proxied downstream. If the downstream UAS accepts the call, it will send the proxy a 200 OK response, which is proxied to the upstream UAC. The ACK will be gen- erated by the upstream UAC. If the proxy wanted to be in future sig- naling path, it would have included a Record-Route in the INVITE it proxied downstream earlier. If it did that, it'll get the ACK, since the UAC will build the Route from the 200 OK response and the ACK will make its way to the proxy. If the proxy did not insert a Record-Route, the ACK will go directly to the UAS. > I thought UDP connect was just a programming convenience (maybe I am > wrong) and does not check to see if there is a client on the recieving > end that will get the udp packet. You are partially right; UDP connect, unlike TCP connect, does not result in a 3-way handshake to ensure that the far peer indeed exists. All it does it to inform the kernel to record the IP address and port number of the peer and associate it with a socket descriptor. Further I/O to a connected UDP peer can then use the convenient read()/recv() primitives. Thus, it is more than a programming conbenience. For more information on this, consult Stevens Unix Network Programming, Volume 1, Section 8.11 ("connect Function with UDP"). Regards, - vijay -- Vijay K. Gurbani vkg@lucent.com vkg@research.bell-labs.com vkg@acm.org Internet Software Group/Intelligent Network and Messaging Systems Lucent Technologies/Bell Labs Innovations, 263 Shuman Blvd, Rm 1A-413 Naperville, Illinois 60566 Voice: +1 630 224 0216 Fax: +1 630 713 0184 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 30 15:27:10 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA01377 for ; Mon, 30 Oct 2000 15:27:09 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2F46244356; Mon, 30 Oct 2000 14:27:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by lists.bell-labs.com (Postfix) with ESMTP id 17DA644337 for ; Mon, 30 Oct 2000 14:26:01 -0500 (EST) Received: from rtp-xdm1.cisco.com (rtp-xdm1.cisco.com [161.44.3.80]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id MAA17895; Mon, 30 Oct 2000 12:25:55 -0800 (PST) Received: from cisco.com (localhost [127.0.0.1]) by rtp-xdm1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id PAA25597; Mon, 30 Oct 2000 15:25:53 -0500 (EST) Message-ID: <39FDD951.C8C2D78@cisco.com> 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: Jean-Francois Mule Cc: sip@lists.bell-labs.com Subject: Re: [SIP] SIP and T.38 fax calls - Internet Draft References: <00a401c03847$5d0e5df0$0100007f@rwcjfmule01> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 30 Oct 2000 15:25:53 -0500 Content-Transfer-Encoding: 7bit Hello Jean, I read through the draft and had a few questions - Is there a need for the fax enabled gateways to advertise the fax capability & params in the initial INVITE and 200 OK ? Is there a timing constraint on the use of RE-INVITEs to negotiate the bit-rate and other parameters ? Potentially, the INVITEs could get lost and might need to be retransmitted. Thanks - Sudipto Jean-Francois Mule wrote: > > A new Internet-Draft has been submitted, dealing with real time fax calls > and SIP: call flows and BCP. > > Comments and suggestions are very much appreciated. > Regards, > Jean-Francois Mule > > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Tuesday, October 17, 2000 3:47 AM > Subject: I-D ACTION:draft-mule-sip-t38callflows-00.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : SIP T.38 Call Flow Examples And Best Current > Practice > Author(s) : J. Mule > Filename : draft-mule-sip-t38callflows-00.txt > Pages : 19 > Date : 16-Oct-00 > > This document gives examples of SIP call flows for T.38 Internet fax > communications (SIP, the Session Initiation Protocol is defined in > RFC2543 [2] and T.38 is an ITU-T Recommendation [3]). Elements in > these call flows include SIP User Agents, SIP Proxy Servers, and > Gateways to the PSTN (Public Switch Telephone Network). > This document introduces best current practices for T.38 fax calls: > a call starts with audio capabilities, and, upon fax tone detection, > T.38 fax capabilities are negotiated. The T.38 fax call scenarios > include the detection of T.38 fax transmission by the receiving > side, or the emitting side, or both (in the latter case, a 'glare' > effect may appear). The current version of this document only > covers the case when the fax tone is detected by the receiving side > (other cases were left for discussion and may be included in the > future). Call flow diagrams and message details are shown. A list > of IANA defined SDP attribute names for T.38 is summarized in > section 5. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-mule-sip-t38callflows-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-mule-sip-t38callflows-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-mule-sip-t38callflows-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. > > ------------------------------------------------------------------------ > > Part 1.2 Type: message/rfc822 > Encoding: 7bit -- --------------------------------------------------------------------------- Sudipto Mukherjee Cisco Systems, Inc sudiptom@cisco.com --------------------------------------------------------------------------- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 30 15:51:54 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA06078 for ; Mon, 30 Oct 2000 15:51:53 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 239DF44381; Mon, 30 Oct 2000 14:50:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from elektron.elka.pw.edu.pl (elektron.elka.pw.edu.pl [194.29.160.2]) by lists.bell-labs.com (Postfix) with ESMTP id C673344337 for ; Mon, 30 Oct 2000 14:49:37 -0500 (EST) Received: from po58.warszawa.cvx.ppp.tpnet.pl ([213.76.110.58]:1921 "EHLO elka.pw.edu.pl") by elektron.elka.pw.edu.pl with ESMTP id ; Mon, 30 Oct 2000 21:49:20 +0100 Message-ID: <39FDDEEE.61C903B8@elka.pw.edu.pl> From: "Piotr S. Kossowski" Organization: Warsaw University of Technology - Institute of Telecommunications X-Mailer: Mozilla 4.7 [pl] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: SIP disscussion list , Billy_Biggs@3com.com Subject: Re: [SIP] possibly unintended recommendation for "tag" in 6.25 ofthe spec References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 30 Oct 2000 21:49:50 +0100 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > across restarts doesn't make sense in such a context. Thus, computing the > tag as a function of a machine specific invariant (IP address is a bad > example, actually, since it might change on restart of the machine) is what > you want. Yes, You're right. IP address as a machine invariant wasn't my best idea (e.g. because of DHCP). As concerns network equipement, MAC address would be a better choice, i think. BTW, for Billy: What is a reason for calling yourself (in application of SIP, not POTS, of course :-) ) ? (Or you have REGISTER on your mind ?) Thank you for your replies, Piotr _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 30 16:02:12 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA07759 for ; Mon, 30 Oct 2000 16:02:12 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0BD594433B; Mon, 30 Oct 2000 15:01:05 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by lists.bell-labs.com (Postfix) with ESMTP id 79E8744337 for ; Mon, 30 Oct 2000 15:00:25 -0500 (EST) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id 254104CE2B; Mon, 30 Oct 2000 16:00:20 -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 QAA18276; Mon, 30 Oct 2000 16:00:16 -0500 (EST) From: William Marshall Received: (from wtm@localhost) by fish-ha.research.att.com (980427.SGI.8.8.8/8.8.5) id QAA56029; Mon, 30 Oct 2000 16:00:16 -0500 (EST) Message-Id: <200010302100.QAA56029@fish-ha.research.att.com> To: gonzalo.camarillo@lmf.ericsson.se, sip@lists.bell-labs.com Cc: jdrosen@dynamicsoft.com Subject: Re: FW: [SIP] Feedback on manyfolks Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 30 Oct 2000 16:00:16 -0500 (EST) Gonzalo.Camarillo@lmf.ericsson.se wrote: > > Hi Bill, > > William Marshall wrote: > > > For the simple call from A to T, A inserts the SDP line a=qos:mandatory > > sendrecv" which T is willing to accept. But T can't do the send&recv QoS > > itself - it needs help from A for the A->T direction. > > (Note that T doesn't know whether A will be using RSVP, so it can't > > depend on using a RESV-CONF to do this trick). > > So, T does not know whether A uses RSVP or not... > Is there a negotiation of the QoS reservation scheme used? > That is, my terminal sends an INVITE with SDP preconditions (sendrecv), > and I get the 183 with the same preconditions (sendrecv). What should my > terminal do? > > Should it use RSVP to reserve resources in the recv direction and expect > the other end to do the same in the other direction? > Should it reserve resources for send&recv over its radio access and > expect the other end to perform also resorce reservation on its access > (maybe an ethernet)? > You mention also bi-directional resource reservation schemes. Should my > terminal use its bi-directional resource reservation mechanism and > perform the sendrecv reservation? > > Who decides which resource reservation mechanism is to be used? > Do we need negotiation of the reservation mechanism? > > > With the first roundtrip, the UAC and UAS agree exactly what the preconditions will be for the session. The UAC proposes "sendrecv" in the INVITE, and the UAS responds "sendrecv" in the 183. So both sides have agreed to get bi-directional QoS before allowing the session to proceed. The UAC then performs whatever it can in order to meet this precondition. For a typical RSVP implementation, it can only guarantee the "send" direction, and would respond in the COMET a=qos:success send The UAS performs whatever it can to meet the precondition. For a typical RSVP implementation, it will guarantee its "send" direction (which is not enough for the session to proceed). When UAS receives the COMET, "sendrecv" has been achieved, and the session can proceed. I don't think it is worthwhile trying to negotiate the type of resource reservation protocol used, since only the results of the reservation are important to the SIP session. The mechanism is already general enough to handle the variations. With QoS architectures where bi-directional reservations can be made: UAC could do the bi-directional reservation and respond with "a=qos:success sendrecv" in the COMET; UAS need do nothing. Alternately, UAS could do the bi-directional reservation and let the call proceed when it completes; in this case the UAS would likely not request a COMET since it is irrelevant. In yet other QoS architectures (such as cable and wireless), the UAC does access reservation (typically bi-directional) and one-way end-end reservation; it sends a COMET with "a=qos:success send". The UAS does its one-way reservation (which may overlap with the downstream on the cable or radio). I see no need to complicate the mechanism to be able to say "slightly more than one-way in send direction", since interoperating with standard endpoints works with just "send" - anything more than just "send" but less than "sendrecv" is still "send". Bill Marshall wtm@research.att.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 30 16:07:06 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA08317 for ; Mon, 30 Oct 2000 16:07:06 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5321B44388; Mon, 30 Oct 2000 15:01:13 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from relay2.shore.net (relay2.shore.net [207.244.125.21]) by lists.bell-labs.com (Postfix) with ESMTP id 0B96644337 for ; Mon, 30 Oct 2000 15:00:39 -0500 (EST) Received: from (hither.rfdsoftware.com) [209.192.222.62] by relay2.shore.net with esmtp (Exim) id 13qM2u-0006x1-00; Mon, 30 Oct 2000 16:00:44 -0500 Received: from cx991414-a.dialout.net (cx991414-d.crans1.ri.home.com [24.180.58.118]) by hither.rfdsoftware.com (8.9.2/8.9.2) with ESMTP id PAA16116; Mon, 30 Oct 2000 15:53:08 -0500 (EST) Message-Id: <5.0.0.25.2.20001030154632.0395cc70@webhost.tactical-sw.com> X-Sender: dnyon@webhost.tactical-sw.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 To: Jean-Francois Mule , ietf-fax@imc.org From: David Yon Subject: Re: [SIP] RE: Request for information on using T.30/T.37/T.38 with SIP/SDP/ RTP Cc: sip@lists.bell-labs.com In-Reply-To: <6374EFC78443D41197DD00508B5C35DD017A8820@rwcxch02.clarent. com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 30 Oct 2000 15:53:40 -0500 I know that the I-D specifically defers the discussion of media transport using TCP rather than UDPTL, but at the same time it also refers to a new token "TCP" to be registered with IANA for use in SDP. I am of the opinion that simply specifying "TCP" is insufficient to describe how TCP-based Media Transport is to be negotiated between two endpoints. I've submitted an Internet Draft for the MMUSIC group which will hopefully be available in the IETF I-D area soon, but for the moment it can be read here: ftp://ftp.dialout.net/drafts/draft-ietf-mmusic-sdp-tcpmedia-00.txt So, in regards to the SIP/T.38 I-D, my only comment would be that it take into account the I-D on SDP/TCP. Or at the very least, participate with better defining the SDP/TCP I-D such that is meets the needs of SIP/T.38 when using TCP for Media Transport. As such, any comments on the I-D above would be greatly appreciated. Again, hopefully the draft will be in the IETF area soon, I don't know why it is taking so long to work through the queue. At 02:26 PM 10/27/00 -0700, Jean-Francois Mule wrote: >There is an Internet-Draft on SIP and T.38 fax calls at >http://search.ietf.org/internet-drafts/draft-mule-sip-t38callflows-00.txt >It deals with how to negotiate a t.38 fax calls using sip as a signaling >protocol (including switch over from audio/rtp to data/t38), the SDP >attributes that itu-t sg-8 has registered with IANA. Comments are >appreciated on this Internet-Draft. > > David Yon Chief Technical Officer Dialout.Net, Inc. yon@dialout.net _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 30 16:14:41 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA09196 for ; Mon, 30 Oct 2000 16:14:40 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 146634439B; Mon, 30 Oct 2000 15:09:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by lists.bell-labs.com (Postfix) with ESMTP id E6F384439A for ; Mon, 30 Oct 2000 15:08:36 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5u3.ericy.com [208.237.135.124]) by imr1.ericy.com (8.9.3/8.9.3) with ESMTP id PAA07930; Mon, 30 Oct 2000 15:08:29 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr5.exu.ericsson.se (8.10.2/8.10.2) with ESMTP id e9UL6Zk05886; Mon, 30 Oct 2000 15:06:35 -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 PAA10469; Mon, 30 Oct 2000 15:08:28 -0600 (CST) Received: (from eusadam@localhost) by b04a24.exu.ericsson.se (8.9.1/8.9.1) id PAA18647; Mon, 30 Oct 2000 15:08:32 -0600 (CST) Message-Id: <200010302108.PAA18647@b04a24.exu.ericsson.se> Subject: Re: [SIP] New SUBSCRIBE/NOTIFY draft available To: mhammer@cisco.com (hammer michael) Cc: sip@lists.bell-labs.com, sip-events@egroups.com In-Reply-To: <4.3.2.7.2.20001030130617.00b3e1f0@cia.cisco.com> from "hammer michael" at Oct 30, 2000 01:41:49 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: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 30 Oct 2000 15:08:31 -0600 (CST) Content-Transfer-Encoding: 7bit >> >Sec 5.1.6, para 7: Would immediate fetch while subscription pending be >> >some type of 18x response? >> >>No. It would be a 200 response, as in a normal subscription refresh. > >If you send a 200, then is your statement that the "subscription is >pending" still valid? By "pending," I meant "active." I'll change it to "active." >> "Note that privacy concerns may require that notifiers either use >> access lists or ask the user on a per-subscription basis whether >> a particular remote node is allowed to subscribe to a certain set >> of events. If such authorization fails, the notifier should reply >> to the request with a "403 Forbidden" request. See section 7." >> >>Perhaps your confusion stems from what, exactly, is meant by "user." >>In this context, I meant the owner of the node that is being asked >>to act as a notifier. You may have read it such that it means the >>owner of the node acting as a subscriber. I'll attempt to clarify >>this text in the next draft. > >I think is was the "per-subscription basis" that threw me. I was thinking >that you were deciding whether to allow the subscription based on the >presence of a subscription list. Re-reading it, you seem to say that the >subscription determines whether to get more information or make the >decision with the current information. I'm not sure if we have this straight yet, so I'll give a concrete example. Let's imagine that you are sitting in front of your PC, with a SIP multimedia client running. You're talking to someone, and have whatever call waiting feature that your client may have turned off. I call and get a busy indication. I want to find out when your terminal is free so that I may immediately ring you back at that time. My client sends yours a "SUBSCRIBE." Your client may: a) Automatically accept the subscription, b) Accept the subscription only if I appear on the list you have entered into your client of "people allowed to subscribe to my terminal state," c) Accept the subscription only if I do not appear on the list you have entered into your client of "people not allowed to subscribe to my terminal state," or d) Pop up a dialog box saying "Adam Roach wants to subscribe to your terminal state. Is that OK?" and accept the subscription only if you click on "Yes." It is situation (d) that I am trying to describe. (Yes, there are other, more complicated criteria that allow/do-not-allow lists that could be applied. In fact, the really useful ones probably fall in this category). >> >Sec 5.2.3: Could repeated non-ACK of Notifies be used before cancelling a >> >subscription. It seems the subscription would be rather fragile under >> >unreliable network conditions. That might be rather service-dependant. I >> >would not want a long-running subscription to a non-call-related service to >> >terminate just because I turned my computer off. In mobile environments, >> >one could think of other cases where communications may be interrupted. >> >>This is solved by periodic subscription refreshes, just like registrations. >>In the situation you cite (turning your computer off), the subscription >>will be re-instantiated by your client when you start it up again. > >The concern that a Notify is not ack'd could still terminate a subscription >still holds. No, it doesn't. If you aren't responding to NOTIFY messages, you are obviously no longer online. Once you become available again, you'll either immediatly send a SUBSCRIBE to put the subscription in place (e.g. client reboot), or it will send another SUBSCRIBE before the expiration of the current subscription. And, yes, such behaviour can be service specific, as you point out. Note that the cancellation of a subscription by a notifier when he knows that the subscriber is offline is a MAY, not a MUST or even a SHOULD. -- 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 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 30 16:20:23 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA09858 for ; Mon, 30 Oct 2000 16:20:23 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B7B90443A2; Mon, 30 Oct 2000 15:12:05 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cybertron.div8.net (el05-24-131-150-91.ce.mediaone.net [24.131.150.91]) by lists.bell-labs.com (Postfix) with ESMTP id B5035443A1 for ; Mon, 30 Oct 2000 15:11:52 -0500 (EST) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for sip@lists.bell-labs.com; Mon, 30 Oct 2000 15:11:37 -0600 (CST) From: Billy Biggs To: "Piotr S. Kossowski" Cc: Jonathan Rosenberg , SIP disscussion list Subject: Re: [SIP] possibly unintended recommendation for "tag" in 6.25 ofthe spec Message-ID: <20001030151137.A31101@div8.net> References: <39FDDEEE.61C903B8@elka.pw.edu.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i In-Reply-To: <39FDDEEE.61C903B8@elka.pw.edu.pl>; from P.Kossowski@elka.pw.edu.pl on Mon, Oct 30, 2000 at 09:49:50PM +0100 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 30 Oct 2000 15:11:37 -0600 Piotr S. Kossowski (P.Kossowski@elka.pw.edu.pl): > BTW, for Billy: > > What is a reason for calling yourself (in application of SIP, not > POTS, of course :-) ) ? (Or you have REGISTER on your mind ?) It happens when you misconfigure forking proxies: you call a number that ends up forking to yourself. It's also an easy way to check if your registration is still active. An even better reason to not use the same tag across calls is for security reasons: Do you really want to silently accept re-INVITEs from unknown individuals as if it was an old call you forgot about after a reboot? Tags should be unique to the call-leg, and more specifically, one end of the call leg. -- Billy Biggs, 3Com Email: Billy_Biggs@3com.com http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 30 17:04:07 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA16277 for ; Mon, 30 Oct 2000 17:04:07 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A0F0A44356; Mon, 30 Oct 2000 16:04:05 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mail-dns2-nj.dialogic.com (mail-dns2-nj.dialogic.com [146.152.228.11]) by lists.bell-labs.com (Postfix) with ESMTP id 8AE9544337 for ; Mon, 30 Oct 2000 16:03:23 -0500 (EST) Received: from mail4.dialogic.com (mail4.dialogic.com [146.152.6.40]) by mail-dns2-nj.dialogic.com (8.9.1a+p1/8.9.1/d: dialogic.m4,v 1.3 2000/05/05 13:56:23 dmccart Exp $) with ESMTP id WAA03628 for ; Mon, 30 Oct 2000 22:07:21 GMT Received: from exchange4nj.dialogic.com (exchange4nj.dialogic.com [146.152.3.19]) by mail4.dialogic.com (8.9.3+Sun/8.9.3) with ESMTP id RAA19006 for ; Mon, 30 Oct 2000 17:03:17 -0500 (EST) Received: by exchange4nj.dialogic.com with Internet Mail Service (5.5.2650.21) id ; Mon, 30 Oct 2000 17:03:21 -0500 Message-ID: From: "Goutam, Gayathri" To: SIP@lists.bell-labs.com Subject: [SIP] un-subscribe MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 30 Oct 2000 17:03:27 -0500 un-subscribe _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip Gayathri Krishnan Goutam _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 30 17:19:06 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA20478 for ; Mon, 30 Oct 2000 17:19:05 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 702EF44356; Mon, 30 Oct 2000 16:19:05 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mailwall.tti.net (216-86-19-5.caprock.net [216.86.19.5]) by lists.bell-labs.com (Postfix) with ESMTP id 69B5E44337 for ; Mon, 30 Oct 2000 16:18:56 -0500 (EST) Received: from mailhost.ttiworld.com (unverified) by mailwall.tti.net (Content Technologies SMTPRS 4.1.2) with ESMTP id for ; Mon, 30 Oct 2000 16:18:51 -0600 Received: by mailhost.ttiworld.com with Internet Mail Service (5.5.2650.21) id ; Mon, 30 Oct 2000 16:18:22 -0600 Message-ID: <69DEAC407D3B6A48AA71F5D09966F7DB0BDF13@mailhost.ttiworld.com> From: Jianbing Chen To: "'SIP@lists.bell-labs.com'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] un-subscribe Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 30 Oct 2000 16:18:21 -0600 un-subscribe ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.inip.com ********************************************************************** _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 30 19:09:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA28575 for ; Mon, 30 Oct 2000 19:09:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0710744339; Mon, 30 Oct 2000 18:09:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from rwcxch02.clarent.com (unknown [208.205.112.2]) by lists.bell-labs.com (Postfix) with ESMTP id B140F44337 for ; Mon, 30 Oct 2000 18:08:17 -0500 (EST) Received: by rwcxch02.clarent.com with Internet Mail Service (5.5.2650.21) id <4V3F3T46>; Mon, 30 Oct 2000 16:05:57 -0800 Message-ID: <6374EFC78443D41197DD00508B5C35DD01844DB3@rwcxch02.clarent.com> From: Jean-Francois Mule To: Sudipto Mukherjee , sip@lists.bell-labs.com Subject: RE: [SIP] T.38 fax calls - advertising capabilities and INVITE re transmit MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 30 Oct 2000 16:05:53 -0800 Sudipto wrote: > Is there a need for the fax enabled gateways to advertise the > fax capability & params in the initial INVITE and 200 OK ? There are 2 possible approaches: 1. UA advertises its full capabilities at the beginning of *any* call 2. Upon fax detection, the UA initiates a re INVITE with new capabilities Unless the Internet Fax gw is a fax terminal dedicated to fax transmissions, I would prefer the second approach. It allows UAs to reject the re INVITE with a 415 Unsupported Media Type if t.38 capabilities are not supported and it allows the sender of the re INVITE to choose between t.38 fax or fax passthrough. Also, it could be heavy to advertize t.38 capabilities for all calls (you would carry fax-related media attributes in the initial INVITE for all calls...). So at a general level, I do not believe there is 'a need' for advertizing the fax capabilities in the initial INVITE. The only case would be when the SIP UA knows that the call is going to be a fax (sometimes you can smell the ink on the paper), for e.g. if it is an IP fax terminal or an analog gw with an fxs port connected to a fax machine -- in that case, fine to advertise both media capabilities in SDP. Any comments on that? Sudipto wrote: > Is there a timing constraint on the use of RE-INVITEs to negotiate > the bit-rate and other parameters ? Potentially, the INVITEs could > get lost and might need to be retransmitted. I would think there is indeed a timing constraint based on the t.30 protocol. The T1 timer may be adjusted when the INVITE is for a fax call (see sections 10.4.1 and 10.5 of the rfc2543bis-01 draft on T1 and invite). Is there a need to add some text on this in the I-D? Any suggestions? Thank you for your comments and questions Sudipto. Regards, Jean-Francois > -----Original Message----- > From: Sudipto Mukherjee [mailto:sudiptom@cisco.com] > Sent: Monday, October 30, 2000 12:26 PM > To: Jean-Francois Mule > Cc: sip@lists.bell-labs.com > Subject: Re: [SIP] SIP and T.38 fax calls - Internet Draft > > > Hello Jean, > > I read through the draft and had a few questions - > > Is there a need for the fax enabled gateways to advertise the > fax capability & params in the initial INVITE and 200 OK ? > > Is there a timing constraint on the use of RE-INVITEs to negotiate > the bit-rate and other parameters ? Potentially, the INVITEs could > get lost and might need to be retransmitted. > > Thanks > - Sudipto > > > > > Jean-Francois Mule wrote: > > > > A new Internet-Draft has been submitted, dealing with real > time fax calls > > and SIP: call flows and BCP. > > > > Comments and suggestions are very much appreciated. > > Regards, > > Jean-Francois Mule > > > > -----Original Message----- > > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > > Sent: Tuesday, October 17, 2000 3:47 AM > > Subject: I-D ACTION:draft-mule-sip-t38callflows-00.txt > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > > > Title : SIP T.38 Call Flow Examples And > Best Current > > Practice > > Author(s) : J. Mule > > Filename : draft-mule-sip-t38callflows-00.txt > > Pages : 19 > > Date : 16-Oct-00 > > > > This document gives examples of SIP call flows for T.38 Internet fax > > communications (SIP, the Session Initiation Protocol is defined in > > RFC2543 [2] and T.38 is an ITU-T Recommendation [3]). Elements in > > these call flows include SIP User Agents, SIP Proxy Servers, and > > Gateways to the PSTN (Public Switch Telephone Network). > > This document introduces best current practices for T.38 fax calls: > > a call starts with audio capabilities, and, upon fax tone detection, > > T.38 fax capabilities are negotiated. The T.38 fax call scenarios > > include the detection of T.38 fax transmission by the receiving > > side, or the emitting side, or both (in the latter case, a 'glare' > > effect may appear). The current version of this document only > > covers the case when the fax tone is detected by the receiving side > > (other cases were left for discussion and may be included in the > > future). Call flow diagrams and message details are shown. A list > > of IANA defined SDP attribute names for T.38 is summarized in > > section 5. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-mule-sip-t38callflows-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-mule-sip-t38callflows-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-mule-sip-t38callflows-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. > > ------------------------------------------------------------------------ > > Part 1.2 Type: message/rfc822 > Encoding: 7bit -- --------------------------------------------------------------------------- Sudipto Mukherjee Cisco Systems, Inc sudiptom@cisco.com --------------------------------------------------------------------------- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 30 19:37:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA04976 for ; Mon, 30 Oct 2000 19:37:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6E6A44433E; Mon, 30 Oct 2000 18:37:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from ganymede.or.intel.com (ganymede.or.intel.com [134.134.248.3]) by lists.bell-labs.com (Postfix) with ESMTP id 25D0A44339 for ; Mon, 30 Oct 2000 18:36:22 -0500 (EST) Received: from SMTP (orsmsxvs01-1.jf.intel.com [192.168.65.200]) by ganymede.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.32 2000/10/12 22:57:04 dmccart Exp $) with SMTP id QAA19367; Mon, 30 Oct 2000 16:36:14 -0800 (PST) Received: from orsmsx28.jf.intel.com ([192.168.70.28]) by 192.168.70.200 (Norton AntiVirus for Internet Email Gateways 1.0) ; Tue, 31 Oct 2000 00:36:14 0000 (GMT) Received: by orsmsx28.jf.intel.com with Internet Mail Service (5.5.2650.21) id ; Mon, 30 Oct 2000 16:36:12 -0800 Message-ID: From: "Agarwal, Aseem" To: "'Bertil Engelholm'" , sip@lists.bell-labs.com Subject: RE: [SIP] Transaction Identification, once again MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 30 Oct 2000 16:36:01 -0800 Hi All, Discussions around this topic have cropped up a number of times. I found related emails in q3 archives under the threads : "Transaction-Id", "Loop detection again", "Late loop detection" and "Record-route and loop detection". However, the volume of emails involved and then the note on merged requests on the SIP Bake off site, have managed to obfuscate me. There is no clear example in the RFC or in the call flows RFC to understand scenarios involved. I would appreciate if somebody could provide example call flows or point me to text which further clarifies these issues. I am sure providing example scenarios for : - loop detection - detection and action on merged requests will help the implementers and avoid further confusions. rgds, aseem -----Original Message----- From: Bertil Engelholm [mailto:Bertil.Engelholm@uab.ericsson.se] Sent: Wednesday, October 25, 2000 9:58 AM To: sip@lists.bell-labs.com Subject: [SIP] Transaction Identification, once again Hi again, I'm sorry to bring this up again but I just can't get things to work in the correct way. I have read through the old threads regarding this matter and still don't understand how it is suppose to work. It's this example again : --------- -------- -------- | a@c1 | -- INV u1@p1 --> | (s1) | -- INV u2@p2 --> | | --------- (contact a@c1) | | | | | p1 | | p2 | --------- | | | | | b@c2 | <- INV b@c2 ---- | (s2) | <- INV u3@p1 --- | | --------- -------- -------- If P1 is stateful it might allocate one "call" state machine for each path the "call" takes in P1 (s1 and s2 in the picture). These two state machines are identified by the REQUEST-URI that came in the two INVITEs since that's the only thing that differs the two from each other. (topmost VIA also differs, more about that later) P1 will now include the REQUEST-URI in the branch value it generates so that the responses can be directed to the right state machine when they arrive. And when the ACK is sent the original REQUEST-URI from ROUTE is used. So no problems here. The problem I have is when b@C2 sends a new request (eg. BYE). According to the specification b should/must/may (or whatever) overwrite the REQUEST-URI in the ROUTE headers using the REQUEST-URI from CONTACT or FROM. So how should P1 now be able to differ the two (BYE) requests from each other ? The Original REQUEST-URI was the only thing that P1 had to identify the two state machines. When reading the old threads regarding this matter I saw something about using topmost VIA in some way, but how ? By using the topmost VIA you can see that they are two different requests but how do you identify which state machine should receive the first request. (Someone might argue that it doesn't matter but if P1 controls a firewall it DO matter. Maybe not for BYE but for a RE-INVITE it matters). -- Bertil Engelholm AXE Research and Development voice : +46 8 727 3499 SIP Security Fax : +46 8 647 8276 S-126 25 Stockholm Sweden E-mail: Bertil.Engelholm@uab.ericsson.se _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 30 22:56:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA23329 for ; Mon, 30 Oct 2000 22:56:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0ECC04433C; Mon, 30 Oct 2000 21:56:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mars.hss.co.in (unknown [202.54.26.197]) by lists.bell-labs.com (Postfix) with ESMTP id 05E804433B for ; Mon, 30 Oct 2000 21:55:37 -0500 (EST) Received: from sampark.hss.hns.com (sampark [139.85.229.22]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id e9V3slC21138; Tue, 31 Oct 2000 09:25:16 +0530 (IST) Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 65256989.00147C15 ; Tue, 31 Oct 2000 09:13:44 +0530 X-Lotus-FromDomain: HSSBLR From: archow@hss.hns.com To: Jean-Francois Mule , sip@lists.bell-labs.com Message-ID: <65256989.00147A3F.00@sampark.hss.hns.com> Subject: Re: [SIP] SIP and T.38 fax calls - Internet Draft Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 31 Oct 2000 09:13:39 +0530 Jean, in your call flows, why does the proxy change CSeq numbers ? This does not seem warranted. Infact, this would throw the endpoints into total confusion if a message happened to reach each other directly. (I dont even see the Proxy adding a Record Route) (see 4.3 for an example ) Any reason why the proxy must re-write CSeq ? I dont see any in the first read. Regds Arjun -- Arjun Roychowdhury @ Hughes Software Systems Jean-Francois Mule wrote: > > A new Internet-Draft has been submitted, dealing with real time fax calls > and SIP: call flows and BCP. > > Comments and suggestions are very much appreciated. > Regards, > Jean-Francois Mule > > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Tuesday, October 17, 2000 3:47 AM > Subject: I-D ACTION:draft-mule-sip-t38callflows-00.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : SIP T.38 Call Flow Examples And Best Current > Practice > Author(s) : J. Mule > Filename : draft-mule-sip-t38callflows-00.txt > Pages : 19 > Date : 16-Oct-00 > > This document gives examples of SIP call flows for T.38 Internet fax > communications (SIP, the Session Initiation Protocol is defined in > RFC2543 [2] and T.38 is an ITU-T Recommendation [3]). Elements in > these call flows include SIP User Agents, SIP Proxy Servers, and > Gateways to the PSTN (Public Switch Telephone Network). > This document introduces best current practices for T.38 fax calls: > a call starts with audio capabilities, and, upon fax tone detection, > T.38 fax capabilities are negotiated. The T.38 fax call scenarios > include the detection of T.38 fax transmission by the receiving > side, or the emitting side, or both (in the latter case, a 'glare' > effect may appear). The current version of this document only > covers the case when the fax tone is detected by the receiving side > (other cases were left for discussion and may be included in the > future). Call flow diagrams and message details are shown. A list > of IANA defined SDP attribute names for T.38 is summarized in > section 5. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-mule-sip-t38callflows-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-mule-sip-t38callflows-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 > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 30 23:23:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA29050 for ; Mon, 30 Oct 2000 23:23:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 86D134433C; Mon, 30 Oct 2000 22:23:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cybertron.div8.net (el05-24-131-150-91.ce.mediaone.net [24.131.150.91]) by lists.bell-labs.com (Postfix) with ESMTP id C1E6644336 for ; Mon, 30 Oct 2000 22:22:58 -0500 (EST) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for sip@lists.bell-labs.com; Mon, 30 Oct 2000 22:22:53 -0600 (CST) From: Billy Biggs To: SIP List Message-ID: <20001030222253.A31229@div8.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i Subject: [SIP] Scope of the Call-ID in bis-02 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 30 Oct 2000 22:22:53 -0600 In section 4.2.1 and 6.12, there is a suggestion (first MAY then SHOULD) that the client would silently accept calls which use the same Call-ID, or at least logically associate them. There has been suggestions made on this list about using this to solve conferencing related problems. However, I believe that is no implementation consensus about how this might work, and I think that implying full-mesh style conferencing or "replaces" style behavior overloads the Call-ID. Can these (confusing) references be removed? Do others feel strongly? I personaly would rather see the Replaces header be revived for use in an INVITE if the user wishes to negotiate a call handoff (attended transfer) using REFER. For full-mesh conferencing, or other logical association tricks, again I see some other header being appropiate (Associate?). At least then we are being much more clear as to the intended behavior. -- Billy Biggs, 3Com Email: Billy_Biggs@3com.com http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Oct 30 23:49:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA06683 for ; Mon, 30 Oct 2000 23:49:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id DF86A44354; Mon, 30 Oct 2000 22:49:05 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cybertron.div8.net (el05-24-131-150-91.ce.mediaone.net [24.131.150.91]) by lists.bell-labs.com (Postfix) with ESMTP id B72024433C for ; Mon, 30 Oct 2000 22:48:32 -0500 (EST) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for sip@lists.bell-labs.com; Mon, 30 Oct 2000 22:48:08 -0600 (CST) From: Billy Biggs To: Henning Schulzrinne Cc: SIP List Message-ID: <20001030224808.B31229@div8.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i Subject: [SIP] My comments on bis-02 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 30 Oct 2000 22:48:08 -0600 These are some of my (late) issues with bis-02. BTW, It would help for commenting on the draft if there was a text file version. Comments which may require discussion ------------------------------------- 1. In 4.2.1 there is discussion about how to handle INVITEs which cross on the wire. Are you worried about when two endpoints change their contact address at the same time? If you're just worried about the session changing, it seems that it would be more interoperability-friendly if implementations just re-re-INVITE'd when they believe requests may have crossed, and use some internal random timer. 2. In 4.2.5, it is noted that CANCEL requests cannot have Route headers. Why not? Are you assuming that CANCEL is only useful for an initial request? This breaks since we need to be able to CANCEL a pending REFER or other extension method which doesn't complete quickly, for example. 3. Sections 6.25 and 10.1.1 (maybe others), as I mentioned in another post to the list, imply that clients should choose a single local tag and preserve this across calls. This is a bad idea in cases when UAs call themselves, may lead to UAs choosing the same tag value in some cases, and also poses a security risk. I strongly recommend that the recommendation change to be that tags should always be unique. Apologies to those implementations that want to try and preserve calls over reboots. I don't see much point to section 11.5 either. Using the same tag doesn't solve all the problems, so why bother trying? It just makes things confusing and prone to failure. 4. Regarding Authentication in 13.2, is it the responsibility of the UAC to not use short form headers after the Authorization, or is it the responsibility of the proxy to switch them when transforming the message into canonical form? I ask because there are extensions to SIP which propose new short forms for headers that proxies will not know about. An example of this is the REFER draft. Should the UAC not use these short forms, or should extensions not propose them? 5. Due to the proliferation of the Also header in BYE requests, I would suggest that it be added to the bis draft, with its meaning restricted to use with the BYE method. 6. Mid-Call redirects. The wording for the 305 response code seems to indicate that it can be sent mid-call. This breaks if you have a Route. I guess the only reasonable thing to do is say that if you get redirected mid-call you should drop your route? Or even better, tell UAs that they cannot send a redirect response to a request with a To tag? Regardless, the bis draft should mention this case. 7. See my last post regarding the scope of the Call-ID. Comments which are just bugs ---------------------------- 8. It would be nice in section 16 if all of the examples included from tags. As well, Figures 1 and 2 don't have tags. 9. Section 4.2.6 explicitly mentions that REGISTER messages can be redirected. This seems redundant. I also believe that there are other areas of the spec where it is quite verbose and redundant. While this is to the benefit of new readers in some cases, the draft is also now quite large. Can we maybe try and strip some of the fluff out? 10. Section 1.4.6 says Call-ID when it means "within the same call leg". 11. In section 7.4.1, as was noted somewhere, "Missing Content-Length header" is a bad example unless it is now mandatory. 12. Section 1.4.2 implies that clients do not need to support UDP. I think this is a bug. -- Billy Biggs, 3Com Email: Billy_Biggs@3com.com http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 31 00:49:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA23626 for ; Tue, 31 Oct 2000 00:49:05 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id EF52E4434A; Mon, 30 Oct 2000 23:49:05 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from rwcxch02.clarent.com (unknown [208.205.112.2]) by lists.bell-labs.com (Postfix) with ESMTP id CD88B44344 for ; Mon, 30 Oct 2000 23:48:35 -0500 (EST) Received: by rwcxch02.clarent.com with Internet Mail Service (5.5.2650.21) id <4V3F3406>; Mon, 30 Oct 2000 21:46:14 -0800 Message-ID: <6374EFC78443D41197DD00508B5C35DD3F02B1@rwcxch02.clarent.com> From: Jean-Francois Mule To: "'archow@hss.hns.com '" , "'sip@lists.bell-labs.com '" Subject: RE: [SIP] SIP proxies and CSeq numbers (was: SIP and T.38 fax cal ls - Internet Draft) MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 30 Oct 2000 21:46:11 -0800 Arjun: Thanks for your comments. For the proxy, the 2 call legs constitute 2 distinct SIP transactions so there is no particular reason to propagate the CSeq number from one call leg to the other. If the 2 UAs happen to communicate directly, the sip transaction would be different from any previous transaction established with the proxy, therefore the CSeq number could be whatever the UAC decides. While I would agree with you that this does not bring much, I believe it is valid. Jean-Francois. PS: As for the Record-Route, it was omitted (while it is key to proxy functions, isn't it optional after all? -- 6.34.1). I'll add the Record-route to the next I-D revision - thanks. -----Original Message----- From: archow@hss.hns.com To: Jean-Francois Mule; sip@lists.bell-labs.com Sent: 10/30/00 7:43 PM Subject: Re: [SIP] SIP and T.38 fax calls - Internet Draft Jean, in your call flows, why does the proxy change CSeq numbers ? This does not seem warranted. Infact, this would throw the endpoints into total confusion if a message happened to reach each other directly. (I dont even see the Proxy adding a Record Route) (see 4.3 for an example ) Any reason why the proxy must re-write CSeq ? I dont see any in the first read. Regds Arjun -- Arjun Roychowdhury @ Hughes Software Systems Jean-Francois Mule wrote: > > A new Internet-Draft has been submitted, dealing with real time fax calls > and SIP: call flows and BCP. > > Comments and suggestions are very much appreciated. > Regards, > Jean-Francois Mule > > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Tuesday, October 17, 2000 3:47 AM > Subject: I-D ACTION:draft-mule-sip-t38callflows-00.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : SIP T.38 Call Flow Examples And Best Current > Practice > Author(s) : J. Mule > Filename : draft-mule-sip-t38callflows-00.txt > Pages : 19 > Date : 16-Oct-00 > > This document gives examples of SIP call flows for T.38 Internet fax > communications (SIP, the Session Initiation Protocol is defined in > RFC2543 [2] and T.38 is an ITU-T Recommendation [3]). Elements in > these call flows include SIP User Agents, SIP Proxy Servers, and > Gateways to the PSTN (Public Switch Telephone Network). > This document introduces best current practices for T.38 fax calls: > a call starts with audio capabilities, and, upon fax tone detection, > T.38 fax capabilities are negotiated. The T.38 fax call scenarios > include the detection of T.38 fax transmission by the receiving > side, or the emitting side, or both (in the latter case, a 'glare' > effect may appear). The current version of this document only > covers the case when the fax tone is detected by the receiving side > (other cases were left for discussion and may be included in the > future). Call flow diagrams and message details are shown. A list > of IANA defined SDP attribute names for T.38 is summarized in > section 5. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-mule-sip-t38callflows-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-mule-sip-t38callflows-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 > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 31 01:06:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA28158 for ; Tue, 31 Oct 2000 01:06:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E9EDA4435A; Tue, 31 Oct 2000 00:06:04 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mars.hss.co.in (unknown [202.54.26.197]) by lists.bell-labs.com (Postfix) with ESMTP id ACAEC4434A for ; Tue, 31 Oct 2000 00:04:50 -0500 (EST) Received: from sampark.hss.hns.com (sampark [139.85.229.22]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id e9V635C26466; Tue, 31 Oct 2000 11:33:43 +0530 (IST) Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 65256989.00218571 ; Tue, 31 Oct 2000 11:36:08 +0530 X-Lotus-FromDomain: HSSBLR From: archow@hss.hns.com To: Jean-Francois Mule Cc: archow@hss.hns.com, "'sip@lists.bell-labs.com '" Message-ID: <65256989.0021841C.00@sampark.hss.hns.com> Subject: RE: [SIP] SIP proxies and CSeq numbers (was: SIP and T.38 fax cal ls - Internet Draft) Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 31 Oct 2000 11:36:04 +0530 Jean, Consider this situation: A sends an INVITE which goes through your Proxy to B. B sends a 200 OK with Contact as userb@here.com. This is routed through your proxy and goes to A. Now since A has a direct path to B (and the proxy did not do a Record-Route), A now sends the next request (ACK) directly to B ( protocol behaviour) The ACK must have the same CSeq as the INVITE although is a transaction of its own. But in this case, the ACK will have the CSeq of A - P which is different from the CSeq space of P-B. Since ACK went directly B would think this ACK is not valid. The same problems will arise in any future requests within the same call which is forwarded directly. This , as you would notice induces incorrect behaviour. jean> PS: As for the Record-Route, it was omitted (while it is key to proxy jean> functions, isn't it optional after all? -- 6.34.1). I'll add the jean> Record-route to the next I-D revision - thanks. Yes, its not mandatory. However in your scenario, if you do not do Record-Route future request can skip your proxy who then cannot change CSeq (if thats needed in the first place) Regds Arjun -- Arjun Roychowdhury @ Hughes Software Systems Jean-Francois Mule on 10/31/2000 11:16:11 AM To: archow, "'sip@lists.bell-labs.com '" cc: Subject: RE: [SIP] SIP proxies and CSeq numbers (was: SIP and T.38 fax cal ls - Internet Draft) Arjun: Thanks for your comments. For the proxy, the 2 call legs constitute 2 distinct SIP transactions so there is no particular reason to propagate the CSeq number from one call leg to the other. If the 2 UAs happen to communicate directly, the sip transaction would be different from any previous transaction established with the proxy, therefore the CSeq number could be whatever the UAC decides. While I would agree with you that this does not bring much, I believe it is valid. Jean-Francois. PS: As for the Record-Route, it was omitted (while it is key to proxy functions, isn't it optional after all? -- 6.34.1). I'll add the Record-route to the next I-D revision - thanks. -----Original Message----- From: archow@hss.hns.com To: Jean-Francois Mule; sip@lists.bell-labs.com Sent: 10/30/00 7:43 PM Subject: Re: [SIP] SIP and T.38 fax calls - Internet Draft Jean, in your call flows, why does the proxy change CSeq numbers ? This does not seem warranted. Infact, this would throw the endpoints into total confusion if a message happened to reach each other directly. (I dont even see the Proxy adding a Record Route) (see 4.3 for an example ) Any reason why the proxy must re-write CSeq ? I dont see any in the first read. Regds Arjun -- Arjun Roychowdhury @ Hughes Software Systems Jean-Francois Mule wrote: > > A new Internet-Draft has been submitted, dealing with real time fax calls > and SIP: call flows and BCP. > > Comments and suggestions are very much appreciated. > Regards, > Jean-Francois Mule > > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Tuesday, October 17, 2000 3:47 AM > Subject: I-D ACTION:draft-mule-sip-t38callflows-00.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : SIP T.38 Call Flow Examples And Best Current > Practice > Author(s) : J. Mule > Filename : draft-mule-sip-t38callflows-00.txt > Pages : 19 > Date : 16-Oct-00 > > This document gives examples of SIP call flows for T.38 Internet fax > communications (SIP, the Session Initiation Protocol is defined in > RFC2543 [2] and T.38 is an ITU-T Recommendation [3]). Elements in > these call flows include SIP User Agents, SIP Proxy Servers, and > Gateways to the PSTN (Public Switch Telephone Network). > This document introduces best current practices for T.38 fax calls: > a call starts with audio capabilities, and, upon fax tone detection, > T.38 fax capabilities are negotiated. The T.38 fax call scenarios > include the detection of T.38 fax transmission by the receiving > side, or the emitting side, or both (in the latter case, a 'glare' > effect may appear). The current version of this document only > covers the case when the fax tone is detected by the receiving side > (other cases were left for discussion and may be included in the > future). Call flow diagrams and message details are shown. A list > of IANA defined SDP attribute names for T.38 is summarized in > section 5. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-mule-sip-t38callflows-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-mule-sip-t38callflows-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 > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 31 07:32:06 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA27181 for ; Tue, 31 Oct 2000 07:32:06 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 74FDB44337; Tue, 31 Oct 2000 06:32:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from exchangesvr.nuera.com (unknown [204.216.240.124]) by lists.bell-labs.com (Postfix) with ESMTP id A2ADB44336 for ; Tue, 31 Oct 2000 06:31:49 -0500 (EST) Received: by exchangesvr.nuera.com with Internet Mail Service (5.5.2650.21) id ; Tue, 31 Oct 2000 04:32:02 -0800 Message-ID: From: "Fairlie-Cuninghame, Robert" To: sip@lists.bell-labs.com Subject: RE: [SIP] Redirect server returning new From header MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 31 Oct 2000 04:31:52 -0800 Agreed. Operating under the proper trust relationships, couldn't this problem be solved by a proxy (or B2BUA - but _not_ a redirect server) adding Remote-Party-Id/Anonimity headers on behalf of the UA (as described in the dcsgroup-privacy internet draft). This only works when the proxy can confirm 1) that the UA is indeed who they claim to be (ie UA to proxy Authentication) 2) that the SIP URL does indeed equate to a tel: number on the destination network (internal database) 3) and that the proxy has a trust relationship established across the SIP-PSTN/VoIP network that the proxy is routing the call to (as per dcsgroup-privacy draft). .... which are conditions that you would want in the first case. Due to proper privacy frameowrk on the SIP-PSTN network side, the proxy can also ensure that the UA's Caller Info doesn't accidentally get sent to somewhere it shouldn't. Last but not least, no extra PSTN specific features are needed on the UA which makes the solution a lot more mobile. Regards, Robert. -- My opinions are my own. I tried selling them once but everybody seems to already have one. -- > -----Original Message----- > From: Simon Barber [mailto:simon@firetalk.com] > Sent: Friday, October 27, 2000 7:52 AM > To: sip@lists.bell-labs.com > Subject: RE: [SIP] Redirect server returning new From header > > > > I thought we had put this issue to bed. > > > > As Henning pointed out previously, allowing a UAC to insert > a telephone > > number into a request, which is then passed to the PSTN > (via a gateway) as > > the originating number, is a recipe for a security > disaster. Nothing stops > > me from inserting fake telephone numbers, and calling > people pretending to > > be someone else. You can expect a call from the FCC about that one. > > > > So, in fact, this proposed used of the Also-From header is, > in practice, > > unusable without a massive security/PKI infrastructure > which really doesn't > > exist (you would need someone to certify that joe@foo.com > owns the number > > 555-1212. I don't even know who would be able to adequately > certify this, > > and I suspect no CA in their right mind would ever put this in a > > certificate). > > This security infrastructure already exists in the current > telephone network - > although it is implemented in hardware rather than software. > Phone companies have a > network of trust with each other, and exchange ISUP messages > with each other only > secure lines setup along these lines of trust. Where > signalling is exchanged with an > end user (Q.931) checks are made to ensure the user is > authorised to send the numbers > he sends. A similar trust network is required if we want to > have authenticated CLI in > SIP. Currently SIP-T does require exactly the same (physical > or secure VPN) trust > network as regular ISUP telephony. Indeed this is probably > one of the main > constraining factors that limits whom SIP-T is available to. > > Your telephone company will be very well positioned to > certify that you have the > right to present your telephone number. I would suggest that > it will be your phone > company, or a third party acting on their behalf who will do so. > > Authenticated CLI in SIP may play a very important part in > keeping SIP spamming down. > > Simon Barber > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 31 08:25:07 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA19806 for ; Tue, 31 Oct 2000 08:25:06 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 733FE44337; Tue, 31 Oct 2000 07:25:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from zrtps06s.us.nortel.com (unknown [47.140.48.50]) by lists.bell-labs.com (Postfix) with ESMTP id A1A2E44336 for ; Tue, 31 Oct 2000 07:24:37 -0500 (EST) Received: from zrtpd00y.us.nortel.com by zrtps06s.us.nortel.com; Tue, 31 Oct 2000 08:22:56 -0500 Received: by zrtpd00y.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Tue, 31 Oct 2000 08:22:56 -0500 Message-ID: From: "Harmi Singh" To: "'INTERNET'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0433D.A6638560" X-Orig: Subject: [SIP] [SIP]UNSUBSCRIBE Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 31 Oct 2000 08:22:42 -0500 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_01C0433D.A6638560 Content-Type: text/plain; charset="iso-8859-1" UNSUBSCRIBE ------_=_NextPart_001_01C0433D.A6638560 Content-Type: text/html; charset="iso-8859-1" [SIP]UNSUBSCRIBE

UNSUBSCRIBE


------_=_NextPart_001_01C0433D.A6638560-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 31 09:34:10 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA08805 for ; Tue, 31 Oct 2000 09:34:09 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 578C844337; Tue, 31 Oct 2000 08:34:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.242]) by lists.bell-labs.com (Postfix) with ESMTP id 6FB1244336 for ; Tue, 31 Oct 2000 08:33:55 -0500 (EST) Received: from hpqs0130.sqf.hp.com (hpqs0130.sqf.hp.com [15.144.177.5]) by palrel1.hp.com (Postfix) with ESMTP id 41B0F21C0 for ; Tue, 31 Oct 2000 06:33:45 -0800 (PST) Received: from sqf0084 (sqf0084.sqf.hp.com [15.144.188.101]) by hpqs0130.sqf.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.0) with SMTP id OAA06483 for ; Tue, 31 Oct 2000 14:33:42 GMT Message-ID: <088101c04347$901f6710$65bc900f@sqf0084.sqf> Reply-To: "Andy Duncan" From: "Andy Duncan" To: 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.3612.1700 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700 Subject: [SIP] Very old SIP+ question ! Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 31 Oct 2000 14:33:39 -0000 Content-Transfer-Encoding: 7bit Hello, I realise SIP+ has been superceded by the amazing SIP-T proposal, but I am currently looking from a backwards compatibility viewpoint, as I understand that Level3 are currently using SIP+ in their networks (Yes/No ?) I am struggling to find any real documentation for SIP+, apart for the Inter MGC Protocol document, by Mr Zimmerer, so have one simple question that I hope somebody could take the time to answer. Does the encapsulated ISUP in a SIP+ message begin at the message type octet, like it does for SIP-T, or does it include the OPC/DPC/CIC ? Thank you, Andy ============================ Andrew S Duncan Agilent Technologies Tel: 0131 331 7822 Exten: 32822 Mailstop: SQFR&D3 ============================ _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 31 10:07:11 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA26525 for ; Tue, 31 Oct 2000 10:07:11 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4BEE144337; Tue, 31 Oct 2000 09:07:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from smtprch2.nortel.com (smtprch2.nortelnetworks.com [192.135.215.15]) by lists.bell-labs.com (Postfix) with ESMTP id 996CB44336 for ; Tue, 31 Oct 2000 09:06:42 -0500 (EST) Received: from zrchb200.us.nortel.com (actually zrchb200) by smtprch2.nortel.com; Tue, 31 Oct 2000 09:02:12 -0600 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2652.35) id <4VMDKK4T>; Tue, 31 Oct 2000 09:06:16 -0600 Message-ID: <9A9367D1556AD21182C40000F80930AB02B16572@crchy28b.us.nortel.com> From: "Sriram Parameswar" To: "'sip@lists.bell-labs.com'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0434C.16C4B6E0" X-Orig: Subject: [SIP] Preferences in SUBSCRIBE Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 31 Oct 2000 09:06:04 -0600 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_01C0434C.16C4B6E0 Content-Type: text/plain; charset="iso-8859-1" Hi, From reading the I-D's on Presence and Caller Preferences, I think it would be neat to allow watchers to send in their preferences in the SUBSCRIBE. For example 'NOTIFY me only when John Doe comes on-line on their Mobile'. This could be achieved if using the mobility-param [mobility = "mobile"] in an Accept-Contact header in the SUBSCRIBE. However the I-D does not cover the SUBSCRIBE method - may I ask that it be included? Jonathan/Henning your comments are appreciated. Thanks and Regards, Sriram Parameswar Nortel Networks ------_=_NextPart_001_01C0434C.16C4B6E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Preferences in SUBSCRIBE

Hi,

From reading the I-D's on Presence and Caller = Preferences, I think it would be neat to allow watchers to send in = their preferences in the SUBSCRIBE. For example 'NOTIFY me only when = John Doe comes on-line on their Mobile'.

This could be achieved if using the mobility-param = [mobility =3D "mobile"] in an Accept-Contact header in the = SUBSCRIBE.

However the I-D does not cover the SUBSCRIBE method - = may I ask that it be included? Jonathan/Henning your comments are = appreciated.

Thanks and Regards,

Sriram Parameswar
Nortel Networks

------_=_NextPart_001_01C0434C.16C4B6E0-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 31 10:26:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA08094 for ; Tue, 31 Oct 2000 10:26:05 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A01EE4434E; Tue, 31 Oct 2000 09:26:05 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id DAB6A44336 for ; Tue, 31 Oct 2000 09:25:57 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id KAA15117; Tue, 31 Oct 2000 10:23:46 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <4WS2YFWA>; Tue, 31 Oct 2000 10:17:23 -0500 Message-ID: From: Jonathan Rosenberg To: "'Sriram Parameswar'" , "'sip@lists.bell-labs.com'" Subject: RE: [SIP] Preferences in SUBSCRIBE MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 31 Oct 2000 10:17:22 -0500 -----Original Message----- >From: Sriram Parameswar [mailto:sriramp@nortelnetworks.com] >Sent: Tuesday, October 31, 2000 10:06 AM >To: 'sip@lists.bell-labs.com' >Subject: [SIP] Preferences in SUBSCRIBE > > >Hi, > >From reading the I-D's on Presence and Caller Preferences, I think it would be neat to >allow watchers to send in their preferences in the SUBSCRIBE. For example 'NOTIFY me only >when John Doe comes on-line on their Mobile'. I agree such a thing is quite a good service. We had actually worked a little on creating an XML data format to describe such things, carried in the body of subscribe. > >This could be achieved if using the mobility-param [mobility = "mobile"] in an Accept- >Contact header in the SUBSCRIBE. No. Caller preferences is for a very specific, well-defined thing. Accept-Contact and Reject-Contact are solely for the purpose of filtering the URLs to which messages are delivered. They certainly can be used in SUBSCRIBE, but the meaning there is the same as INVITE - they govern the contacts to which the request is forwarded or redirected. The preferences you are asking for are different. You want to modify the conditions under which a presence agent delivers a NOTIFY request. That is not at all the same semantic. Even syntactically, preferences about subscriptions is far more complex that can be expressed in the limited syntax of caller preferences. I need to express requirements on update frequency, types of devices, specific states I want to know about, etc. These cannot be represented in the current syntax. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 31 11:02:07 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA24258 for ; Tue, 31 Oct 2000 11:02:07 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id F0E4544337; Tue, 31 Oct 2000 10:02:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from pentagon.cisco.com (pentagon.cisco.com [161.44.199.141]) by lists.bell-labs.com (Postfix) with ESMTP id A38CE44336 for ; Tue, 31 Oct 2000 10:01:32 -0500 (EST) Received: from cia.cisco.com (mirapoint@cia.cisco.com [161.44.199.157]) by pentagon.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA27562; Tue, 31 Oct 2000 11:01:23 -0500 (EST) Received: from mhammer-nt.cisco.com (va-dhcp198-137.cisco.com [161.44.198.137]) by cia.cisco.com (Mirapoint) with ESMTP id ADO04973; Tue, 31 Oct 2000 11:01:23 -0500 (EST) Message-Id: <4.3.2.7.2.20001031103325.00b59100@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Adam B. Roach" From: hammer michael Subject: Re: [SIP] New SUBSCRIBE/NOTIFY draft available Cc: sip@lists.bell-labs.com, sip-events@egroups.com In-Reply-To: <200010302108.PAA18647@b04a24.exu.ericsson.se> References: <4.3.2.7.2.20001030130617.00b3e1f0@cia.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 31 Oct 2000 11:06:45 -0800 Comments embedded. Mike At 03:08 PM 10/30/2000 -0600, Adam B. Roach wrote: > >> >Sec 5.1.6, para 7: Would immediate fetch while subscription pending be > >> >some type of 18x response? > >> > >>No. It would be a 200 response, as in a normal subscription refresh. > > > >If you send a 200, then is your statement that the "subscription is > >pending" still valid? > >By "pending," I meant "active." I'll change it to "active." Understood. > >> "Note that privacy concerns may require that notifiers either use > >> access lists or ask the user on a per-subscription basis whether > >> a particular remote node is allowed to subscribe to a certain set > >> of events. If such authorization fails, the notifier should reply > >> to the request with a "403 Forbidden" request. See section 7." > >> > >>Perhaps your confusion stems from what, exactly, is meant by "user." > >>In this context, I meant the owner of the node that is being asked > >>to act as a notifier. You may have read it such that it means the > >>owner of the node acting as a subscriber. I'll attempt to clarify > >>this text in the next draft. > > > >I think is was the "per-subscription basis" that threw me. I was thinking > >that you were deciding whether to allow the subscription based on the > >presence of a subscription list. Re-reading it, you seem to say that the > >subscription determines whether to get more information or make the > >decision with the current information. > >I'm not sure if we have this straight yet, so I'll give a >concrete example. > >Let's imagine that you are sitting in front of your PC, with a >SIP multimedia client running. You're talking to someone, and >have whatever call waiting feature that your client may have >turned off. I call and get a busy indication. I want to find >out when your terminal is free so that I may immediately ring >you back at that time. > >My client sends yours a "SUBSCRIBE." Your client may: > >a) Automatically accept the subscription, > >b) Accept the subscription only if I appear on the list > you have entered into your client of "people allowed to > subscribe to my terminal state," > >c) Accept the subscription only if I do not appear on the list > you have entered into your client of "people not allowed to > subscribe to my terminal state," or > >d) Pop up a dialog box saying "Adam Roach wants to subscribe > to your terminal state. Is that OK?" and accept the subscription > only if you click on "Yes." > >It is situation (d) that I am trying to describe. > >(Yes, there are other, more complicated criteria that allow/do-not-allow >lists that could be applied. In fact, the really useful ones probably >fall in this category). I would suggest saying: "on a per SUBSCRIBE message basis" > >> >Sec 5.2.3: Could repeated non-ACK of Notifies be used before > cancelling a > >> >subscription. It seems the subscription would be rather fragile under > >> >unreliable network conditions. That might be rather > service-dependant. I > >> >would not want a long-running subscription to a non-call-related > service to > >> >terminate just because I turned my computer off. In mobile environments, > >> >one could think of other cases where communications may be interrupted. > >> > >>This is solved by periodic subscription refreshes, just like registrations. > >>In the situation you cite (turning your computer off), the subscription > >>will be re-instantiated by your client when you start it up again. > > > >The concern that a Notify is not ack'd could still terminate a subscription > >still holds. > >No, it doesn't. If you aren't responding to NOTIFY messages, you >are obviously no longer online. Once you become available again, >you'll either immediatly send a SUBSCRIBE to put the subscription >in place (e.g. client reboot), or it will send another SUBSCRIBE >before the expiration of the current subscription. Here, you seem to agree with me that it is repeated failure to respond to more than one (1) NOTIFY message rather than the failure to respond to a single NOTIFY message, which is what the draft says. Using more than one failure would enable the time-scale of the NOTIFIES to be proportional to the time-scale of the subscription. Using multiple NOTIFYs would also give the service more leeway in deciding when to cancel the subscription short of the expires time. You seem to have some very specific scenarios in mind that are very call specific and very short timed. I would only ask that you consider whether it is possible to have much longer-term standing subscriptions. Also, in BW constrained, error prone environments (read mobile) you might want to consider the possible loss of a single message. Also, if I have more than one standing subscription, I don't necessarily want to flood the local connection every time I re-establish contact. >And, yes, such behaviour can be service specific, as you point out. >Note that the cancellation of a subscription by a notifier when >he knows that the subscriber is offline is a MAY, not a MUST or >even a SHOULD. In the last paragraph of 5.2.3 you say SHOULD. The MAY refers to the decision whether to send the NOTIFY. Enough said, there is wiggle room within the current wording. >-- >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 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 31 11:29:06 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA05660 for ; Tue, 31 Oct 2000 11:29:05 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7B2AE4435B; Tue, 31 Oct 2000 10:29:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by lists.bell-labs.com (Postfix) with ESMTP id F201344336 for ; Tue, 31 Oct 2000 02:22:51 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5u3.ericy.com [208.237.135.124]) by imr1.ericy.com (8.9.3/8.9.3) with ESMTP id CAA14963; Tue, 31 Oct 2000 02:22:44 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr5.exu.ericsson.se (8.10.2/8.10.2) with ESMTP id e9V8Kok05391; Tue, 31 Oct 2000 02:20:50 -0600 (CST) Received: from ericsson.com (kipe51.eraj.ericsson.se [147.214.68.51]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id CAA02619; Tue, 31 Oct 2000 02:22:41 -0600 (CST) Message-ID: <39FE814E.9A0F4215@ericsson.com> From: Sean Olson Organization: Ericsson Inc. X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: sip-events@egroups.com Cc: Jonathan Rosenberg , SIP List Subject: Re: [sip-events] Re: [SIP] New SUBSCRIBE/NOTIFY draft available References: <200010301638.KAA17849@b04a24.exu.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 31 Oct 2000 09:22:39 +0100 Content-Transfer-Encoding: 7bit One question on this. It was suggested that the Event: header was not needed because this information would need to be encoded in the body anyways. For this particular event: 1) What Content-Type: will we use? 2) What will be placed in the body? Or has it been decided that the Event: header is OK to leave in? /sean "Adam B. Roach" wrote: > David Shrader writes: > >What if the object being monitored ceases to exist? That is, I choose to > >monitor a call leg (from, to, call-id) and I am not a member of that call > >leg and the call ends. Does my subscription get cancelled? > > This problem appears to be solved if we add a general mechanism by > which notifiers can send a general "this subscription is now > over" NOTIFY message, as has been proposed. I intend to add this > mechanism to future version of the draft. > > -- > 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 > > -------------------------- eGroups Sponsor -------------------------~-~> > eLerts > It's Easy. It's Fun. Best of All, it's Free! > http://click.egroups.com/1/9699/16/_/782536/_/972923896/ > ---------------------------------------------------------------------_-> > > To Post a message, send it to: sip-events@eGroups.com > To Unsubscribe, send a blank message to: sip-events-unsubscribe@eGroups.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 31 11:30:43 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA06206 for ; Tue, 31 Oct 2000 11:30:43 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id F3CCA44362; Tue, 31 Oct 2000 10:29:18 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from web10303.mail.yahoo.com (web10303.mail.yahoo.com [216.136.130.81]) by lists.bell-labs.com (Postfix) with SMTP id 4283544336 for ; Tue, 31 Oct 2000 06:02:17 -0500 (EST) Message-ID: <20001031120211.89062.qmail@web10303.mail.yahoo.com> Received: from [203.200.0.5] by web10303.mail.yahoo.com; Tue, 31 Oct 2000 04:02:11 PST From: james jack To: SIP@lists.bell-labs.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [SIP] discussion Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 31 Oct 2000 04:02:11 -0800 (PST) Dear All: I have one question to ask, If an request contains One header that is not applicable according to RFC2543bis 02, for example, in REGISTER request, there appear Alert-info, Priority, how to cope with this request, 400 response code or discard this header and continue to process? Could anyone give me some advice or suggestion for processing such stuation? Best regards! Yours:james __________________________________________________ Do You Yahoo!? Yahoo! Messenger - Talk while you surf! It's FREE. http://im.yahoo.com/ _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 31 11:34:34 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA07496 for ; Tue, 31 Oct 2000 11:34:34 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5AACE44367; Tue, 31 Oct 2000 10:29:29 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lists.bell-labs.com (Postfix) with ESMTP id 2952944336 for ; Tue, 31 Oct 2000 06:16:16 -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 HAA23135; Tue, 31 Oct 2000 07:16:08 -0500 (EST) Message-Id: <200010311216.HAA23135@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@lists.bell-labs.com From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: [SIP] I-D ACTION:draft-ietf-sip-session-timer-03.txt Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 31 Oct 2000 07:16:07 -0500 --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-03.txt Pages : 22 Date : 30-Oct-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 proxies to determine if 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-03.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-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-session-timer-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001030080930.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-session-timer-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-session-timer-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001030080930.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 31 11:39:25 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA09120 for ; Tue, 31 Oct 2000 11:39:25 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0DB894435A; Tue, 31 Oct 2000 10:29:39 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 4C74144346 for ; Tue, 31 Oct 2000 08:34:59 -0500 (EST) 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 JAA04081; Tue, 31 Oct 2000 09:34:34 -0500 (EST) Message-ID: <39FED87B.606A7D99@cs.columbia.edu> From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: undisclosed-recipients:;;:; Subject: [SIP] Call for Papers: Network and Operating Systems Support for Digital Audio and Video (NOSSDAV) 2001 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 31 Oct 2000 09:34:35 -0500 Content-Transfer-Encoding: 7bit The 11th International Workshop on Network and Operating Systems Support for Digital Audio and Video (NOSSDAV 2001) Sponsored by the Association for Computing Machinery In cooperation with USENIX, ACM SIGCOMM, ACM SIGMM, ACM SIGOPS Technically cosponsored by IEEE Communications Society June 25-27, 2001 Danfords on the Sound, Port Jefferson, New York http://www.nossdav.org/2001 CALL FOR PAPERS The 11th International Workshop on Network and Operating Systems Support for Digital Audio and Video (NOSSDAV 2001) will bring together participants from academia and industry to present and discuss new ideas and future directions in networking and operating system support for multimedia. Exponential improvements in networking bandwidth, cost, and ubiquity coupled with the growing availability and use of streaming media content pose new networking and operating system research opportunities and challenges at the global systems level. We solicit papers in current or emerging areas including but not limited to ubiquitous multimedia services, broadband streaming media content distribution, webcasting, end-to-end resource management, real-time interactive streaming audio services, internet telephony, interactive network games, wireless multimedia systems, and multimedia information appliances and consumer devices. The workshop particularly encourages submission of papers describing implementations, measurements and field experience. To ensure a productive workshop environment, attendance will be limited to about 70 participants who are active in the field. Each potential participant should submit a position paper or extended abstract that identifies new problems and explains why they are important, challenges conventional wisdom, advocates a specific solution, and/or reports on actual experience with real systems. Papers will be subject to a normal review process and are restricted to five pages. Participants will be invited based on the originality, technical merit and topical relevance of their submissions, as well as the likelihood that the ideas expressed in their submissions will lead to insightful technical discussions at the workshop. Papers submitted to NOSSDAV must not have been published or submitted elsewhere. Please do not submit abbreviated versions of journal or conference papers. Authors of accepted papers will be invited to present at the workshop and publish full-length versions of their papers in the workshop proceedings. All submissions must be made through the web. For detailed guidelines for submission, please refer to the workshop web site at http://www.nossdav.org/2001. Important Dates: ================ Submission Deadline for Papers: February 15, 2001 Acceptance Notification: April 2, 2001 Camera Ready Deadline: May 15, 2001 Workshop: June 25-27, 2001 NOSSDAV 2001 Organizing Committee: ================================= Chairs: Jason Nieh, Columbia University Henning Schulzrinne, Columbia University Peter Danzig, Akamai Christophe Diot, Sprint Advanced Technology Labs Wu-chi Feng, Ohio State University Anoop Gupta, Microsoft Research Chuck Kalmanek, AT&T Research Duane Northcutt, Sun Microsystems Larry Peterson, Princeton University Larry Rowe, University of California, Berkeley Doug Shepherd, Lancaster University -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 31 11:43:58 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA10710 for ; Tue, 31 Oct 2000 11:43:58 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 904EE4437E; Tue, 31 Oct 2000 10:43:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 7A8DD4437B for ; Tue, 31 Oct 2000 10:42:06 -0500 (EST) Received: from CINQUECENTO ([63.110.3.222]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with SMTP id LAA16706; Tue, 31 Oct 2000 11:44:13 -0500 (EST) From: "Robert Sparks" To: , Subject: referred-by syntax (was RE: [SIP] (no subject)) Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: <65256987.005126F1.00@sampark.hss.hns.com> Importance: Normal Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 31 Oct 2000 10:37:49 -0600 Content-Transfer-Encoding: 7bit URL parameters are _definitely_ allowed. If your URL has a semicolon in it, it is required to be bracketed with <>, so you don't have the ambiguity you suspected. I don't follow your consistancy argument. Commas (with a few exceptions imported from HTTP) separate whole header values, not parameters within a value. RjS > > hi! > > I have a question on the syntax of the Referred-By header in > draft-sip-cc-transfer-01.txt dated September 2000. > > The syntax for this is, > > ("Referred-By"|"b")":" referrer-url ";" referenced-url [";" > ref-signature] > referrer-url = SIP URL > referenced-url = "ref" "="URL > > i am having a problem parsing this....Since referrer-url is SIP > URL it can > have urlparams which are semicolon separated "ref=" invariably maps to url > params > There is no way of knowing where the url parameters end. Is it > possible to > simplify the rule..like change that separator to a comma > ?....normally only > parameters within a header are semicolon separated, multiple fields of a > similar structure within the same header are comma separated....going by > this convention we could justify a shift form a semicolon separator to a > comma separator in the referred-by header, to ensure consistency > across the > SIP ABNF. > > Or is the use of url params in this particular header allowed?..... > > regards, > Ashok > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > > Ashok I. Roy @hss.hns.com > > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 31 11:51:30 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA13528 for ; Tue, 31 Oct 2000 11:51:30 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E36F344374; Tue, 31 Oct 2000 10:50:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 8107744373 for ; Tue, 31 Oct 2000 10:49:26 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id LAA16925; Tue, 31 Oct 2000 11:51:34 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <4WS2YGBB>; Tue, 31 Oct 2000 11:45:11 -0500 Message-ID: From: Jonathan Rosenberg To: "'sip-events@egroups.com'" , Jonathan Rosenberg Cc: huitema@microsoft.com, sip@lists.bell-labs.com Subject: RE: [sip-events] Re: [SIP] New SUBSCRIBE/NOTIFY draft available MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 31 Oct 2000 11:45:10 -0500 > -----Original Message----- > From: Adam B. Roach [mailto:adam.roach@ericsson.com] > Sent: Monday, October 30, 2000 12:03 PM > To: jdrosen@dynamicsoft.com > Cc: huitema@microsoft.com; sip@lists.bell-labs.com; > sip-events@egroups.com > Subject: [sip-events] Re: [SIP] New SUBSCRIBE/NOTIFY draft available > > > >> My hope is that, once the events draft is complete, the presence > >> draft will be somewhat thinner, and have the luxury of > concentrating > >> on presence instead of event notification. If you feel that there > >> are any generally applicable features included in the presence > >> draft which I have failed to clearly incorporate in my > draft, please > >> point them out. > > > >I believe that, in general, your draft is more or less the > distillation of > >the presence draft, modulo the above issues plus one more. > > > >That additional issue centers around your statement: > > > > > > Since forking proxies pass all 200 responses upstream, it is > > expected that these "From" fields will not contain any > tags which > > are unknown to the subscriber. However, to make the subscription > > mechanism more robust, subscribers SHOULD be prepared to receive > > notifications with previously unknown tags in the "From" field. > > > >Your assumption here is false. For non-INVITE methods, there > is only a > >single 200 OK passed upstream. > > This was changed between the bis-00 and bis-01 drafts. I will > update my draft to reflect this change. > > Compare section 12.4, "Forking Proxies": > > "2xx: The proxy MUST forward the response upstream towards > the client, > without sending an ACK downstream." > > ...versus... > > "2xx: If the request was an INVITE, the proxy MUST forward the > response upstream towards the client, without sending an > ACK downstream. For other requests, it should only forward > the response upstream if it has not forwarded any other > responses upstream." > Sending only one 200 OK for a non-INVITE is not a feature we added by fiat; sending multiple ones just doesn't work. It has to do with reliability. Remember, for non-INVITE, request retransmissions are used to ensure reliability, since they trigger response retransmissions. The client knows to stop sending requests when its gotten the response. Now, say I send the first 200 OK. The client gets this, and stops retransmitting the request, since its now gotten a response. Now I try to send a second 200 OK, and it gets lost. It never gets retransmitted. Multiple responses only work in the case of the three way handshake of the INVITE method. Since new methods are treated as non-INVITE, well, SUBSCRIBE can only have a single 200 OK. To tell you the truth, I rather like the cleanness of this. Multiple 200 handling, with ACKs and these other rules are complex. The non-INVITE handling is much cleaner and simpler. This is good since there will be people (I hope) who implement SIP for presence and never even do INVITE, since they only want IM and presence. I'd like the solution for them to be as clean as possible. > Note that this has the horrible, horrible side effect that I > can receive a 6xx (or, in timeout situations, even 4xx-5xx > responses) to a SUBSCRIBE request, never see a 200, and still > have valid outstanding subscriptions. I dislike this behaviour. Not likely. Even though a proxy only sends one 200 response, it still sends the best response it receives to all forked requests. As such, it will send a 200 OK upstream so long as any one of the forked requests generated a 200 OK. It is possible that one branch never answered, and the proxy times out, sending a 408 response upstream. This passes a 200 OK on the wire. In this case, yes, a subscription does exist even though the UA thinks there is none. This is fixed by having the UA retry the SUBSCRIBE if it timed out initially. Also, the soft state nature of SUBSCRIBE will also eventually clean things up in this rare case. > > Why do we do something so radically different for INVITE than > for anything else? Yes, I know it's needed for cleaner ACK > handling, but what harm comes from *always* proxying 200-class > responses regardless of the method? As none of us know what the > nature of future methods might be, I beleive this is folly. I think I have answered this above. > > >Besides this issue, and the ones above regarding call-leg specific > >subscriptions, I believe there is nothing different between > the two (to put > >it in Adam's terms, the presence draft is a concrete > implementation of the > >abstract class defined in his draft, without overriding any > of its methods > >:) ) I need to go over both with a fine tooth comb to be > sure, however. > > Actually, I think the presence draft still has a bunch of behavior > which I didn't capture, but still needs to be described somewhere. > The descripiton of presentities that serve as representives > of UAs for > the purpose of user presence is still a concept that needs to be > defined. Not sure what you mean. By simple definition, a presentity serve as representatives of users for the purpose of presence; there is no protocol implications of this definition. The SIP for presence draft does define the notion of a presence agent, or PA, whose function can migrate from the server to the client. Turns out that this is perfectly within the realm of your draft. Remember, UA vs. proxy are LOGICAL roles, and all that this capability is doing is saying that a server may act as a UA for one SUBSCRIBE, and then as a proxy for the refresh. We simply describe how to smoothly do this transition, your draft describes how a UA and proxy behave for handling subscriptions and notifications. Adam later writes: > David Shrader writes: > >What if the object being monitored ceases to exist? That is, > I choose to > >monitor a call leg (from, to, call-id) and I am not a member > of that call > >leg and the call ends. Does my subscription get cancelled? > > This problem appears to be solved if we add a general mechanism by > which notifiers can send a general "this subscription is now > over" NOTIFY message, as has been proposed. I intend to add this > mechanism to future version of the draft. > Thats my preference. Remember, there are other types of entities we might subscribe to whose subscription naturally terminates at some time. I'd rather have a single, general solution for this rather than several ones specific to the entity being subscribed to. Sean Olson writes: > One question on this. It was suggested that the Event: header was not > needed because this information would need to be encoded in the > body anyways. For this particular event: > > 1) What Content-Type: will we use? > 2) What will be placed in the body? > > Or has it been decided that the Event: header is OK to leave in? I'd prefer the Event header. Subscription data will often be XML, I suspect, so the type may be difficult to use. Plus, I don't like tying the semantics of the request to the syntax of the body. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 31 12:03:49 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA17782 for ; Tue, 31 Oct 2000 12:03:48 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 64A744434F; Tue, 31 Oct 2000 11:03:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by lists.bell-labs.com (Postfix) with ESMTP id A69A244336 for ; Tue, 31 Oct 2000 11:02:30 -0500 (EST) Received: from mr4u3.ericy.com (mr4u3.ericy.com [208.237.135.127]) by imr1.ericy.com (8.9.3/8.9.3) with ESMTP id LAA20837; Tue, 31 Oct 2000 11:02:20 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr4u3.ericy.com (8.9.3/8.9.3) with ESMTP id LAA09396; Tue, 31 Oct 2000 11:02:19 -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 LAA23044; Tue, 31 Oct 2000 11:02:18 -0600 (CST) Received: (from eusadam@localhost) by b04a24.exu.ericsson.se (8.9.1/8.9.1) id LAA21355; Tue, 31 Oct 2000 11:02:23 -0600 (CST) Message-Id: <200010311702.LAA21355@b04a24.exu.ericsson.se> Subject: Re: [SIP] New SUBSCRIBE/NOTIFY draft available To: mhammer@cisco.com (hammer michael) Cc: sip@lists.bell-labs.com, sip-events@egroups.com In-Reply-To: <4.3.2.7.2.20001031103325.00b59100@cia.cisco.com> from "hammer michael" at Oct 31, 2000 11:06:45 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: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 31 Oct 2000 11:02:23 -0600 (CST) Content-Transfer-Encoding: 7bit hammer michael writes: >I would suggest saying: "on a per SUBSCRIBE message basis" No, I really mean on a per-subscription basis. If you subscribe to my terminal for terminal state, I want to be asked if you're allowed to do so. However, if you refresh this subscription one minute later, I don't want to be bothered with the same question. I've already *given* you permission to subscribe. >In the last paragraph of 5.2.3 you say SHOULD. The MAY refers to the >decision whether to send the NOTIFY. Aha. We were looking at different paragraphs. Mine had to do with out-of-band methods of determining that the client is unavailable; yours had specifically to do with failure to respond to NOTIFY requests. >Enough said, there is wiggle room within the current wording. Yes, but I'd still encourage dropping a subscription if a notify fails -- allowing the SUBSCRIBE refresh to pick it back up again in the case of a transient failure. Remember that, like all other (non-INVITE, non-ACK) SIP methods, NOTIFY will retransmit 11 times over the course of 35.5 seconds. You'd have to have a network outage lasting more than half a minute to inadvertantly remove a subscription for a host that is arguably (although only weakly arguably) still connected. -- 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 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 31 12:09:39 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA19789 for ; Tue, 31 Oct 2000 12:09:39 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0AEE744342; Tue, 31 Oct 2000 11:04:05 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id C67D344336 for ; Tue, 31 Oct 2000 11:02:53 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id MAA17450; Tue, 31 Oct 2000 12:04:42 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <4WS2YG1P>; Tue, 31 Oct 2000 11:58:19 -0500 Message-ID: From: Jonathan Rosenberg To: "'james jack'" , SIP@lists.bell-labs.com Subject: RE: [SIP] discussion MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 31 Oct 2000 11:58:19 -0500 These are ignored. Thats what optional means, although this probably needs to be clarified. The text in Section 6 currently reads: The header fields required, optional and not applicable for each method are listed in Table 4 and Table 5. The table uses "o" to indicate optional, "m" mandatory and "-" for not applicable. "m*" indicates a header that SHOULD be sent, but servers need to be prepared to receive requests without that header field. A "*" indicates that the header fields are needed only if message body is not empty. See sections 6.18, 6.19 and 8 for details. I would suggest: The header fields required, optional, and not applicable for each method are listed in Table 4 and Table 5. The table uses "o" to indicate optional, "m" mandatory and "-" for not applicable. Optional means that a UAC \MAY include the header in a request, and a UAS \MAY ignore the header if present in the request. Similarly, an optional response header implies that a UAS \MAY place the header in a response, and the UAC \MAY ignore the header if present in a response it receives. A mandatory request header means the header \MUST be present in a request, and \MUST be understood by the UAS receiving the request. A mandatory response header means the header \MUST be present in the response, and the header \MUST be understood by the UAS processing the response. "Not applicable" for request headers means the header \SHOULDNOT be present in a request. If one is placed in a request, it \SHOULD be ignored by the UAS receiving the request. Similarly, a header "not applicable" for a response means the UAS \SHOULDNOT place the header in the response, and the UAC \SHOULD ignore the header in the response. "m*" indicates a header that SHOULD be sent, but servers need to be prepared to receive requests without that header field. A "*" indicates that the header fields are needed only if message body is not empty. See sections 6.18, 6.19 and 8 for details. Sound OK? --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com > -----Original Message----- > From: james jack [mailto:sipjames@yahoo.com] > Sent: Tuesday, October 31, 2000 7:02 AM > To: SIP@lists.bell-labs.com > Subject: [SIP] discussion > > > Dear All: > I have one question to ask, If an request > contains > One header that is not applicable according to > RFC2543bis > 02, for example, in REGISTER request, there appear > Alert-info, Priority, > how to cope with this request, 400 response code or > discard this header > and continue to process? > Could anyone give me some advice or suggestion > for processing such stuation? > Best regards! > Yours:james > > > > __________________________________________________ > Do You Yahoo!? > Yahoo! Messenger - Talk while you surf! It's FREE. > http://im.yahoo.com/ > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 31 12:16:30 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA22585 for ; Tue, 31 Oct 2000 12:16:30 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id BCE8B44396; Tue, 31 Oct 2000 11:07:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 6B8C144393 for ; Tue, 31 Oct 2000 11:06:50 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id MAA17514; Tue, 31 Oct 2000 12:08:58 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <4WS2YG16>; Tue, 31 Oct 2000 12:02:35 -0500 Message-ID: From: Jonathan Rosenberg To: Robert Sparks , airoy@hss.hns.com, sip@lists.bell-labs.com Subject: RE: referred-by syntax (was RE: [SIP] (no subject)) MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 31 Oct 2000 12:02:35 -0500 > -----Original Message----- > From: Robert Sparks [mailto:rsparks@dynamicsoft.com] > Sent: Tuesday, October 31, 2000 11:38 AM > To: airoy@hss.hns.com; sip@lists.bell-labs.com > Subject: referred-by syntax (was RE: [SIP] (no subject)) > > > URL parameters are _definitely_ allowed. If your URL has a > semicolon in it, > it is required to be bracketed with <>, so you don't have the > ambiguity you > suspected. I agree thats what you should do, but thats not what the grammar says. The grammar says these are just URLs. To allow for the brackets, they need to be name-addr or addr-spec. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 31 12:22:08 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA25044 for ; Tue, 31 Oct 2000 12:22:07 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id AA8814438E; Tue, 31 Oct 2000 11:18:05 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id EB3304437F for ; Tue, 31 Oct 2000 11:17:28 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id MAA17678; Tue, 31 Oct 2000 12:18:29 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <4WS2YGF8>; Tue, 31 Oct 2000 12:12:05 -0500 Message-ID: From: Igor Slepchin To: "'james jack'" , SIP@lists.bell-labs.com Subject: RE: [SIP] discussion MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 31 Oct 2000 12:12:05 -0500 If you are a proxy, copy them; if you are a UAS, ignore them if you don't care. --- Igor Slepchin > -----Original Message----- > From: james jack [mailto:sipjames@yahoo.com] > Sent: Tuesday, October 31, 2000 7:02 AM > To: SIP@lists.bell-labs.com > Subject: [SIP] discussion > > > Dear All: > I have one question to ask, If an request > contains > One header that is not applicable according to > RFC2543bis > 02, for example, in REGISTER request, there appear > Alert-info, Priority, > how to cope with this request, 400 response code or > discard this header > and continue to process? > Could anyone give me some advice or suggestion > for processing such stuation? > Best regards! > Yours:james > > > > __________________________________________________ > Do You Yahoo!? > Yahoo! Messenger - Talk while you surf! It's FREE. > http://im.yahoo.com/ > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 31 12:26:35 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA27029 for ; Tue, 31 Oct 2000 12:26:34 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3BD50443A4; Tue, 31 Oct 2000 11:22:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from june.Broomfield1.level3.net (june.Broomfield1.Level3.net [209.245.18.7]) by lists.bell-labs.com (Postfix) with ESMTP id 9E1DE44393 for ; Tue, 31 Oct 2000 11:21:37 -0500 (EST) Received: from f1ee40-19.idc1.level3.com (hme0.f1ee40-19.idc1.oss.level3.com [10.1.144.204]) by june.Broomfield1.level3.net (8.9.3/8.9.3) with ESMTP id RAA09416; Tue, 31 Oct 2000 17:21:31 GMT From: Aparna.Vemuri@Level3.com Received: from n0195idc1.oss.level3.com (localhost [127.0.0.1]) by f1ee40-19.idc1.level3.com (8.8.8+Sun/8.8.8) with ESMTP id RAA00740; Tue, 31 Oct 2000 17:21:23 GMT Received: by n0195idc1.oss.level3.com with Internet Mail Service (5.5.2650.21) id ; Tue, 31 Oct 2000 10:23:16 -0700 Message-ID: <350829A9DA9FD411841200508BF9F0600AB96E@n0217idc1.oss.level3.com> To: andrew_s_duncan@agilent.com, sip@lists.bell-labs.com Subject: RE: [SIP] Very old SIP+ question ! MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 31 Oct 2000 10:23:40 -0700 Hello. We use SIP-T as specified in the SIP-T proposal only. I do not know of any existing SIP+ implementations (that conform to Eric Zimmerer's old specification, that is). And yes, you are right, the ISUP message is encapsulated beginning with the Message Type Code (i.e., omitting Routing Label and Circuit ID Code) in SIP-T and it should've been the same in the now obsolete SIP+. I hope this answers your question. Aparna V. Level (3) Communications. -----Original Message----- From: Andy Duncan [mailto:andrew_s_duncan@agilent.com] Sent: Tuesday, October 31, 2000 7:34 AM To: sip@lists.bell-labs.com Subject: [SIP] Very old SIP+ question ! Hello, I realise SIP+ has been superceded by the amazing SIP-T proposal, but I am currently looking from a backwards compatibility viewpoint, as I understand that Level3 are currently using SIP+ in their networks (Yes/No ?) I am struggling to find any real documentation for SIP+, apart for the Inter MGC Protocol document, by Mr Zimmerer, so have one simple question that I hope somebody could take the time to answer. Does the encapsulated ISUP in a SIP+ message begin at the message type octet, like it does for SIP-T, or does it include the OPC/DPC/CIC ? Thank you, Andy ============================ Andrew S Duncan Agilent Technologies Tel: 0131 331 7822 Exten: 32822 Mailstop: SQFR&D3 ============================ _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 31 12:29:20 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA28200 for ; Tue, 31 Oct 2000 12:29:20 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 493C6443A8; Tue, 31 Oct 2000 11:27:05 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 3517044388 for ; Tue, 31 Oct 2000 11:26:51 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id MAA17800; Tue, 31 Oct 2000 12:28:29 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <4WS2YGGV>; Tue, 31 Oct 2000 12:22:05 -0500 Message-ID: From: Jonathan Rosenberg To: "'Adam B. Roach'" , Jonathan Rosenberg Cc: adamr@yahoo.com, Steve Donovan , sip@lists.bell-labs.com Subject: RE: [SIP] Re: draft-ietf-sip-session-timer-02.txt MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 31 Oct 2000 12:22:05 -0500 > -----Original Message----- > From: Adam B. Roach [mailto:Adam.Roach@Ericsson.com] > Sent: Monday, October 30, 2000 11:23 AM > To: jdrosen@dynamicsoft.com > Cc: adamr@yahoo.com; sdonovan@dynamicsoft.com; sip@lists.bell-labs.com > Subject: [SIP] Re: draft-ietf-sip-session-timer-02.txt > > > > I know this email is ancient, but I am finally > > getting around to updating > > this. So, here are some comments: > ... > > > > > > In section 4, you specify that the lack of > > > require and session-timer headers in an > > > INVITE response imply that the UAC has no > > > further actions to take. This is somewhat > > > misleading. If, for example, the UAC sends > > > a "Supported: timer" header and a > > "Session-Expires" > > > header, but receives no timer indication in the > > > response, he still should be responsible for > > > initiating the periodic re-INVITEs for his > > > own use. > > > > I disagree. In this case, neither proxies nor the > > UAS are interested in the > > timer. Why send periodic re-INVITES if no one cares? > > Because the *UAC* is interested in knowing if > the far side goes down. Perhaps a subtle point > that isn't even necessarily related to the draft. Good point. It does need to be addressed, actually. I've added text for handling this case. It'll be in the -04 version. > > > How, for > > > example, does the calling UA handle the > > > 420 response? Yes, this is fairly straightforward, > > > but I really think it should be outlined in > > > the text of the draft. > > > > Good point. This scenario is likely to be confusing > > for the > > UAC. Thats because it doesn't know session timer, > > didn't put > > a Require in the request, yet gets back a 420 Bad > > Extension. > > I recall we discussed this on the list and several > > people felt > > strongly about having the ability of proxies to put > > in Require > > despite this problem. > > Yes. If you dig back in the archives to find the > thread that started the whole session-refresh > bit, you'll find that the entire initial motivation > was to allow call-stateful proxies to have a sure-fire > way to tell whether a call is up. Remember the > proposal for the "PING" method? This is what came of > those discussions. If the final result is that > proxies cannot insist on some mechnanism to > determine liveness of a call (not just a UA -- a > *call* in particular), then this has been an > academic exercise, as far as I'm concerned. > > The point I was attempting to make by this > comment is that you should probably explicitly > point out that the UAC will treat this 420 as > any other 4xx class failure, and the call will > not be set up. I've added a note explicitly discussing this situation. > > > > - Section 8.4, the first message from the SPS > > > to the called UA should have a "Require" header > > > in it (I think). > > > > No. Proxy insertion of Require is not recommended. > > "Since the proxy requires session timer..." would > seem to imply that the proxy requires (not desires) > a session timer. If the called party doesn't support > the session timer, we need to have appropriate > handling. THis text has changed in -03 to say "want" instead of "require". > > I guess that this could be done by having the proxy > note whether the response from the UAS contains > the "Session-Expires" header, and adding it back > in if not present. This situation (UAS doesn't > support timer, UAC does, and proxy requires it) > probably warrants its own call flow. "Session Timer without Called UA Support" handles this case, excepting the proxy *desires*, not *requires* it. > > In any case, shouldn't the called UA to SPS > message contain a "Required" header to indicate > that the timer is being used for this session? > I thought this was the way that feature negotiation > worked. No; the presence of Require would tell the UAC that some feature has been applied to the response. But, in this case, the calling UA doesn't understand the feature. So, the REquire header is not appropriate. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 31 12:39:00 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA02588 for ; Tue, 31 Oct 2000 12:39:00 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C424F4438D; Tue, 31 Oct 2000 11:37:05 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id ED24E4435D for ; Tue, 31 Oct 2000 11:36:04 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id MAA17940; Tue, 31 Oct 2000 12:38:07 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <4WS2YGHR>; Tue, 31 Oct 2000 12:31:44 -0500 Message-ID: From: Jonathan Rosenberg To: "'vkg@lucent.com'" , mranga@nist.gov Cc: sip@lists.bell-labs.com Subject: RE: [SIP] Forwarding SIP Invites -- how to decide transport. MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 31 Oct 2000 12:31:43 -0500 > -----Original Message----- > From: Vijay K. Gurbani [mailto:vkg@lucent.com] > Sent: Monday, October 30, 2000 12:49 PM > To: mranga@nist.gov > Cc: sip@lists.bell-labs.com > Subject: Re: [SIP] Forwarding SIP Invites -- how to decide transport. > > > I thought UDP connect was just a programming convenience > (maybe I am > > wrong) and does not check to see if there is a client on > the recieving > > end that will get the udp packet. > > You are partially right; UDP connect, unlike TCP connect, does not > result in a 3-way handshake to ensure that the far peer > indeed exists. > All it does it to inform the kernel to record the IP address and port > number of the peer and associate it with a socket descriptor. > Further > I/O to a connected UDP peer can then use the convenient read()/recv() > primitives. Thus, it is more than a programming conbenience. > For more > information on this, consult Stevens Unix Network Programming, Volume > 1, Section 8.11 ("connect Function with UDP"). More importantly, for purposes of this discussion, connect() allows the kernel to associate ICMP error messages with a socket. Thats why the second send() results in a failure; the kernel, when it got the ICMP error, knew which socket was used initially that generated it, and so it can cause the next call to send on that same socket to generate an error. Interestingly, this capability wasn't present in Java until just recently. Igor reported this bug almost two years ago: http://developer.java.sun.com/developer/bugParade/bugs/4204320.html -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 31 12:45:09 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA04819 for ; Tue, 31 Oct 2000 12:45:09 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 10F524437C; Tue, 31 Oct 2000 11:41:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from rwcxch02.clarent.com (unknown [208.205.112.2]) by lists.bell-labs.com (Postfix) with ESMTP id 641AC4435D for ; Tue, 31 Oct 2000 11:40:54 -0500 (EST) Received: by rwcxch02.clarent.com with Internet Mail Service (5.5.2650.21) id <4V3F3X5Y>; Tue, 31 Oct 2000 09:38:32 -0800 Message-ID: <6374EFC78443D41197DD00508B5C35DD0184509A@rwcxch02.clarent.com> From: Jean-Francois Mule To: archow@hss.hns.com Cc: "'sip@lists.bell-labs.com '" Subject: RE: [SIP] SIP proxies and CSeq numbers MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 31 Oct 2000 09:38:31 -0800 (A record-route will be added in the call flow to close this discussion on the sip t.38 side). But I still believe we have a bug based on what you correctly outlined Arjun. CSeq numbers are truly relevant in the context of a sip transaction and can easily get out of sequence (sick), especially for statefull proxies. Unless the record-route header is added, we have a recipe for guaranteeing call failures. Take this other scenario where the proxy is seating between a public net & a private trusted net and the proxy requires authentication on one leg only. A -> P: authentication is required, A is in the public net. A initiates an invite (F1), P challenges A (F2) but P also sends the request to B (F3) while waiting for the credentials (proxies may act like this: the proxy knows that A comes from a known but untrusted network and has confidence the authentication should be ok so it sends the request F3 before receiving F4). Another justification for proxies to act this way may be that to check the credentials on F4, the proxy has check with a remote authentication server. P -> B: no authentication required If the UA A behaves as you stated in this scenario and sends the ACK directly to B, the CSeq=2 in the ACK: game over. Any suggestions on how do we fix this? Jean-Francois Mule' SIP UA: A Proxy SIP UA: B | | | | F1 INVITE (Cseq=1) | | |------------------------->| | | | | | F2 407 Proxy auth. req| | |<-------------------------| F3 INVITE (Cseq=1) | | |------------------------->| | F4 INVITE (Cseq=2) | | |------------------------->| | | | F5 Trying (Cseq=1) | | |<-------------------------| | F6 Trying (Cseq=2) | | |<-------------------------| | | | F7 200 OK (Cseq=1) | | |<-------------------------| | F8 200 OK (Cseq=2) | | |<-------------------------| | | | | F9 ACK (Cseq=2) ! | |---------------------------------------------------->| | | | > -----Original Message----- > From: archow@hss.hns.com [mailto:archow@hss.hns.com] > Sent: Monday, October 30, 2000 10:06 PM > To: Jean-Francois Mule > Cc: archow@hss.hns.com; 'sip@lists.bell-labs.com ' > Subject: RE: [SIP] SIP proxies and CSeq numbers (was: SIP and T.38 fax > cal ls - Internet Draft) > > > > > Jean, > Consider this situation: > > A sends an INVITE which goes through your Proxy to B. B sends > a 200 OK with > Contact as userb@here.com. > This is routed through your proxy and goes to A. > Now since A has a direct path to B (and the proxy did not do a > Record-Route), > A now sends the next request (ACK) directly to B ( protocol behaviour) > > The ACK must have the same CSeq as the INVITE although is a > transaction of > its own. But in this case, > the ACK will have the CSeq of A - P which is different from > the CSeq space > of P-B. Since ACK went directly > B would think this ACK is not valid. > The same problems will arise in any future requests within > the same call > which is forwarded directly. > > This , as you would notice induces incorrect behaviour. > > jean> PS: As for the Record-Route, it was omitted (while it > is key to proxy > jean> functions, isn't it optional after all? -- 6.34.1). > I'll add the > jean> Record-route to the next I-D revision - thanks. > > Yes, its not mandatory. However in your scenario, if you do not do > Record-Route > future request can skip your proxy who then cannot change > CSeq (if thats > needed in > the first place) > > Regds > Arjun > > -- > Arjun Roychowdhury @ Hughes Software Systems _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 31 12:49:18 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA06232 for ; Tue, 31 Oct 2000 12:49:17 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D406B4435D; Tue, 31 Oct 2000 11:46:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id A46A944336 for ; Tue, 31 Oct 2000 11:45:49 -0500 (EST) Received: from CINQUECENTO ([63.110.3.222]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with SMTP id MAA18116; Tue, 31 Oct 2000 12:47:53 -0500 (EST) From: "Robert Sparks" To: "Jonathan Rosenberg" , , Subject: RE: referred-by syntax (was RE: [SIP] (no subject)) Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: Importance: Normal Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 31 Oct 2000 11:41:29 -0600 Content-Transfer-Encoding: 7bit nod - we agreed to that (and altering the syntax to remove the ordering dependency between "scheme" and "ref") in an earlier thread. I plan to get -02 out (which reflects that suggestion) this week. RjS > > URL parameters are _definitely_ allowed. If your URL has a > > semicolon in it, > > it is required to be bracketed with <>, so you don't have the > > ambiguity you > > suspected. > > I agree thats what you should do, but thats not what the grammar says. The > grammar says these are just URLs. To allow for the brackets, they > need to be > name-addr or addr-spec. > > -Jonathan R. > --- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > http://www.dynamicsoft.com > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 31 15:48:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA06432 for ; Tue, 31 Oct 2000 15:48:05 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C487744345; Tue, 31 Oct 2000 14:48:05 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from pigeon.vovida.com (a98.vovida.com [209.237.8.98]) by lists.bell-labs.com (Postfix) with ESMTP id 739EA44340 for ; Tue, 31 Oct 2000 14:47:40 -0500 (EST) Received: from vovida.com ([209.237.8.113]) by pigeon.vovida.com (Netscape Messaging Server 4.15) with ESMTP id G3BANZ00.TFE for ; Tue, 31 Oct 2000 12:38:23 -0800 Message-ID: <39FF2FE5.68482A75@vovida.com> From: Vladislav Zubarev X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14 i686) X-Accept-Language: en, ru MIME-Version: 1.0 To: sip@lists.bell-labs.com Content-Type: multipart/alternative; boundary="------------D569EE11614D92C319398412" Subject: [SIP] Deleting media streams Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 31 Oct 2000 12:47:33 -0800 --------------D569EE11614D92C319398412 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello, I have a question about deleting media stream procedure, described in a new SIP draft (section B. 5). Let's say we opened two media streams, so now we send re-INVITE with SDP, where one of the "m=" lines contains RTP port set to 0 - we would like to delete this particular media stream. My question is what should we expect in 200 OK's SDP: should it contain the same "m=" line with RTP port set to 0 or this "m=" line should be missing at all ? Thanx. -- Vladislav Zubarev mailto:vladis@vovida.com Software Engineer Vovida Networks, Inc. http://www.vovida.com --------------D569EE11614D92C319398412 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hello,
    I have a question about deleting media stream procedure, described in a new SIP draft (section B. 5).

Let's say we opened two media streams, so now we send re-INVITE with SDP, where one of the "m="
lines contains RTP port set to 0 - we would like to delete this particular media stream.

My question is what should we expect in 200 OK's SDP: should it contain the same "m=" line with
RTP port set to 0 or this "m=" line should be missing at all ?

Thanx. 

-- 
Vladislav Zubarev        mailto:vladis@vovida.com
Software Engineer   
Vovida Networks, Inc.    http://www.vovida.com
  --------------D569EE11614D92C319398412-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 31 16:09:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA11431 for ; Tue, 31 Oct 2000 16:09:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id F2F464434F; Tue, 31 Oct 2000 15:09:05 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from elektron.elka.pw.edu.pl (elektron.elka.pw.edu.pl [194.29.160.2]) by lists.bell-labs.com (Postfix) with ESMTP id EC14D44345 for ; Tue, 31 Oct 2000 15:08:20 -0500 (EST) Received: from pn171.warszawa.cvx.ppp.tpnet.pl ([213.76.109.171]:1061 "EHLO elka.pw.edu.pl") by elektron.elka.pw.edu.pl with ESMTP id ; Tue, 31 Oct 2000 22:08:03 +0100 Message-ID: <39FF334C.DFEAEFB2@elka.pw.edu.pl> From: "Piotr S. Kossowski" Organization: Warsaw University of Technology - Institute of Telecommunications X-Mailer: Mozilla 4.7 [pl] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: SIP discussion list Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Subject: [SIP] Retransmission after provisional resp. - UAC side Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 31 Oct 2000 22:02:04 +0100 Content-Transfer-Encoding: 7bit Hello, Let me invoke retransmission thread again: Section 10.4.1 (rfc2543bis-02): "(...)If the client receives a provisional response, it continues to retransmit the request, but with an interval of T2 seconds.(...)" I'm confused or I can't understand general idea of retransmission. To my mind, Retransmission is a way for delivering 100% information from one entity (UAC) to another (UAS, proxy). Till the moment when we have not got any signal from peer that it received everything what we wanted to send, we should continue of delivering, preserving our information intact (retransmission should not carry new information). That's general rule. As a server send provisional response It means that it received 100 % of our information - request (at least, we assuming so). Thus, Retransmission of request will not supply new information to the server (and shouldn't change server's state). My question is: What is the reason for retransmiting of request, even thouht the server has confirmed reception of our request (by sending provisional response) ? Thanks in advance, Piotr _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 31 16:17:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA13411 for ; Tue, 31 Oct 2000 16:17:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A1E664434F; Tue, 31 Oct 2000 15:17:05 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cybertron.div8.net (el05-24-131-150-91.ce.mediaone.net [24.131.150.91]) by lists.bell-labs.com (Postfix) with ESMTP id E4B1C44340 for ; Tue, 31 Oct 2000 15:16:37 -0500 (EST) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for sip@lists.bell-labs.com; Tue, 31 Oct 2000 15:16:19 -0600 (CST) From: Billy Biggs To: "Piotr S. Kossowski" Cc: SIP discussion list Subject: Re: [SIP] Retransmission after provisional resp. - UAC side Message-ID: <20001031151619.A32351@div8.net> References: <39FF334C.DFEAEFB2@elka.pw.edu.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i In-Reply-To: <39FF334C.DFEAEFB2@elka.pw.edu.pl>; from P.Kossowski@elka.pw.edu.pl on Tue, Oct 31, 2000 at 10:02:04PM +0100 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 31 Oct 2000 15:16:19 -0600 Piotr S. Kossowski (P.Kossowski@elka.pw.edu.pl): > "(...)If the client receives a provisional response, it continues to > retransmit the request, but with an interval of T2 seconds.(...)" > > [...] > > My question is: What is the reason for retransmiting of request, even > thouht the server has confirmed reception of our request (by sending > provisional response) ? To poll for a final response which may have been lost. -- Billy Biggs, 3Com Email: Billy_Biggs@3com.com http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 31 16:38:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17989 for ; Tue, 31 Oct 2000 16:38:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id F36604433C; Tue, 31 Oct 2000 15:38:04 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 0ED9A44339 for ; Tue, 31 Oct 2000 15:37:06 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id QAA21866; Tue, 31 Oct 2000 16:38:58 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <4WS2YHBD>; Tue, 31 Oct 2000 16:32:34 -0500 Message-ID: From: Jonathan Rosenberg To: "'Vladislav Zubarev'" , sip@lists.bell-labs.com Subject: RE: [SIP] Deleting media streams MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 31 Oct 2000 16:32:34 -0500 -----Original Message----- From: Vladislav Zubarev [mailto:vladis@vovida.com] Sent: Tuesday, October 31, 2000 3:48 PM To: sip@lists.bell-labs.com Subject: [SIP] Deleting media streams >Hello, > I have a question about deleting media stream procedure, described in a new SIP draft >(section B. 5). > >Let's say we opened two media streams, so now we send re-INVITE with SDP, where one of the >"m=" > >lines contains RTP port set to 0 - we would like to delete this particular media stream. > >My question is what should we expect in 200 OK's SDP: should it contain the same "m=" line >with > >RTP port set to 0 or this "m=" line should be missing at all ? Same m line with port 0. There must always be the same number of m lines in the request as in the response. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 31 16:40:07 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA18439 for ; Tue, 31 Oct 2000 16:40:06 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D26794435F; Tue, 31 Oct 2000 15:40:05 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 3A0404433C for ; Tue, 31 Oct 2000 15:39:51 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id QAA21918; Tue, 31 Oct 2000 16:41:50 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <4WS2YHBM>; Tue, 31 Oct 2000 16:35:26 -0500 Message-ID: From: Jonathan Rosenberg To: "'Piotr S. Kossowski'" , SIP discussion list Subject: RE: [SIP] Retransmission after provisional resp. - UAC side MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-2" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 31 Oct 2000 16:35:26 -0500 Reliability of the responses, since responses are re-sent based on request retransmissions. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com > -----Original Message----- > From: Piotr S. Kossowski [mailto:P.Kossowski@elka.pw.edu.pl] > Sent: Tuesday, October 31, 2000 4:02 PM > To: SIP discussion list > Subject: [SIP] Retransmission after provisional resp. - UAC side > > > Hello, > > Let me invoke retransmission thread again: > > Section 10.4.1 (rfc2543bis-02): > > "(...)If the client receives a provisional response, it continues to > retransmit the request, but with an interval of T2 seconds.(...)" > > I'm confused or I can't understand general idea of retransmission. > > To my mind, Retransmission is a way for delivering 100% information > from one entity (UAC) to another (UAS, proxy). Till the moment > when we have not got any signal from peer that it received > everything what we wanted to send, we should continue of delivering, > preserving our information intact (retransmission should not carry > new information). That's general rule. > > As a server send provisional response It means that it received > 100 % of our information - request (at least, we assuming so). Thus, > Retransmission of request will not supply new information to > the server > (and shouldn't change server's state). > > My question is: What is the reason for retransmiting of request, > even thouht the server has confirmed reception of our request > (by sending provisional response) ? > > Thanks in advance, > Piotr > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Oct 31 20:45:08 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA14255 for ; Tue, 31 Oct 2000 20:45:07 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9548644337; Tue, 31 Oct 2000 19:45:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by lists.bell-labs.com (Postfix) with ESMTP id CD6ED44336 for ; Tue, 31 Oct 2000 19:44:34 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5u3.ericy.com [208.237.135.124]) by imr1.ericy.com (8.9.3/8.9.3) with ESMTP id TAA29135; Tue, 31 Oct 2000 19:44:29 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr5.exu.ericsson.se (8.10.2/8.10.2) with ESMTP id eA11gXk20784; Tue, 31 Oct 2000 19:42:33 -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 TAA17235; Tue, 31 Oct 2000 19:44:28 -0600 (CST) Received: (from eusadam@localhost) by b04a24.exu.ericsson.se (8.9.1/8.9.1) id TAA24185; Tue, 31 Oct 2000 19:44:33 -0600 (CST) Message-Id: <200011010144.TAA24185@b04a24.exu.ericsson.se> Subject: Re: [SIP] Re: draft-ietf-sip-session-timer-02.txt To: jdrosen@dynamicsoft.com (Jonathan Rosenberg) Cc: jdrosen@dynamicsoft.com (Jonathan Rosenberg), adamr@yahoo.com, sdonovan@dynamicsoft.com (Steve Donovan), sip@lists.bell-labs.com In-Reply-To: from "Jonathan Rosenberg" at Oct 31, 2000 12:22:05 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: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 31 Oct 2000 19:44:33 -0600 (CST) Content-Transfer-Encoding: 7bit Jonathan Rosenberg writes: >> In any case, shouldn't the called UA to SPS >> message contain a "Required" header to indicate >> that the timer is being used for this session? >> I thought this was the way that feature negotiation >> worked. > >No; the presence of Require would tell the UAC that some >feature has been applied to the response. But, in this case, >the calling UA doesn't understand the feature. So, the REquire >header is not appropriate. Aha. Yes, that makes sense. I think the text in the draft clarifying this point is new (or I missed it the first time around). A quick glance through the current draft looks good. I'll get out my fine-toothed comb in a bit and see if I find any other minor glitches. -- 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 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip