From sip-admin@lists.bell-labs.com Fri Sep 1 01:46: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 ESMTP id BAA27132 for ; Fri, 1 Sep 2000 01:46: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 3A96D4437F; Fri, 1 Sep 2000 00:46: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 50A0E44364 for ; Fri, 1 Sep 2000 00:46:01 -0400 (EDT) Received: from dynamicsoft.com (1Cust105.tnt1.freehold.nj.da.uu.net [63.17.113.105]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA05018; Fri, 1 Sep 2000 01:47:43 -0400 (EDT) Message-ID: <39AF425A.3AB2DC92@dynamicsoft.com> Date: Fri, 01 Sep 2000 01:44:58 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Benny Prijono Cc: sip@lists.bell-labs.com Subject: Re: [SIP] recvonly/sendonly in SDP References: <049e01c00ba3$adadfed0$3202a8c0@broadsoft.com> <39A4BB82.19559938@dynamicsoft.com> <39A52333.A1E79D73@cs.columbia.edu> <39A5F723.7C8909E0@dynamicsoft.com> <39A6BB92.EB836D5E@cs.columbia.edu> <39AD13C0.726915D6@switchlab.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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Changing this would break backwards compatibility. We were aware of this at writing time, and in fact mention this: > The interpretation of send-only and receive-only for multicast media > sessions differs from that for unicast sessions. For multicast, > send-only means that the recipient of the session description (caller > or callee) SHOULD only send media streams to the address and port > indicated. Receive-only means that the recipient of the session > description SHOULD only receive media on the address and port > indicated. The reason is that multicast and unicast are quite different. For everything else in the SDP sent in the INVITE, the information reflects the perspective of the sender of the SDP. This is the reason we did it this way. We could either be consistent with the meaning of the rest of the parameters, or be consistent with multicast. We chose the former. -Jonathan R. Benny Prijono wrote: > > Hello all, > > As Henning has pointed out below regarding the meaning of > recvonly/sendonly attribute in SDP body, it seems that there's an > incompatibility between SDP draft and SIP one. > > Has this been confirmed to the SDP authors? Because I got the > impression that Henning was not sure about this. And if this is really > the case, then has a consensus been made regarding which one to use? > > Personally, although I have implemented them as in the SIP draft, I > don't mind if it has to be changed. > > cheers, > Bennylp > > Henning Schulzrinne wrote: > > > > > > Finally, there's a small bug in the current definition of the send-only > > and receive-only description in Section B.2. RFC 2327 says: > > > > a=recvonly > > This specifies that the tools should be started in receive-only > > mode where applicable. It can be either a session or media > > attribute, and is not dependent on charset. > > > > This is presumably from the viewpoint of the receiver of the SDP. (This > > would certainly be true if I used SDP to invite somebody to a multicast > > conference.) Thus, if the caller wants to only send, it should > > logically include a 'recvonly' in its SDP, since that's what the > > receiver of the SDP (the callee) would have to do. > > > > In the current SIP B.2 definition, > > > > If a session description from a caller contains a media stream which > > is listed as send (receive) only, it means that the caller is only > > willing to send (receive) this stream, not receive (send). The same > > is true for the callee. > > > > This says the opposite: the caller that only sends would set the > > description to send-only. It may be too late to fix this, depending on > > whether anybody actually implements sendonly and recvonly. > > > > -- > > Henning Schulzrinne http://www.cs.columbia.edu/~hgs > > > > _______________________________________________ > 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: (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 Fri Sep 1 02:26: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 ESMTP id CAA05333 for ; Fri, 1 Sep 2000 02:26: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 3FFBA4437B; Fri, 1 Sep 2000 01:26: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 DF09344364 for ; Fri, 1 Sep 2000 01:26:02 -0400 (EDT) Received: from dynamicsoft.com (1Cust105.tnt1.freehold.nj.da.uu.net [63.17.113.105]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA05050; Fri, 1 Sep 2000 02:24:01 -0400 (EDT) Message-ID: <39AF4ADB.B8751B55@dynamicsoft.com> Date: Fri, 01 Sep 2000 02:21:15 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Neil Deason Cc: Loita Jahnsson , jhornsby@ubiquity.net, sip@lists.bell-labs.com Subject: Re: [SIP] transaction identification References: <002e01c011c2$94a85000$4e34c3c1@ubiquity.co.uk> <39AC83A0.68A61CA@dynamicsoft.com> <39AE1096.95161017@uab.ericsson.se> <39AE38A0.526A55F8@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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Neil Deason wrote: > > > You might want to consider the case below though: > > > > *************************************************************************** > > > > ---------> u1@p2 ---> ub1@cb1 > > | > > ua@ca ------> u@p ---------> u2@p2 ---> ub2@cb2 > > > > > > ca sends an INVITE to u@p, which forks the request to > > different users. As it turns out, both ub1@cb1 and ub2@cb2 sends > > a 200 OK and "p" happens to be able to forward multiple 200 OK's. > > ca is an implementation that could actually ACK both of the 200 OK's > > and setup and represent parallell media sessions towards both cb1 > > and cb2 for the single SIP session. > > > > Imagine "p" implementing some service or controlling a > > firewall or media proxy for example. "p" would then have to > > keep the different "sub-sessions" apart, because, cb1 & cb2 > > could hang up at different occasions. > > > > Consider "p" and "p2" to be Record-Routing. > > > > When cb2 hangs up it would appear in "p" as: > > > > BYE ua@ca, Route ua@ca > > > > and when cb1 hangs up it would appear in the proxy as: > > > > BYE ua@ca, Route ua@ca > > > > How should "p" be able to determine which "sub-session" the BYE > > is for? > > >From p's point of view the topmost Via would be different > thus identifying the two possible BYEs as non isomorphic > requests. Also in this example a tag in the From > differentiates the call legs if the proxy needs to be > call stateful for some specialised service. Correct; the tag differentiates. Jo previously wrote: > > I am missing something here; why does this eliminate loop detection? > > It doesn't eliminate Loop Detection, but it means that you don't > need to waste time decrypting Vias to check for loops. > > Previously, I was concerned that this was a bogus approach, since > if you attempt to detect Loops by decrypting Vias, any ACKs or > CANCELs relating to this request would be ambiguous (would they be > for the "first" time you "saw" the request, or for the "second"?). > This is because there was no guarantee that the branch parameter > would be different in each case. > > Requiring that the branch parameter is always unique alleviates > this problem; however, since you suggest adding some other > invariant, it now becomes possible for a proxy to identify its > "own" branch parameters. Thus decrypting Vias for the sole > purpose of checking for Loops becomes rendundant. > I think you are saying that if the branch ID contains a component that can identify the server itself, the server can find Via headers it inserted? So, let me try to summarize: 1. a request is matched to a transaction ID through a hash of (request URI, To, From, Call-ID, CSeq, topmost Via), where the hash is done over "canonical" representations of these (ie, you don't want insertion of a white space to screw it up). The ACK and CANCEL use the same thing in a PROXY (note this doesn't work for ACK in a UAS since the ACK can take a different path entirely. One of the nasty things I really don't like). So, for a UAS, you have two keys - one with the topmost Via, one without. If there is no match on the key with the via for the ACK, you try the one without. 2. the branch ID, in addition to the two components mentioned in the bis draft, also now contains a third piece, which is sufficient extra info to make the branch ID unique across all transactions as defined in 1. Note that this uniqueness piece must be separable -i.e., you can't include it in the hash of the incoming R-URI, TO, From,CSeq, Call-ID defined in bis. Otherwise, you can't detect spirals. This could be the transaction ID + server instance. Does that sound right? -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 Fri Sep 1 02:40: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 ESMTP id CAA05631 for ; Fri, 1 Sep 2000 02:40: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 D9CF244381; Fri, 1 Sep 2000 01:40:00 -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 8BFF54437A for ; Fri, 1 Sep 2000 01:39:57 -0400 (EDT) Received: from dynamicsoft.com (1Cust105.tnt1.freehold.nj.da.uu.net [63.17.113.105]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA05079; Fri, 1 Sep 2000 02:41:26 -0400 (EDT) Message-ID: <39AF4EF1.2A757C2@dynamicsoft.com> Date: Fri, 01 Sep 2000 02:38:41 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Henning Schulzrinne Cc: Paul Krumviede , Michael Thomas , David Harris , sip Subject: Re: [SIP] Re: SIP gateways and authentication References: <843805530.967211447@sjo-dhcp0181.mcit.com> <39A9D4EF.BA761047@dynamicsoft.com> <39AAC59E.5022DAD8@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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > > I'll repeat my question, since the answer matters greatly: are you > talking about Basic/Digest or PGP authentication? > > Since that's what's implemented, I'm assuming Basic/Digest for now. > > With Basic/Digest, it only matters what name(s) and associated secrets > the receiving proxy recognizes. If it recognizs gateway:spoiled-milk for > all request-URIs, that's fine, but it's not clear what establishing a > canonical user name, realm or password accomplishes. > > In any event, the secret has to be hard-configured for each gateway. For > the proxy and UA case, > > sip:1234@proxy.com > ...realm="foo" > and > sip:456@proxy.com > ...realm="foo" > > are different protection spaces. > > As a guide to implementors, it may be useful to indicate that if you > don't care about different authentications for different request-URIs, > it makes sense to establish a "global" user name/password/realm that's > the default challenge if a particular user name doesn't have its own > realm or set of user names. Similarly, gateways may want to try their > global user name and secret when challenged. This is what I am trying to get at. This global username/password/realm needs to be mentioned somewhere. I suppose since you need to configure a username/password anyway, you can also configure the realm for this (i.e., we need not define any special syntax for a global realm). What we do need to do is ensure that discussion of this concept appears in the specs, so that implementors support such a concept. The text above is probably right on target. Can we add it in? -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 Fri Sep 1 02:54: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 ESMTP id CAA05764 for ; Fri, 1 Sep 2000 02:54: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 112D444388; Fri, 1 Sep 2000 01:53:13 -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 3CA4244379 for ; Fri, 1 Sep 2000 01:53: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 e816r7p18445; Fri, 1 Sep 2000 08:53:07 +0200 (MEST) Received: from ericsson.fi (E0080C7FA22D6.lmf.ericsson.se [131.160.30.48]) by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id JAA21388; Fri, 1 Sep 2000 09:53:07 +0300 (EET DST) Message-ID: <39AF51F7.CDBFE713@ericsson.fi> Date: Fri, 01 Sep 2000 09:51:35 +0300 From: Hisham Khartabil X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: Neil Deason , Loita.Jahnsson@uab.ericsson.se, jhornsby@ubiquity.net, sip@lists.bell-labs.com Subject: Re: [SIP] transaction identification References: <002e01c011c2$94a85000$4e34c3c1@ubiquity.co.uk> <39AC83A0.68A61CA@dynamicsoft.com> <39AE1096.95161017@uab.ericsson.se> <39AE38A0.526A55F8@ubiquity.net> <39AF4ADB.B8751B55@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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit > > So, let me try to summarize: > > 1. a request is matched to a transaction ID through a hash of (request > URI, To, From, Call-ID, CSeq, topmost Via), where the hash is done over > "canonical" representations of these (ie, you don't want insertion of a > white space to screw it up). The ACK and CANCEL use the same thing in a > PROXY (note this doesn't work for ACK in a UAS since the ACK can take a > different path entirely. One of the nasty things I really don't like). > So, for a UAS, you have two keys - one with the topmost Via, one > without. If there is no match on the key with the via for the ACK, you > try the one without. The way we get around getting a spiraled request with whitespaces added it by calculating the hash of the parsed form of the headers forming a sting without the spaces (eg: user+host+port+tag+... of To plus cseqnum+method ... and so on, ie eliminating the spaces). how does that sound > > > 2. the branch ID, in addition to the two components mentioned in the bis > draft, also now contains a third piece, which is sufficient extra info > to make the branch ID unique across all transactions as defined in 1. > Note that this uniqueness piece must be separable -i.e., you can't > include it in the hash of the incoming R-URI, TO, From,CSeq, Call-ID > defined in bis. Otherwise, you can't detect spirals. This could be the > transaction ID + server instance. Would this be just for the encrypted via headers only? Regards, Hisham > > > Does that sound right? > > -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 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Sep 1 03:07: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 ESMTP id DAA05935 for ; Fri, 1 Sep 2000 03:07: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 55C4D44341; Fri, 1 Sep 2000 02:06:52 -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 5B40844336 for ; Fri, 1 Sep 2000 02:06:48 -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 e8176bp24605; Fri, 1 Sep 2000 09:06:37 +0200 (MEST) Received: from uabx04c148.uab.ericsson.se.uab.ericsson.se (uabx04c148 [134.138.228.163]) by ms.uab.ericsson.se (8.10.0/8.10.0/uab-2.26) with ESMTP id e8176bL18638; Fri, 1 Sep 2000 09:06:37 +0200 (MET DST) Received: from uab.ericsson.se by uabx04c148.uab.ericsson.se.uab.ericsson.se (8.8.7/client-1.3uab1) id JAA01354; Fri, 1 Sep 2000 09:06:32 +0200 (MET DST) Message-ID: <39AF5578.CE1367E8@uab.ericsson.se> Date: Fri, 01 Sep 2000 09:06:32 +0200 From: Loita Jahnsson Organization: Ericsson Utvecklings AB X-Mailer: Mozilla 4.7C-CCK-MCD [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: sv,en-US MIME-Version: 1.0 To: Neil Deason , sip@lists.bell-labs.com Subject: Re: [SIP] transaction identification References: <002e01c011c2$94a85000$4e34c3c1@ubiquity.co.uk> <39AC83A0.68A61CA@dynamicsoft.com> <39AE1096.95161017@uab.ericsson.se> <39AE38A0.526A55F8@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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Hi, > > ---------> u1@p2 ---> ub1@cb1 > | > ua@ca ------> u@p ---------> u2@p2 ---> ub2@cb2 > [ ... ] > > From p's point of view the topmost Via would be different > thus identifying the two possible BYEs as non isomorphic > requests. OK, that's fine, what is unclear to me is how the two calls would be separated. > Also in this example a tag in the From > differentiates the call legs if the proxy needs to be > call stateful for some specialised service. I thought all SIP messages through "p" in my example would share the same call leg. Are you implying that proxy "p" would modify the From, add it's own tag and thus have different call legs in different directions? Could you please extend your answer? Thanks, Best Regards, Loita Jahnsson SIP SW Designer _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Sep 1 03:13: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 ESMTP id DAA05969 for ; Fri, 1 Sep 2000 03:13:53 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 92E334434B; Fri, 1 Sep 2000 02:12:38 -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 0095744336 for ; Fri, 1 Sep 2000 02:12:34 -0400 (EDT) Received: from dynamicsoft.com (1Cust105.tnt1.freehold.nj.da.uu.net [63.17.113.105]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id DAA05137; Fri, 1 Sep 2000 03:12:32 -0400 (EDT) Message-ID: <39AF563A.8EEB995@dynamicsoft.com> Date: Fri, 01 Sep 2000 03:09:46 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Hisham Khartabil Cc: Neil Deason , Loita.Jahnsson@uab.ericsson.se, jhornsby@ubiquity.net, sip@lists.bell-labs.com Subject: Re: [SIP] transaction identification References: <002e01c011c2$94a85000$4e34c3c1@ubiquity.co.uk> <39AC83A0.68A61CA@dynamicsoft.com> <39AE1096.95161017@uab.ericsson.se> <39AE38A0.526A55F8@ubiquity.net> <39AF4ADB.B8751B55@dynamicsoft.com> <39AF51F7.CDBFE713@ericsson.fi> 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Hisham Khartabil wrote: > > > > > So, let me try to summarize: > > > > 1. a request is matched to a transaction ID through a hash of (request > > URI, To, From, Call-ID, CSeq, topmost Via), where the hash is done over > > "canonical" representations of these (ie, you don't want insertion of a > > white space to screw it up). The ACK and CANCEL use the same thing in a > > PROXY (note this doesn't work for ACK in a UAS since the ACK can take a > > different path entirely. One of the nasty things I really don't like). > > So, for a UAS, you have two keys - one with the topmost Via, one > > without. If there is no match on the key with the via for the ACK, you > > try the one without. > > The way we get around getting a spiraled request with whitespaces added it by > calculating the hash of the parsed form of the headers forming a sting without the > spaces (eg: user+host+port+tag+... of To plus cseqnum+method ... and so on, ie > eliminating the spaces). how does that sound Fine. Same as canonicalization. > > > > > > > 2. the branch ID, in addition to the two components mentioned in the bis > > draft, also now contains a third piece, which is sufficient extra info > > to make the branch ID unique across all transactions as defined in 1. > > Note that this uniqueness piece must be separable -i.e., you can't > > include it in the hash of the incoming R-URI, TO, From,CSeq, Call-ID > > defined in bis. Otherwise, you can't detect spirals. This could be the > > transaction ID + server instance. > > Would this be just for the encrypted via headers only? Well, nearly as I can tell it would only be needed if there is Via hiding being done. -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 Fri Sep 1 03:17:29 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06064 for ; Fri, 1 Sep 2000 03:17: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 B299B4435B; Fri, 1 Sep 2000 02:13:42 -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 4375244336 for ; Fri, 1 Sep 2000 02:13:38 -0400 (EDT) Received: from dynamicsoft.com (1Cust105.tnt1.freehold.nj.da.uu.net [63.17.113.105]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id DAA05145; Fri, 1 Sep 2000 03:15:21 -0400 (EDT) Message-ID: <39AF56E4.B838709D@dynamicsoft.com> Date: Fri, 01 Sep 2000 03:12:36 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Loita Jahnsson Cc: Neil Deason , sip@lists.bell-labs.com Subject: Re: [SIP] transaction identification References: <002e01c011c2$94a85000$4e34c3c1@ubiquity.co.uk> <39AC83A0.68A61CA@dynamicsoft.com> <39AE1096.95161017@uab.ericsson.se> <39AE38A0.526A55F8@ubiquity.net> <39AF5578.CE1367E8@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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Loita Jahnsson wrote: > > Hi, > > > > > ---------> u1@p2 ---> ub1@cb1 > > | > > ua@ca ------> u@p ---------> u2@p2 ---> ub2@cb2 > > > [ ... ] > > > > From p's point of view the topmost Via would be different > > thus identifying the two possible BYEs as non isomorphic > > requests. > > OK, that's fine, what is unclear to me is how the two > calls would be separated. > > > Also in this example a tag in the From > > differentiates the call legs if the proxy needs to be > > call stateful for some specialised service. > > I thought all SIP messages through "p" in my example would > share the same call leg. No; call legs have nothing to do with proxies. ub1@cb1 will insert a tag into the To field into the 200 OK. So will ub2@cb2, but these tags are both different. When ub1 hangs up, it places its tag in its From field, and ub2@cb2 places its tag in the BYE. Thus, the two BYEs differ in the From field, and thus will appear to u to be different transactions. -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 Fri Sep 1 03:44: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 ESMTP id DAA06458 for ; Fri, 1 Sep 2000 03:44: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 C6D0844339; Fri, 1 Sep 2000 02:44:34 -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 89CA644336 for ; Fri, 1 Sep 2000 02:44:31 -0400 (EDT) Received: from dynamicsoft.com (1Cust105.tnt1.freehold.nj.da.uu.net [63.17.113.105]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id DAA05179; Fri, 1 Sep 2000 03:46:17 -0400 (EDT) Message-ID: <39AF5E23.A98F4EC9@dynamicsoft.com> Date: Fri, 01 Sep 2000 03:43:31 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Hong Chen Cc: sip@lists.bell-labs.com Subject: Re: [SIP] SIP feature services References: <39AEACDE.F5686B52@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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Hong Chen wrote: > > Dear All: > > I would like to initial discussion on what the best > systematic/consistent way to invoke network feature services by SIP > signaling without > losing SIP advantages. You mean what protocol would one use to talk to an application server that provides SIP features? Thats easy - 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: (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 Fri Sep 1 05:24: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 ESMTP id FAA07198 for ; Fri, 1 Sep 2000 05:24: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 D1B214434A; Fri, 1 Sep 2000 04:24:10 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id 235F644336 for ; Fri, 1 Sep 2000 04:24:05 -0400 (EDT) Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id KAA01878; Fri, 1 Sep 2000 10:21:50 +0100 (BST) From: "Jo Hornsby" To: "Jonathan Rosenberg" , "Neil Deason" Cc: "Loita Jahnsson" , Subject: RE: [SIP] transaction identification Date: Fri, 1 Sep 2000 10:21:49 +0100 Message-ID: <004b01c013f6$0ea96940$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: <39AF4ADB.B8751B55@dynamicsoft.com> Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit > I think you are saying that if the branch ID contains a component that > can identify the server itself, the server can find Via headers it > inserted? Yes -- very much so. > So, let me try to summarize: > > 1. a request is matched to a transaction ID through a hash of (request > URI, To, From, Call-ID, CSeq, topmost Via), where the hash is done over > "canonical" representations of these (ie, you don't want insertion of a > white space to screw it up). The ACK and CANCEL use the same thing in a > PROXY (note this doesn't work for ACK in a UAS since the ACK can take a > different path entirely. One of the nasty things I really don't like). > So, for a UAS, you have two keys - one with the topmost Via, one > without. If there is no match on the key with the via for the ACK, you > try the one without. Yup. I might to be inclined to s/hash/combination/g, however, to not restrict the implementation? > 2. the branch ID, in addition to the two components mentioned in the bis > draft, also now contains a third piece, which is sufficient extra info > to make the branch ID unique across all transactions as defined in 1. > Note that this uniqueness piece must be separable -i.e., you can't > include it in the hash of the incoming R-URI, TO, From,CSeq, Call-ID > defined in bis. Otherwise, you can't detect spirals. This could be the > transaction ID + server instance. > > Does that sound right? Sounds good to me. 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 Sep 1 05:59: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 ESMTP id FAA07445 for ; Fri, 1 Sep 2000 05:59: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 BBECB4434C; Fri, 1 Sep 2000 04:59: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 A8F1344336 for ; Fri, 1 Sep 2000 04:59:05 -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 e819wkp28222; Fri, 1 Sep 2000 11:58:46 +0200 (MEST) Received: from uabx04c148.uab.ericsson.se.uab.ericsson.se (uabx04c148 [134.138.228.163]) by ms.uab.ericsson.se (8.10.0/8.10.0/uab-2.26) with ESMTP id e819wjL15457; Fri, 1 Sep 2000 11:58:45 +0200 (MET DST) Received: from uab.ericsson.se by uabx04c148.uab.ericsson.se.uab.ericsson.se (8.8.7/client-1.3uab1) id LAA01529; Fri, 1 Sep 2000 11:58:41 +0200 (MET DST) Message-ID: <39AF7DD1.2AE4EDE7@uab.ericsson.se> Date: Fri, 01 Sep 2000 11:58:41 +0200 From: Loita Jahnsson Organization: Ericsson Utvecklings AB X-Mailer: Mozilla 4.7C-CCK-MCD [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: sv,en-US MIME-Version: 1.0 To: Jonathan Rosenberg , sip@lists.bell-labs.com Subject: Re: [SIP] transaction identification References: <002e01c011c2$94a85000$4e34c3c1@ubiquity.co.uk> <39AC83A0.68A61CA@dynamicsoft.com> <39AE1096.95161017@uab.ericsson.se> <39AE38A0.526A55F8@ubiquity.net> <39AF5578.CE1367E8@uab.ericsson.se> <39AF56E4.B838709D@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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Hi, > > I thought all SIP messages through "p" in my example would > > share the same call leg. > > No; call legs have nothing to do with proxies. > > ub1@cb1 will insert a tag into the To field into the 200 OK. So will > ub2@cb2, but these tags are both different. When ub1 hangs up, it places > its tag in its From field, and ub2@cb2 places its tag in the BYE. Thus, > the two BYEs differ in the From field, and thus will appear to u to be > different transactions. > Thanks for your quick response, I still feel a bit lost however. I appreciate the possibility to separate the BYE transactions in "p". The things I don't quite understand is: (i) When ub1@cb1 & ub2@cb2 hangs up, I thought they didn't necessarily have to insert tags the From field. When I read in the spec I only find this about the From tag: "It MUST be present when it is possible that two instances of a user sharing a SIP address can make call invitations with the same call-ID". How does that apply to ub1@cb1 and ub2@cb2 in the above scenario? (ii) Imagine proxy "p" implementing a service or doing something like controlling a firewall for example. To be able to do this it needs to be call stateful in some respect. Right now I could only visualize two ways of achieving call statefullness in "p"; (a) either you add the "call state information" as parameters as you proxy the messages and pray that the client in the other end doesn't remove that data when sending responses, generating new requests or whatever. Or (b) actually keeping "call state" for each call within the proxy. If you prefer (b), you need some way of identifying the different calls (not only transactions). As I would have imagined this would be call leg + possibly some other information. Now I am trying to apply the "call leg has nothing to do with proxies" statement for a "(b)" proxy implementation. And that's where I get lost. Could you please explain some more? Thanks, Best Regards, Loita Jahnsson SIP SW Designer _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Sep 1 06: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 ESMTP id GAA07553 for ; Fri, 1 Sep 2000 06:06: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 2434844418; Fri, 1 Sep 2000 05:01:57 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id 6BD7A443D5 for ; Fri, 1 Sep 2000 05:01:47 -0400 (EDT) Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id KAA13557; Fri, 1 Sep 2000 10:59:48 +0100 (BST) Message-ID: <39AF7E14.FE7886BB@ubiquity.net> Date: Fri, 01 Sep 2000 10:59:48 +0100 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: Hisham Khartabil , Loita.Jahnsson@uab.ericsson.se, jhornsby@ubiquity.net, sip@lists.bell-labs.com Subject: Re: [SIP] transaction identification References: <002e01c011c2$94a85000$4e34c3c1@ubiquity.co.uk> <39AC83A0.68A61CA@dynamicsoft.com> <39AE1096.95161017@uab.ericsson.se> <39AE38A0.526A55F8@ubiquity.net> <39AF4ADB.B8751B55@dynamicsoft.com> <39AF51F7.CDBFE713@ericsson.fi> <39AF563A.8EEB995@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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > Hisham Khartabil wrote: [...] > > > 2. the branch ID, in addition to the two components mentioned in the bis > > > draft, also now contains a third piece, which is sufficient extra info > > > to make the branch ID unique across all transactions as defined in 1. > > > Note that this uniqueness piece must be separable -i.e., you can't > > > include it in the hash of the incoming R-URI, TO, From,CSeq, Call-ID > > > defined in bis. Otherwise, you can't detect spirals. This could be the > > > transaction ID + server instance. > > > > Would this be just for the encrypted via headers only? > > Well, nearly as I can tell it would only be needed if there is Via > hiding being done. Correct. The branch param is not one of the encrypted components when Via hiding is performed. This means that if we make the branch param globally unique there is no longer a requirement on Proxies to try and decrypt all Via headers marked as hidden to perform loop detection. A proxy can just just recognise it's own globally unique branch param within any hidden Vias. 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 mailman-owner@lists.bell-labs.com Fri Sep 1 06:20: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 ESMTP id GAA07653 for ; Fri, 1 Sep 2000 06:20:14 -0400 (EDT) From: mailman-owner@lists.bell-labs.com Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E842244AEE for ; Fri, 1 Sep 2000 05:06:19 -0400 (EDT) Subject: lists.bell-labs.com mailing list memberships reminder To: sip-archive@ietf.org X-No-Archive: yes Precedence: bulk X-Mailman-Version: 1.1 Precedence: bulk List-Id: External Test Mailing List Message-Id: <20000901090619.E842244AEE@lists.bell-labs.com> Date: Fri, 1 Sep 2000 05:06:19 -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@lists.ietf.org From sip-admin@lists.bell-labs.com Fri Sep 1 06:37: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 ESMTP id GAA07792 for ; Fri, 1 Sep 2000 06:37: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 43758443BA; Fri, 1 Sep 2000 05:31:42 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id 6B98B443A3 for ; Fri, 1 Sep 2000 05:24:25 -0400 (EDT) Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id LAA21318; Fri, 1 Sep 2000 11:22:37 +0100 (BST) From: "Jo Hornsby" To: "Loita Jahnsson" , "Jonathan Rosenberg" , Subject: RE: [SIP] transaction identification Date: Fri, 1 Sep 2000 11:22:36 +0100 Message-ID: <004f01c013fe$8c9352a0$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: <39AF7DD1.2AE4EDE7@uab.ericsson.se> Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit > I appreciate the possibility to separate the BYE transactions > in "p". > > The things I don't quite understand is: > > (i) > When ub1@cb1 & ub2@cb2 hangs up, I thought they didn't > necessarily have to insert tags the From field. When I > read in the spec I only find this about the From tag: > "It MUST be present when it is possible that two instances > of a user sharing a SIP address can make call invitations > with the same call-ID". How does that apply to ub1@cb1 > and ub2@cb2 in the above scenario? This text applies to the initial INVITE [0]. To see how the tag plays a role in BYEs (and re-INVITEs, and whatever), have a look at section 11.4: For the desired call leg, the To header field is set to the remote address, and the From header field is set to the local address (both including any tags). > (ii) > Imagine proxy "p" implementing a service or doing something > like controlling a firewall for example. To be able to > do this it needs to be call stateful in some respect. > > Right now I could only visualize two ways of achieving > call statefullness in "p"; (a) either you add the "call > state information" as parameters as you proxy the messages > and pray that the client in the other end doesn't remove > that data when sending responses, generating new requests > or whatever. Or (b) actually keeping "call state" for > each call within the proxy. (a) is not going to work without some sort of extension (okay, ignoring putting bizarre parameters into Record-Route Request-URIs). > If you prefer (b), you need some way of identifying > the different calls (not only transactions). As I would > have imagined this would be call leg + possibly some > other information. > > Now I am trying to apply the "call leg has nothing to do > with proxies" statement for a "(b)" proxy implementation. > And that's where I get lost. I think the point is that call leg is defined by the endpoints involved, and thus irrelevant to the proxy -- it just does its normal transaction processing. However, the proxy is free to maintain state on call legs as it chooses -- in general, this is probably going to be invisible to any of the endpoints involved in the call. HTH, - Jo. [0] I noticed that From tags were one of the "Open Issues". Has there been any resolution to this? _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Sep 1 08:13: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 ESMTP id IAA09846 for ; Fri, 1 Sep 2000 08:13: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 457324434C; Fri, 1 Sep 2000 07:13:12 -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 9DE6444336 for ; Fri, 1 Sep 2000 07:13:08 -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 e81CC8p03428; Fri, 1 Sep 2000 14:12:08 +0200 (MEST) Received: from uabx04c148.uab.ericsson.se.uab.ericsson.se (uabx04c148 [134.138.228.163]) by ms.uab.ericsson.se (8.10.0/8.10.0/uab-2.26) with ESMTP id e81CC8L05502; Fri, 1 Sep 2000 14:12:08 +0200 (MET DST) Received: from uab.ericsson.se by uabx04c148.uab.ericsson.se.uab.ericsson.se (8.8.7/client-1.3uab1) id OAA01668; Fri, 1 Sep 2000 14:12:04 +0200 (MET DST) Message-ID: <39AF9D13.16739D7B@uab.ericsson.se> Date: Fri, 01 Sep 2000 14:12:03 +0200 From: Loita Jahnsson Organization: Ericsson Utvecklings AB X-Mailer: Mozilla 4.7C-CCK-MCD [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: sv,en-US MIME-Version: 1.0 To: Jo Hornsby , sip@lists.bell-labs.com, jdrosen@dynamicsoft.com, ndeason@ubiquity.net Subject: Re: [SIP] transaction identification References: <004f01c013fe$8c9352a0$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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Hi, > This text applies to the initial INVITE [0]. To see how > the tag plays a role in BYEs (and re-INVITEs, and whatever), > have a look at section 11.4: > For the desired call leg, the To header field is > set to the remote address, and the From header > field is set to the local address (both including > any tags). Thanks, that was the part of information that I needed to be pointed out. Now I understand both Neils and Jonathans previous answers: Jonathan: > ub1@cb1 will insert a tag into the To field into the 200 OK. So will > ub2@cb2, but these tags are both different. When ub1 hangs up, it places > its tag in its From field, and ub2@cb2 places its tag in the BYE. Thus, > the two BYEs differ in the From field, and thus will appear to u to be > different transactions. Neil: > Also in this example a tag in the From > differentiates the call legs if the proxy needs to be > call stateful for some specialised service. Given that, I think the following solution would work beautifully: Jonathan: > So, let me try to summarize: > > 1. a request is matched to a transaction ID through a hash of (request > URI, To, From, Call-ID, CSeq, topmost Via), where the hash is done over > "canonical" representations of these (ie, you don't want insertion of a > white space to screw it up). The ACK and CANCEL use the same thing in a > PROXY (note this doesn't work for ACK in a UAS since the ACK can take a > different path entirely. One of the nasty things I really don't like). > So, for a UAS, you have two keys - one with the topmost Via, one > without. If there is no match on the key with the via for the ACK, you > try the one without. > > 2. the branch ID, in addition to the two components mentioned in the bis > draft, also now contains a third piece, which is sufficient extra info > to make the branch ID unique across all transactions as defined in 1. > Note that this uniqueness piece must be separable -i.e., you can't > include it in the hash of the incoming R-URI, TO, From,CSeq, Call-ID > defined in bis. Otherwise, you can't detect spirals. This could be the > transaction ID + server instance. Thanks again, Best Regards, Loita Jahnsson SIP SW Designer _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Sep 1 12:03: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 ESMTP id MAA15266 for ; Fri, 1 Sep 2000 12:03: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 E48EF44357; Fri, 1 Sep 2000 11:03:18 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from proxy2.ba.best.com (proxy2.ba.best.com [206.184.139.14]) by lists.bell-labs.com (Postfix) with ESMTP id 45AD844336 for ; Fri, 1 Sep 2000 11:03:12 -0400 (EDT) Received: from amd.echeque.com (jamesd.vip.best.com [204.156.153.125]) by proxy2.ba.best.com (8.9.3/8.9.2/best.out) with ESMTP id JAA22072; Fri, 1 Sep 2000 09:00:42 -0700 (PDT) Message-Id: <4.3.1.2.20000901082013.030f1ce0@shell11.ba.best.com> X-Sender: jamesd@shell11.ba.best.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Fri, 01 Sep 2000 08:25:00 -0700 To: Michael Thomas , Henning Schulzrinne , Jonathan Rosenberg , David Harris , "Sip-Implementors (E-mail)" , sip From: "James A. Donald" Subject: Re: [SIP] Re: SIP gateways and authentication 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com -- At 09:59 AM 8/31/2000 -0700, Michael Thomas wrote: > It looks like your argument is not with the SIP WG but with the CAT > WG. To be useful, encryption must be integral with a communications protocol. To be secure, a communications protocol must be integral with encryption. > I'm sure a lot of folks there would be willing to entertain (or not) > this argument. In particular, the assertion that that Kerberos is > inherently subject to dictionary attacks looks more like an > indictment against symmetric key cryptography in general, rather > than Kerberos in particular. There is nothing special about symmetric key cryptography that makes it particularly subject to dictionary attacks. In all public key solutions, the public keys are used to set up a symmetric key that is not subject to dictionary attacks. It is probably possible to set up a system with properties similar to those that I outlined using nothing but symmetric key cryptography, though it would be more complex, hence harder to understand and harder to get right. Existing symmetric key solutions (Kerberos) are vulnerable to dictionary attack Existing public key solutions are hard to use and unpopular. These are properties of the particular implementations, and the particular tasks for which they are used, not a property of the underlying technology. The technology is merely a tool. It is what one makes with the tool that has particular properties, like being hard to use, or being vulnerable to particular attacks --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG xirSvfQvSQVFCs8dj58C5bSdC21fv2EaGyNzr8wn 4x8kyGomth1BRtbAUDUQHnw3q8MGtTv7Mb395WWQ4 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Sep 1 12:05: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 ESMTP id MAA15298 for ; Fri, 1 Sep 2000 12:05: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 CCDBE4435B; Fri, 1 Sep 2000 11:03:33 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from proxy2.ba.best.com (proxy2.ba.best.com [206.184.139.14]) by lists.bell-labs.com (Postfix) with ESMTP id B10BE4435A for ; Fri, 1 Sep 2000 11:03:29 -0400 (EDT) Received: from amd.echeque.com (jamesd.vip.best.com [204.156.153.125]) by proxy2.ba.best.com (8.9.3/8.9.2/best.out) with ESMTP id JAA24598; Fri, 1 Sep 2000 09:01:36 -0700 (PDT) Message-Id: <4.3.1.2.20000901083307.030e31e8@shell11.ba.best.com> X-Sender: jamesd@shell11.ba.best.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Fri, 01 Sep 2000 08:42:11 -0700 To: Paul Krumviede , Michael Thomas , "James A. Donald" From: "James A. Donald" Subject: Re: [SIP] Re: SIP gateways and authentication Cc: sip In-Reply-To: <1352928840.967720570@sjo-dhcp0317.mcit.com> References: <14766.36613.901750.929369@thomasm-u1.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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com -- At 11:16 AM 8/31/2000 -0700, Paul Krumviede wrote: > there is a complexity result that use of "public key techniques are > unavoidable for password protocols that resist off-line guessing > attacks." i doubt we can require that in all environments... No there is not. If you put a turbine into a car, this does not require you to build a car with wings that flies. We need a solution that for the user works like kerberos, does not require anything more of the user or administrator than kerberos requires, but is secure, unlike kerberos. The underlying technologies used to achieve this are irrelevant. As it happens, people who design kerberos like solutions these days tend to use public key techniques, just as people who build planes these days tend to use modern tools. There is nothing about the underlying technologies that leads to the properties of the existing protocols. The technologies are just tools. You use bolts in an plane, and bolts in a bridge. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG 3nBV+z9qm9n1z0nZqN4eSN1cTmAoF+Ne4z9VMplf 478WQjH1WAD4d1A3hu7wyNA8KwewETOKL35vaVLg3 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Sep 1 12:29: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 ESMTP id MAA15683 for ; Fri, 1 Sep 2000 12:29: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 5F38E44353; Fri, 1 Sep 2000 11:29:16 -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 DF7DE44338 for ; Fri, 1 Sep 2000 11:29:12 -0400 (EDT) Received: from driftwood.cisco.com (driftwood.cisco.com [171.71.157.40]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id JAA10074; Fri, 1 Sep 2000 09:29:31 -0700 (PDT) Received: from cisco.com ([171.71.159.231]) by driftwood.cisco.com (Mirapoint) with ESMTP id ACE08811; Fri, 1 Sep 2000 11:26:00 -0500 (CDT) Message-ID: <39AFD999.AAE9F83@cisco.com> Date: Fri, 01 Sep 2000 11:30:17 -0500 From: Hong Chen Organization: Cisco Systems X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: sip@lists.bell-labs.com Subject: Re: [SIP] SIP feature services References: <39AEACDE.F5686B52@cisco.com> <39AF5E23.A98F4EC9@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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > Hong Chen wrote: > > > > Dear All: > > > > I would like to initial discussion on what the best > > systematic/consistent way to invoke network feature services by SIP > > signaling without > > losing SIP advantages. > > You mean what protocol would one use to talk to an application server > that provides SIP features? Thats easy - SIP. I might ask some dump questions. My question is how to use SIP to request AS feature services systematically and consistently, meaning: - Is there a systematic / consistent sip mechanism being used to invoke AS for different feature services? - Is this mechanism well accepted for the interoperability purpose? - Do we need to keep originating sip session same as the feature service sip session? - Do we need to create feature call flows based on this well accepted mechanism? - Can we keep the consistency between the different feature call flows? For example, if we set service "feature-i" in Request-URI of INVITE request to invoke an AS, - Where should "feature-i" be put in Request-URI? "feature-i"@example or user@example;"service"="feature-i"? - How do users know the name of "feature-i" and "service"? - Is there such pname "service" defined for such purpose? - Are there pvalue like "feature-i" defined and well accepted? By the way, can any one help to give a whole picture about XML and SIP for feature services? Hong C > > > -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 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Sep 1 12:33: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 ESMTP id MAA15819 for ; Fri, 1 Sep 2000 12:33:22 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C3D1644355; Fri, 1 Sep 2000 11:32:54 -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 B8B7D44336 for ; Fri, 1 Sep 2000 11:32:50 -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 JAA12470; Fri, 1 Sep 2000 09:32:31 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA26518; Fri, 1 Sep 2000 09:32:10 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14767.55818.365340.898563@thomasm-u1.cisco.com> Date: Fri, 1 Sep 2000 09:32:10 -0700 (PDT) To: "James A. Donald" Cc: Michael Thomas , Henning Schulzrinne , Jonathan Rosenberg , David Harris , "Sip-Implementors (E-mail)" , sip Subject: Re: [SIP] Re: SIP gateways and authentication In-Reply-To: <4.3.1.2.20000901082013.030f1ce0@shell11.ba.best.com> References: <4.3.1.2.20000901082013.030f1ce0@shell11.ba.best.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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit James A. Donald writes: > In all public key solutions, > the public keys are used to set up a symmetric key that is not subject to > dictionary attacks. False. A public key solution that chose bad symmetric keys would be subject to dictionary attacks and much more. > It is probably possible to set up a system with properties similar to those > that I outlined using nothing but symmetric key cryptography, though it > would be more complex, hence harder to > understand and harder to get right. FSVO "more". > Existing symmetric key solutions (Kerberos) are vulnerable to > dictionary attack This is a ludicrous strawman. People choose dictionary attackable symmetric keys, not Kerberos. Talk about babies and bathwater... Mike _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Sep 1 12:37: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 ESMTP id MAA15885 for ; Fri, 1 Sep 2000 12:37: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 45E0944367; Fri, 1 Sep 2000 11:36:48 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from proxy2.ba.best.com (proxy2.ba.best.com [206.184.139.14]) by lists.bell-labs.com (Postfix) with ESMTP id 564CA44358 for ; Fri, 1 Sep 2000 11:36:44 -0400 (EDT) Received: from amd.echeque.com (jamesd.vip.best.com [204.156.153.125]) by proxy2.ba.best.com (8.9.3/8.9.2/best.out) with ESMTP id JAA04422; Fri, 1 Sep 2000 09:30:49 -0700 (PDT) Message-Id: <4.3.1.2.20000901084454.03471720@shell11.ba.best.com> X-Sender: jamesd@shell11.ba.best.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Fri, 01 Sep 2000 09:08:04 -0700 To: Jonathan Trostle , "James A. Donald" , Michael Thomas , Henning Schulzrinne From: "James A. Donald" Subject: Re: [SIP] Re: SIP gateways and authentication Cc: Michael Thomas , Jonathan Rosenberg , David Harris , "Sip-Implementors (E-mail)" , sip In-Reply-To: <4.1.20000831165609.015802e0@nsm-mail2> References: <4.3.1.2.20000830092306.00bbeeb0@shell11.ba.best.com> <14765.12335.868273.287866@thomasm-u1.cisco.com> <39A6D968.647FBFDB@cs.columbia.edu> <89866A7EC9C0D1119C950000F8BCC282016352E9@zrtpd00n.us.nortel.com> <39A6035E.4DDC74C0@dynamicsoft.com> <14758.38134.851139.496078@thomasm-u1.cisco.com> <39A6B1C4.E424802F@cs.columbia.edu> <14758.48066.388917.988364@thomasm-u1.cisco.com> <39A6C0C3.7BEC4838@cs.columbia.edu> <14758.49815.427708.431582@thomasm-u1.cisco.com> <39A6C49E.9844FF65@cs.columbia.edu> <14758.51787.331133.132625@thomasm-u1.cisco.com> <39A6D968.647FBFDB@cs.columbia.edu> 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com -- At 08:53 PM 8/30/00 -0700, James A. Donald wrote: > >While you are correct that we should use Kerberos like security > >servers, Kerberos itself is broken. It has been broken for some time. > > > >The problem is described in http://theory.stanford.edu/~tjw/krbpass.html, At 05:17 PM 8/31/2000 -0700, Jonathan Trostle wrote: > The first line of defense against dictionary attacks in Kerberos is > a reasonable password policy. The paper you cite does nothing to > show that a reasonable password policy is not adequate to prevent > these attacks - the paper demonstates attacks against a Kerberos 4 > realm with a very weak password policy. In particular, some users > had passwords with 1 character, some had passwords with 2 > characters, etc. That was not my reading of the paper. The password checker discouraged, but did not flatly prohibit weak passwords. The vast majority of the passwords that they cracked were passwords that the password checker had accepted. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG A0bbR6u7j50dqDEO+2Fc+OObr3x+2gH94Mde3CJQ 4dxmy4K5kGimwMrQ0pNJ1zC9crVXCSszvx0j4Lp4z _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Sep 1 13:02: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 ESMTP id NAA16299 for ; Fri, 1 Sep 2000 13:02: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 20C7744353; Fri, 1 Sep 2000 12:01:59 -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 B431F44336 for ; Fri, 1 Sep 2000 10:12:33 -0400 (EDT) Received: from zrchb200.us.nortel.com (actually zrchb200) by smtprch2.nortel.com; Fri, 1 Sep 2000 10:06:44 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Fri, 1 Sep 2000 10:10:24 -0500 Message-ID: From: "Brian Stucker" To: "'Henry Sinnreich'" , "James A. Donald" , Michael Thomas , Henning Schulzrinne Cc: Michael Thomas , Jonathan Rosenberg , "David Harris" , "Sip-Implementors (E-mail)" , sip Subject: RE: [SIP] Re: SIP gateways and authentication Date: Fri, 1 Sep 2000 10:10:22 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C01426.BFBAB150" X-Orig: Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com 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_01C01426.BFBAB150 Content-Type: text/plain; charset="iso-8859-1" Cheap or not, do you really want to start chipping away at the image that people have that a phone call is ubiquitous, reliable, and (relatively) secure transaction in their minds? It took decades of marketing and technical performance to get to that point, why not try to maintain that in the future? How long did it take the phone companies to finally put an end to blue boxing, and how much money did they lose? Even if the calls are incredibly cheap, it could be easy for people to make incredibly large numbers of them if for nothing else, just for the fun for watching the network crater. Strong security and authentication is important in a system where you have in-band signalling, and everything is visible to (and reproducible by) the end user if not for other users protection, but for the protection of the network itself. If the fault of the original phone system was that is was a closed system, as is often stated by those working on IP telephony, the fault of the next generation phone system, cheap or not, is going to be security and reliablility if we're not careful. Brian -----Original Message----- From: Henry Sinnreich [mailto:Henry.Sinnreich@WCOM.com] Sent: Thursday, August 31, 2000 7:37 PM To: James A. Donald; Michael Thomas; Henning Schulzrinne Cc: Michael Thomas; Jonathan Rosenberg; Harris, David [NCRTP:3M12:EXCH]; Sip-Implementors (E-mail); sip Subject: RE: [SIP] Re: SIP gateways and authentication Am not sure such complexity is jutified for phone calls having the cost close to e-mail. Henry >-----Original Message----- >From: sip-admin@lists.bell-labs.com >[mailto:sip-admin@lists.bell-labs.com]On Behalf Of >James A. Donald >Sent: Wednesday, August 30, 2000 10:53 PM >To: Michael Thomas; Henning Schulzrinne >Cc: Michael Thomas; Jonathan Rosenberg; David Harris; >Sip-Implementors >(E-mail); sip >Subject: Re: [SIP] Re: SIP gateways and authentication > > > -- >At 09:02 AM 8/30/2000 -0700, Michael Thomas wrote: > > A cross realm Kerberos based solution would be more >than adequate to > > give you a high level of confidence that a piece of >information came > > from the realm it claims to have come from. > >While you are correct that we should use Kerberos like >security >servers, Kerberos itself is broken. It has been >broken for some time. > >The problem is described in >http://theory.stanford.edu/~tjw/krbpass.html, >and with the passage of time the problem becomes ever >worse, due to the >increased power of offline dictionary attack hardware >and software. > >A modern security system, (which kerberos is not) must >only permit online >attacks on the password. Kerberos permits offline >attacks. In a modern >system the attacker must only be able to test his >guesses by using the >guessed password to attempt to establish a secure >connection to the >security server. After some large number of >consecutive failures, the >security server will temporarily disable the account, >and send to the user >an insecure notification containing a log of all >information about the >failed attempts. After each successful logon, the >system sends the user >information about all previous failed attempts through >the secure connection. > >The proposal to use PGP keys or verisign keys uses >modern security >techniques to solve the wrong problem. > >The proposal to use kerberos techniques addresses the >right problem in the >right way, but the particular details of the solution >are obsolete. > >I propose the following EKE like solution, similar to >that described in my >web page http://catalog.com/jamesd/kong/secure_video.htm > >The user establishes a secure connection with the >secure personal presence >server. > >The personal presence client logs in to the personal >presence server using >the name and password. The password is never revealed >to the server. An >outside attacker would have to try his guessed >password by attempting to >log on. If he tried lots of logons, this would become >noticeable. > >The server knows, not the password p , but h(p)*G >where G is an elliptic >point that the server makes known to anyone. > >When the user created his account, his client software >informed the server >of h(p)*G through https. The software ensures that it >gave this account >creation information only to the real server, thanks >to the usual https >mechanism, which guarantees the server's true name. >The server does not >need to verify the users true name. > >Lower case letters stand for very large integers, >upper case letters stand >for elliptic points. h(x) means "one way hash of x " > >The object of the logon protocol is to ensure that the >client program is >communicating with a server that knows h(p)*G , and >the server knows it is >communicating with a client who knows h(p) In this >the protocol differs >from SPEKE, where both the client and the security >server both know >p. The implementors have to keep in mind the usual >EKE concerns described >in http://world.std.com/~dpj/speke97.html. > >When the user logs on he sends the server his logon >name in the clear, The >server generates a true random number b , and sends >the user b*G . > >The client similarly generates a true random number c >and sends the server c*G. > >An attacker can discover c*G, b*G, and G, but cannot >calculate c or b from >this information. > >The client then generates the secret elliptic point >(b*G)*[c+h(p)] > >The server similarly generates the secret elliptic >point b*[(c*G)+(h(p)*G)] >, which will be equal to the point generated by the >client. This elliptic >point is then used as the symmetric secret key for >secure communications >between client and the security server until the user logs off. > >In order to succeed with the protocol, in order for >the client to construct >a secret elliptic point equal to that of the server, >it must know h(p) >corresponding to the server's h(p)*G >Of course, ultimately our objective is not secure >communications with the >security server, but secure communications between any > two users, and >secure communications between a user and all the >various entities that are >involved in setting up his communication. > >The simplest way of solving this is the classic DH >method, now patent free, >where each entity generates one true random transient >public/private key >pair, which lasts the duration of a login session. >Each security server >authenticates the public keys of its users and >entities, and only the user >or entity knows the private key. > >This could potentially lead to a very large number of >public key >operations, which are quite slow Because the keys >change infrequently, >this problem can be solved by each entity caching the >results of previous >public key operations. The cache is discarded when >the entity logs out.. > >When Bob sends an authenticated and secure message to >Ann, saying "Hi Ann, >how are things?" it would use intolerable bandwidth if >that message, and >each of the various acks and nacks by various entities >required to locate >Ann and set up and send the message, required a >verisign style public key >signature, or pgp style public key signatue. > >Instead, for any two entities, there will be a unique >DH shared secret, >constructed from each one's DH key. Each obtains the >other's public DH key >from the others security server. That unique shared >secret will not change >as long as both entities remain logged on to their >security server. Since >each ack and nack will be sent encrypted using that >unique and unchanging >shared secret, no public key operations will be >needed to prove who is >sending the ack, since only the apparent author or the >apparent recipient >could decrypt it or encrypt it. We have only one >public key operation per >logon time per pair of entities that need to >communicate securely, which >will have an insignificant bandwidth and computational >cost, not several >public key operations per ack and nack, as would be >required if we employed >a signature system similar to that employed by verisign or PGP. > > > --digsig > James A. Donald > 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG > i4N8MYu3lFyxRz7rj6IX3CMlEt8P5QsQNrYF+dGO > 478RouxqobjnPMPR6Cg+Lf/c/t2dukyvpj+QkrgkK > > > > >_______________________________________________ >SIP mailing list >SIP@lists.bell-labs.com >http://lists.bell-labs.com/mailman/listinfo/sip ------_=_NextPart_001_01C01426.BFBAB150 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [SIP] Re: SIP gateways and authentication

Cheap or not, do you really want to start chipping = away at the image that people have that a phone call is ubiquitous, = reliable, and (relatively) secure transaction in their minds? It took = decades of marketing and technical performance to get to that point, = why not try to maintain that in the future?

How long did it take the phone companies to finally = put an end to blue boxing, and how much money did they lose? Even if = the calls are incredibly cheap, it could be easy for people to make = incredibly large numbers of them if for nothing else, just for the fun = for watching the network crater. Strong security and authentication is = important in a system where you have in-band signalling, and everything = is visible to (and reproducible by) the end user if not for other users = protection, but for the protection of the network itself.

If the fault of the original phone system was that is = was a closed system, as is often stated by those working on IP = telephony, the fault of the next generation phone system, cheap or not, = is going to be security and reliablility if we're not = careful.

Brian

-----Original Message-----
From: Henry Sinnreich [mailto:Henry.Sinnreich@WCOM.com= ]
Sent: Thursday, August 31, 2000 7:37 PM
To: James A. Donald; Michael Thomas; Henning = Schulzrinne
Cc: Michael Thomas; Jonathan Rosenberg; Harris, = David [NCRTP:3M12:EXCH];
Sip-Implementors (E-mail); sip
Subject: RE: [SIP] Re: SIP gateways and = authentication


Am not sure such complexity is jutified for phone = calls having
the cost close to e-mail.

Henry

>-----Original Message-----
>From: sip-admin@lists.bell-labs.com
>[mailto:sip-admin@lists.bel= l-labs.com]On Behalf Of
>James A. Donald
>Sent: Wednesday, August 30, 2000 10:53 PM
>To: Michael Thomas; Henning Schulzrinne
>Cc: Michael Thomas; Jonathan Rosenberg; David = Harris;
>Sip-Implementors
>(E-mail); sip
>Subject: Re: [SIP] Re: SIP gateways and = authentication
>
>
>     --
>At 09:02 AM 8/30/2000 -0700, Michael Thomas = wrote:
> > A cross realm Kerberos based solution = would be more
>than adequate to
> > give you a high level of confidence that a = piece of
>information came
> > from the realm it claims to have come = from.
>
>While you are correct that we should use = Kerberos like
>security
>servers,  Kerberos itself is broken. It has = been
>broken for some time.
>
>The problem is described in
>http://theory.stanford.edu/~tjw/krbpass.html,
>and with the passage of time the problem becomes = ever
>worse, due to the
>increased power of offline dictionary attack = hardware
>and software.
>
>A modern security system, (which kerberos is = not) must
>only permit online
>attacks on the password.  Kerberos permits = offline
>attacks. In a modern
>system the attacker must only be able to test = his
>guesses by using the
>guessed password to attempt to establish a = secure
>connection to the
>security server.  After some large number = of
>consecutive failures, the
>security server will temporarily disable the = account,
>and send to the user
>an insecure notification containing a log of = all
>information about the
>failed attempts.  After each successful = logon, the
>system sends the user
>information about all previous failed attempts = through
>the secure connection.
>
>The proposal to use PGP keys or verisign keys = uses
>modern security
>techniques to solve the wrong problem.
>
>The proposal to use kerberos techniques = addresses the
>right problem in the
>right way, but the particular details of the = solution
>are obsolete.
>
>I propose the following EKE like solution, = similar to
>that described in my
>web page http://catalog.com/jamesd/kong/secure_video.htm
>
>The user establishes a secure connection with = the
>secure personal presence
>server.
>
>The personal presence client logs in to the = personal
>presence server using
>the name and password.  The password is = never revealed
>to the server.   An
>outside attacker would have to try his = guessed
>password by attempting to
>log on.  If he tried lots of logons, this = would become
>noticeable.
>
>The server knows, not the password p , but = h(p)*G
>where G is an elliptic
>point that the server makes known to = anyone.
>
>When the user created his account, his client = software
>informed the server
>of h(p)*G through https.  The software = ensures that it
>gave this account
>creation information only to the real server, = thanks
>to the usual https
>mechanism, which guarantees the server's true = name.
>The server does not
>need to verify the users true name.
>
>Lower case letters stand for very large = integers,
>upper case letters stand
>for elliptic points. h(x) means "one way = hash of x "
>
>The object of the logon protocol is to ensure = that the
>client program is
>communicating with a server that knows h(p)*G , = and
>the server knows it is
>communicating with a client who knows = h(p)    In this
>the protocol differs
>from SPEKE, where both the client and the = security
>server both know
>p.   The implementors have to keep in = mind the usual
>EKE concerns described
>in http://world.std.com/~dpj/speke97.html.
>
>When the user logs on he sends the server his = logon
>name in the clear, The
>server generates a true random number b , and = sends
>the user b*G .
>
>The client similarly generates a true random = number c
>and sends the server c*G.
>
>An attacker can discover c*G, b*G, and G, but = cannot
>calculate c or b from
>this information.
>
>The client then generates the secret elliptic = point
>(b*G)*[c+h(p)]
>
>The server similarly generates the secret = elliptic
>point b*[(c*G)+(h(p)*G)]
>, which will be equal to the point generated by = the
>client.  This elliptic
>point is then used as the symmetric secret key = for
>secure communications
>between client and the security server until the = user logs off.
>
>In order to succeed with the protocol, in order = for
>the client to construct
>a secret elliptic point equal to that of the = server,
>it must know h(p)
>corresponding to the server's h(p)*G
>Of course, ultimately our objective is not = secure
>communications with the
>security server, but secure communications = between any
> two users, and
>secure communications between a user  and = all the
>various entities that are
>involved in setting up his communication.
>
>The simplest way of solving this is the classic = DH
>method, now patent free,
>where each entity generates one true random = transient
>public/private key
>pair, which lasts the duration of a login = session.
>Each security server
>authenticates the public keys of its users = and
>entities, and only the user
>or entity knows the private key.
>
>This could potentially lead to a very large = number of
>public key
>operations, which are quite slow  Because = the keys
>change infrequently,
>this problem can be solved by each entity = caching the
>results of previous
>public key operations.   The cache is = discarded when
>the entity logs out..
>
>When Bob sends an authenticated and secure = message to
>Ann, saying "Hi Ann,
>how are things?" it would use intolerable = bandwidth if
>that message, and
>each of the various acks and nacks by various = entities
>required to locate
>Ann and set up and send the message, required = a
>verisign style public key
>signature, or pgp style public key = signatue.
>
>Instead, for any two entities, there will be a = unique
>DH shared secret,
>constructed from each one's DH key.  Each = obtains the
>other's public DH key
>from the others security server.  That = unique shared
>secret will not change
>as long as both entities remain logged on to = their
>security server.   Since
>each ack and nack will be sent encrypted using = that
>unique and unchanging
>shared secret, no  public key operations = will be
>needed to prove who is
>sending the ack, since only the apparent author = or the
>apparent recipient
>could decrypt it or encrypt it.  We have = only one
>public key operation per
>logon time per pair of entities that need = to
>communicate securely, which
>will have an insignificant bandwidth and = computational
>cost, not several
>public key operations per ack and nack, as would = be
>required if we employed
>a signature system similar to that employed by = verisign or PGP.
>
>
>     --digsig
>          = James A. Donald
>      = 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
>      = i4N8MYu3lFyxRz7rj6IX3CMlEt8P5QsQNrYF+dGO
>      = 478RouxqobjnPMPR6Cg+Lf/c/t2dukyvpj+QkrgkK
>
>
>
>
>_______________________________________________
>SIP mailing list
>SIP@lists.bell-labs.com
>http://lists.bell-labs.com/mailman/listinfo/sip

------_=_NextPart_001_01C01426.BFBAB150-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Sep 1 13:03: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 ESMTP id NAA16317 for ; Fri, 1 Sep 2000 13:03: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 286364435F; Fri, 1 Sep 2000 12:02:29 -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 9082344339 for ; Fri, 1 Sep 2000 11:12:03 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Fri Sep 1 12:11:48 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 7931D44347; Fri, 1 Sep 2000 11:58:38 -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 1B09544341 for ; Fri, 1 Sep 2000 11:58:38 -0400 (EDT) Received: by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id KAA11248; Fri, 1 Sep 2000 10:58:34 -0500 Received: from lucent.com by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id KAA11244; Fri, 1 Sep 2000 10:58:34 -0500 Message-ID: <39AFD22B.6E65E404@lucent.com> Date: Fri, 01 Sep 2000 10:58:35 -0500 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] Forking proxy and OPTIONS Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit All: What should the behavior of a forking proxy be when the very first request it gets from it's upstream client is an OPTIONS request. Let's assume that the callee has been registered with multiple Contacts at the proxy. Should the proxy treat the OPTIONS as it does INVITEs and spawn several downstream requests? Thanks, - vijay -- Vijay K. Gurbani vkg@lucent.com vkg@research.bell-labs.com vkg@acm.org Internet Software Group/Intelligent Network and Instant Messaging 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 Sep 1 13:05: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 ESMTP id NAA16353 for ; Fri, 1 Sep 2000 13:05: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 816F644352; Fri, 1 Sep 2000 12:02:54 -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 C224744338 for ; Fri, 1 Sep 2000 11:28:04 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Fri Sep 1 12:27:42 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 2DA8D44347; Fri, 1 Sep 2000 12:14:33 -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 04FEA44341 for ; Fri, 1 Sep 2000 12:14:32 -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 MAA07123; Fri, 1 Sep 2000 12:14:32 -0400 (EDT) Message-ID: <39AFD5E8.CCF5F434@cs.columbia.edu> Date: Fri, 01 Sep 2000 12:14:32 -0400 From: Henning Schulzrinne X-Mailer: Mozilla 4.05 [en] (WinNT; U) MIME-Version: 1.0 To: Brian Stucker Cc: sip Subject: Re: [SIP] Re: SIP gateways and authentication 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Trimming cc list since everybody is presumably on the SIP list. Note that authentication has at least three very different roles: - authenticate SIP caller to callee (or caller-id-providing gateway to callee) - this has nothing to do with whether charging is involved or not. This was the topic of discussion. - authenticate SIP caller to gateway (SIP authentication) - authenticate resource reservation requests (where resources may include, particularly for wireless, basic IP connectivity) The third is independent of SIP, but may benefit from some SIP-related information. See the OSP-related drafts. In general, this is more of a AAA topic than a SIP topic and probably belongs there. Most of the "charging for phone call" debates belong into this third category. As has been said a few times on this list already: This group is *not* chartered to develop new encryption or authentication algorithms or protocols. Application of existing algorithms, if described in sufficient detail, are obviously appropriate (although the danger of having twenty different algorithms and protocols is great). _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Sep 1 13:07: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 ESMTP id NAA16409 for ; Fri, 1 Sep 2000 13:07: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 89E1E4438B; Fri, 1 Sep 2000 12:05:09 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by lists.bell-labs.com (Postfix) with ESMTP id BED4D4437A for ; Fri, 1 Sep 2000 12:05:03 -0400 (EDT) Received: by zmamail03.zma.compaq.com (Postfix, from userid 12345) id 7EE74E1B; Fri, 1 Sep 2000 13:05:02 -0400 (EDT) Received: from exchou-gh03.cca.cpqcorp.net (exchou-gh03.cca.cpqcorp.net [16.110.248.203]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 0B269E95; Fri, 1 Sep 2000 13:05:02 -0400 (EDT) Received: by exchou-gh03.cca.cpqcorp.net with Internet Mail Service (5.5.2650.21) id ; Fri, 1 Sep 2000 12:05:01 -0500 Message-ID: <202F03744BDCD31194270000F803CA9E76FF78@CXOEXC2> From: "Maddux, Michel" To: "'Jonathan Rosenberg'" , Henning Schulzrinne Cc: Paul Krumviede , Michael Thomas , David Harris , sip Subject: RE: [SIP] Re: SIP gateways and authentication Date: Fri, 1 Sep 2000 12:04:56 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Jonathan R. writes: This is what I am trying to get at. This global username/password/realm needs to be mentioned somewhere. I suppose since you need to configure a username/password anyway, you can also configure the realm for this (i.e., we need not define any special syntax for a global realm). What we do need to do is ensure that discussion of this concept appears in the specs, so that implementors support such a concept. The text above is probably right on target. Can we add it in? -Jonathan R. ======================= I agree that the nuances of provide the encryption/trusted system are interesting. To me, the most important questions are those that suggest who/what should be trusted. From that decision it should follow the best way (meaning, the best among available tools) to implement the various levels of protection for the applications. Here I suggest that we need three levels of "trust": o the user level; authentication primarily for billing and non-repudiation type services o the server level; authentication to establish a trusted relationship from server to server o the management level; an imperfect superset of the user level. The most interesting of these to me falls into the server level plane; e.g. how can I trust that the information passed to me by proxy X is valid? thanks. /m. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Sep 1 13:09: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 ESMTP id NAA16470 for ; Fri, 1 Sep 2000 13:09: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 148AF4439A; Fri, 1 Sep 2000 12:08:33 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by lists.bell-labs.com (Postfix) with ESMTP id A700544392 for ; Fri, 1 Sep 2000 12:08:29 -0400 (EDT) Received: by zmamail03.zma.compaq.com (Postfix, from userid 12345) id 79C0DD01; Fri, 1 Sep 2000 13:08:28 -0400 (EDT) Received: from exchou-gh03.cca.cpqcorp.net (exchou-gh03.cca.cpqcorp.net [16.110.248.203]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id BB722CF6; Fri, 1 Sep 2000 13:08:27 -0400 (EDT) Received: by exchou-gh03.cca.cpqcorp.net with Internet Mail Service (5.5.2650.21) id ; Fri, 1 Sep 2000 12:08:27 -0500 Message-ID: <202F03744BDCD31194270000F803CA9E76FF79@CXOEXC2> From: "Maddux, Michel" To: "'Brian Stucker'" , "'Henry Sinnreich'" , "James A. Donald" , Michael Thomas , Henning Schulzrinne Cc: Michael Thomas , Jonathan Rosenberg , David Harris , "Sip-Implementors (E-mail)" , sip Subject: RE: [SIP] Re: SIP gateways and authentication Date: Fri, 1 Sep 2000 12:07:59 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Brian writes: [...snip...] Strong security and authentication is important in a system where you have in-band signalling, and everything is visible to (and reproducible by) the end user if not for other users protection, but for the protection of the network itself. If the fault of the original phone system was that is was a closed system, as is often stated by those working on IP telephony, the fault of the next generation phone system, cheap or not, is going to be security and reliablility if we're not careful. Brian ========= Agreed; the dangers inherent with in-band signaling are readily apparent; remember the Cap'n Crunch bandit of the '60's phone phreaks. /m. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Sep 1 13:29: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 ESMTP id NAA16834 for ; Fri, 1 Sep 2000 13:29: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 B62E044369; Fri, 1 Sep 2000 12:27:21 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from renown.cnchost.com (renown.concentric.net [207.155.248.7]) by lists.bell-labs.com (Postfix) with ESMTP id 94B8E44356 for ; Fri, 1 Sep 2000 12:27:17 -0400 (EDT) Received: from MATT.ascend.com (ts005d40.lap-ca.concentric.net [64.1.211.244]) by renown.cnchost.com id NAA19860; Fri, 1 Sep 2000 13:27:05 -0400 (EDT) [ConcentricHost SMTP Relay 1.10] Message-Id: <4.3.1.2.20000901101838.00c1f150@pop3.ipverse.com> X-Sender: matt@ipverse.com@pop3.ipverse.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Fri, 01 Sep 2000 10:24:17 -0700 To: Henning Schulzrinne From: Matt Holdrege Subject: Re: [SIP] Re: SIP gateways and authentication Cc: sip@lists.bell-labs.com In-Reply-To: <39AFD5E8.CCF5F434@cs.columbia.edu> References: 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com At 12:14 PM 9/1/00 -0400, Henning Schulzrinne wrote: >Trimming cc list since everybody is presumably on the SIP list. > >Note that authentication has at least three very different roles: > >- authenticate SIP caller to callee (or caller-id-providing gateway to >callee) - this has nothing to do with whether charging is involved or >not. This was the topic of discussion. Not to try to extend useless debate, but this does involve charging. Think about the 900 service we have in the U.S. The callee bills the caller per minute. But since he doesn't have an indisputable method of billing, the callee uses the phone company to handle the authentication and billing. But in the SIP world, we can offer the callee an indisputable method of authentication that he can use for billing. I'm sure some people smarter and richer than I will think of lots of ways to make money along these lines. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Sep 1 13:56: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 ESMTP id NAA17186 for ; Fri, 1 Sep 2000 13:56:53 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C4E8D4435F; Fri, 1 Sep 2000 12:55:47 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from nsm-mail2.cisco.com (nsm-mail2.cisco.com [171.71.236.25]) by lists.bell-labs.com (Postfix) with ESMTP id 3D2A944352 for ; Fri, 1 Sep 2000 12:55:43 -0400 (EDT) Received: from jtrostle-nt2 (dhcp-171-71-229-115.cisco.com [171.71.229.115]) by nsm-mail2.cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id KAA22944; Fri, 1 Sep 2000 10:54:29 -0700 (PDT) Message-Id: <4.1.20000901104618.0158a510@nsm-mail2> X-Sender: jtrostle@nsm-mail2 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Fri, 01 Sep 2000 10:55:32 -0700 To: "James A. Donald" , "James A. Donald" , Michael Thomas , Henning Schulzrinne From: Jonathan Trostle Subject: Re: [SIP] Re: SIP gateways and authentication Cc: Michael Thomas , Jonathan Rosenberg , David Harris , "Sip-Implementors (E-mail)" , sip In-Reply-To: <4.3.1.2.20000901084454.03471720@shell11.ba.best.com> References: <4.1.20000831165609.015802e0@nsm-mail2> <4.3.1.2.20000830092306.00bbeeb0@shell11.ba.best.com> <14765.12335.868273.287866@thomasm-u1.cisco.com> <39A6D968.647FBFDB@cs.columbia.edu> <89866A7EC9C0D1119C950000F8BCC282016352E9@zrtpd00n.us.nortel.com> <39A6035E.4DDC74C0@dynamicsoft.com> <14758.38134.851139.496078@thomasm-u1.cisco.com> <39A6B1C4.E424802F@cs.columbia.edu> <14758.48066.388917.988364@thomasm-u1.cisco.com> <39A6C0C3.7BEC4838@cs.columbia.edu> <14758.49815.427708.431582@thomasm-u1.cisco.com> <39A6C49E.9844FF65@cs.columbia.edu> <14758.51787.331133.132625@thomasm-u1.cisco.com> <39A6D968.647FBFDB@cs.columbia.edu> 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com At 09:08 AM 9/1/00 -0700, James A. Donald wrote: > -- >At 08:53 PM 8/30/00 -0700, James A. Donald wrote: > > >While you are correct that we should use Kerberos like security > > >servers, Kerberos itself is broken. It has been broken for some time. > > > > > >The problem is described in http://theory.stanford.edu/~tjw/krbpass.html, > > >At 05:17 PM 8/31/2000 -0700, Jonathan Trostle wrote: > > The first line of defense against dictionary attacks in Kerberos is > > a reasonable password policy. The paper you cite does nothing to > > show that a reasonable password policy is not adequate to prevent > > these attacks - the paper demonstates attacks against a Kerberos 4 > > realm with a very weak password policy. In particular, some users > > had passwords with 1 character, some had passwords with 2 > > characters, etc. > >That was not my reading of the paper. > >The password checker discouraged, but did not flatly prohibit weak >passwords. The vast majority of the passwords that they cracked were >passwords that the password checker had accepted. A password checker is not a good way to prevent weak passwords, since it is well established that some users will pick weak passwords if given the choice. Kerberos 5 password policy will not allow a user to pick a new password that does not conform with the password policy. One of the parameters for a password policy is minimum length. Jonathan > > --digsig > James A. Donald > 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG > A0bbR6u7j50dqDEO+2Fc+OObr3x+2gH94Mde3CJQ > 4dxmy4K5kGimwMrQ0pNJ1zC9crVXCSszvx0j4Lp4z > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Sep 1 14:23: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 ESMTP id OAA17760 for ; Fri, 1 Sep 2000 14:23: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 9875E44360; Fri, 1 Sep 2000 13:22:32 -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 5EFDA44352 for ; Fri, 1 Sep 2000 13:22:29 -0400 (EDT) Received: from dynamicsoft.com (ip19.honxr1.ras.tele.dk [195.249.119.19]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id OAA09396; Fri, 1 Sep 2000 14:23:36 -0400 (EDT) Message-ID: <39AFF3AC.B71D4C5@dynamicsoft.com> Date: Fri, 01 Sep 2000 20:21:32 +0200 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: Hong Chen Cc: Jonathan Rosenberg , sip@lists.bell-labs.com Subject: Re: [SIP] SIP feature services References: <39AEACDE.F5686B52@cisco.com> <39AF5E23.A98F4EC9@dynamicsoft.com> <39AFD999.AAE9F83@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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Hong Chen wrote: > > Jonathan Rosenberg wrote: > > > Hong Chen wrote: > > > > > > Dear All: > > > > > > I would like to initial discussion on what the best > > > systematic/consistent way to invoke network feature services by SIP > > > signaling without > > > losing SIP advantages. > > > > You mean what protocol would one use to talk to an application server > > that provides SIP features? Thats easy - SIP. > > I might ask some dump questions. > > My question is how to use SIP to request AS feature services > systematically and consistently, meaning: > - Is there a systematic / consistent sip mechanism being used to > invoke AS for different feature services? Yes, plain old SIP. > - Is this mechanism well accepted for the interoperability > purpose? Getting there. > - Do we need to keep originating sip session same as the feature > service sip session? There is no separate "feature service SIP session". There is call setup and subsequent end-to-end signaling, during which proxies and other network elements are free to do whatever it takes to decide how to handle requests that come their way. No separate protocol is needed to invoke service logic. > - Do we need to create feature call flows based on this well > accepted mechanism? I don't think so. It's all standard SIP; well, give or take the odd extension, such as REFER and session timers. > - Can we keep the consistency between the different feature call > flows? > > For example, if we set service "feature-i" in Request-URI of INVITE > request to invoke an AS, > - Where should "feature-i" be put in Request-URI? > "feature-i"@example or Request URIs won't (usually) contain info that identifies services to be invoked. Maybe you subscribe to feature-i at some proxy -- it is then up to that proxy to figure out to apply feature-i to your calls. > user@example;"service"="feature-i"? > - How do users know the name of "feature-i" and "service"? > - Is there such pname "service" defined for such purpose? > - Are there pvalue like "feature-i" defined and well accepted? > > By the way, can any one help to give a whole picture about XML and > SIP for feature services? > > Hong C > > > > > > > -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 > > _______________________________________________ > 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 Sep 1 14:43:29 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17992 for ; Fri, 1 Sep 2000 14:43: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 4777644363; Fri, 1 Sep 2000 13:43:12 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cnri.reston.va.us (ns.CNRI.Reston.VA.US [132.151.1.1]) by lists.bell-labs.com (Postfix) with ESMTP id 830A344352 for ; Fri, 1 Sep 2000 12:53:48 -0400 (EDT) Received: from ietf.org (cnri-7-191.cnri.reston.va.us [132.151.7.191]) by cnri.reston.va.us (8.9.1a/8.9.1) with ESMTP id NAA01907 for ; Fri, 1 Sep 2000 13:53:44 -0400 (EDT) From: jmunoz@ietf.org Message-ID: <39AFECE2.15AB707E@ietf.org> Date: Fri, 01 Sep 2000 13:52:34 -0400 Reply-To: jmunoz@ietf.org X-Mailer: Mozilla 4.75 [en] (Win98; U) 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 Content-Transfer-Encoding: 8bit Subject: [SIP] IETF48 SIP wg Slide Inquiry Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 8bit Hello, One of the slides which you have posted on your site for the 48th IETF seems to be a broken link. The slide in question is located at: http://www.softarmor.com/sipwg/meets/IETF48/slides/pres-sijben-tiphon-sip.ppt If you wish for this slide to appear in the next edition of the proceedings, please e-mail a copy of this .ppt file or notify minutes@ietf.org or jmunoz@ietf.org when you have corrected this link. If you have any questions, just let me know. Thank you, Jacob Muñoz Proceedings Editor _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Sep 1 14:53: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 ESMTP id OAA18129 for ; Fri, 1 Sep 2000 14:53: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 9E25A4436C; Fri, 1 Sep 2000 13:52:45 -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 30A4644352 for ; Fri, 1 Sep 2000 13:52:42 -0400 (EDT) Received: from driftwood.cisco.com (driftwood.cisco.com [171.71.157.40]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id LAA15433; Fri, 1 Sep 2000 11:53:01 -0700 (PDT) Received: from cisco.com ([171.71.159.231]) by driftwood.cisco.com (Mirapoint) with ESMTP id ACE09792; Fri, 1 Sep 2000 13:49:29 -0500 (CDT) Message-ID: <39AFFB3A.7FA1C772@cisco.com> Date: Fri, 01 Sep 2000 13:53:46 -0500 From: Hong Chen Organization: Cisco Systems X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Anders Kristensen Cc: Jonathan Rosenberg , sip@lists.bell-labs.com Subject: Re: [SIP] SIP feature services References: <39AEACDE.F5686B52@cisco.com> <39AF5E23.A98F4EC9@dynamicsoft.com> <39AFD999.AAE9F83@cisco.com> <39AFF3AC.B71D4C5@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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Anders Kristensen wrote: > Hong Chen wrote: > > > > Jonathan Rosenberg wrote: > > > > > Hong Chen wrote: > > > > > > > > Dear All: > > > > > > > > I would like to initial discussion on what the best > > > > systematic/consistent way to invoke network feature services by SIP > > > > signaling without > > > > losing SIP advantages. > > > > > > You mean what protocol would one use to talk to an application server > > > that provides SIP features? Thats easy - SIP. > > > > I might ask some dumb questions. > > > > My question is how to use SIP to request AS feature services > > systematically and consistently, meaning: > > - Is there a systematic / consistent sip mechanism being used to > > invoke AS for different feature services? > > Yes, plain old SIP. > > > - Is this mechanism well accepted for the interoperability > > purpose? > > Getting there. > > > - Do we need to keep originating sip session same as the feature > > service sip session? > > There is no separate "feature service SIP session". There is call setup > and subsequent end-to-end signaling, during which proxies and other > network elements are free to do whatever it takes to decide how to > handle requests that come their way. No separate protocol is needed to > invoke service logic. > > > - Do we need to create feature call flows based on this well > > accepted mechanism? > > I don't think so. It's all standard SIP; well, give or take the odd > extension, such as REFER and session timers. > > > - Can we keep the consistency between the different feature call > > flows? > > > > For example, if we set service "feature-i" in Request-URI of INVITE > > request to invoke an AS, > > - Where should "feature-i" be put in Request-URI? > > "feature-i"@example or > > Request URIs won't (usually) contain info that identifies services to be > invoked. Maybe you subscribe to feature-i at some proxy -- it is then up > to that proxy to figure out to apply feature-i to your calls. > Yes, some services can be subscribed by users and can be trigged inside SIP proxy. But the issues are: - Do we need to define the trig points (for both originating and terminating trigs) and their conditions in Proxy? This could be a design and implementation issue. - Further more, it may not possible to define and implement trigs for some feature services. How can we handle these services by SIP? - How can we use SIP to implement user based and/or call based feature services? Thanks, Hong > > > user@example;"service"="feature-i"? > > - How do users know the name of "feature-i" and "service"? > > - Is there such pname "service" defined for such purpose? > > - Are there pvalue like "feature-i" defined and well accepted? > > > > By the way, can any one help to give a whole picture about XML and > > SIP for feature services? > > > > Hong C > > > > > > > > > > > -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 > > > > _______________________________________________ > > 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 Sep 1 15:21: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 ESMTP id PAA18613 for ; Fri, 1 Sep 2000 15:21: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 4B24444358; Fri, 1 Sep 2000 14:20:22 -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 EDB7A44342 for ; Fri, 1 Sep 2000 14:20:17 -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 PAA21153; Fri, 1 Sep 2000 15:19:49 -0400 (EDT) Message-ID: <39AE519C.99177233@cs.columbia.edu> Date: Thu, 31 Aug 2000 08:37:48 -0400 From: Henning Schulzrinne X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "James A. Donald" Cc: Michael Thomas , Jonathan Rosenberg , David Harris , sip Subject: Re: [SIP] Re: SIP gateways and authentication References: <39A6D968.647FBFDB@cs.columbia.edu> <89866A7EC9C0D1119C950000F8BCC282016352E9@zrtpd00n.us.nortel.com> <39A6035E.4DDC74C0@dynamicsoft.com> <14758.38134.851139.496078@thomasm-u1.cisco.com> <39A6B1C4.E424802F@cs.columbia.edu> <14758.48066.388917.988364@thomasm-u1.cisco.com> <39A6C0C3.7BEC4838@cs.columbia.edu> <14758.49815.427708.431582@thomasm-u1.cisco.com> <39A6C49E.9844FF65@cs.columbia.edu> <14758.51787.331133.132625@thomasm-u1.cisco.com> <39A6D968.647FBFDB@cs.columbia.edu> <4.3.1.2.20000830092306.00bbeeb0@shell11.ba.best.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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit I doubt that the SIP WG is the right group to evaluate or standardize new general-purposed security mechanism. (Actually, I'm pretty sure it's not...) If there are problems with Kerberos, they should be taken to the relevant working group or the IESG. If there are new and interesting authentication mechanisms, their authors should request a BOF to pursue possible standardization. Thus, for the time being, we're "stuck" with existing mechanisms, including S/MIME and PGP (and MIME-PGP), plus Basic/Digest, at the application layer, TLS at the transport layer and IPsec at the network layer. Kerberos has been proposed, but unless it is very clear that this adds new capabilities and does not raise any new security capabilities, I'm not convinced that adding new mechanisms is going to be particularly helpful. Since most authentication is client-to-client, CPU issues are probably not as grave a concern (no more than, say, for email). The ability to implement PK protocols (or Kerberos) in very small devices is much more likely to be an issue. "James A. Donald" wrote: > > -- > At 09:02 AM 8/30/2000 -0700, Michael Thomas wrote: > > A cross realm Kerberos based solution would be more than adequate to > > give you a high level of confidence that a piece of information came > > from the realm it claims to have come from. > > While you are correct that we should use Kerberos like security > servers, Kerberos itself is broken. It has been broken for some time. > > The problem is described in http://theory.stanford.edu/~tjw/krbpass.html, > and with the passage of time the problem becomes ever worse, due to the > increased power of offline dictionary attack hardware and software. > > A modern security system, (which kerberos is not) must only permit online > attacks on the password. Kerberos permits offline attacks. In a modern > system the attacker must only be able to test his guesses by using the > guessed password to attempt to establish a secure connection to the > security server. After some large number of consecutive failures, the > security server will temporarily disable the account, and send to the user > an insecure notification containing a log of all information about the > failed attempts. After each successful logon, the system sends the user > information about all previous failed attempts through the secure connection. > > The proposal to use PGP keys or verisign keys uses modern security > techniques to solve the wrong problem. > > The proposal to use kerberos techniques addresses the right problem in the > right way, but the particular details of the solution are obsolete. > > I propose the following EKE like solution, similar to that described in my > web page http://catalog.com/jamesd/kong/secure_video.htm > > The user establishes a secure connection with the secure personal presence > server. > > The personal presence client logs in to the personal presence server using > the name and password. The password is never revealed to the server. An > outside attacker would have to try his guessed password by attempting to > log on. If he tried lots of logons, this would become noticeable. > > The server knows, not the password p , but h(p)*G where G is an elliptic > point that the server makes known to anyone. > > When the user created his account, his client software informed the server > of h(p)*G through https. The software ensures that it gave this account > creation information only to the real server, thanks to the usual https > mechanism, which guarantees the server's true name. The server does not > need to verify the users true name. > > Lower case letters stand for very large integers, upper case letters stand > for elliptic points. h(x) means "one way hash of x " > > The object of the logon protocol is to ensure that the client program is > communicating with a server that knows h(p)*G , and the server knows it is > communicating with a client who knows h(p) In this the protocol differs > from SPEKE, where both the client and the security server both know > p. The implementors have to keep in mind the usual EKE concerns described > in http://world.std.com/~dpj/speke97.html. > > When the user logs on he sends the server his logon name in the clear, The > server generates a true random number b , and sends the user b*G . > > The client similarly generates a true random number c and sends the server c*G. > > An attacker can discover c*G, b*G, and G, but cannot calculate c or b from > this information. > > The client then generates the secret elliptic point (b*G)*[c+h(p)] > > The server similarly generates the secret elliptic point b*[(c*G)+(h(p)*G)] > , which will be equal to the point generated by the client. This elliptic > point is then used as the symmetric secret key for secure communications > between client and the security server until the user logs off. > > In order to succeed with the protocol, in order for the client to construct > a secret elliptic point equal to that of the server, it must know h(p) > corresponding to the server's h(p)*G > Of course, ultimately our objective is not secure communications with the > security server, but secure communications between any two users, and > secure communications between a user and all the various entities that are > involved in setting up his communication. > > The simplest way of solving this is the classic DH method, now patent free, > where each entity generates one true random transient public/private key > pair, which lasts the duration of a login session. Each security server > authenticates the public keys of its users and entities, and only the user > or entity knows the private key. > > This could potentially lead to a very large number of public key > operations, which are quite slow Because the keys change infrequently, > this problem can be solved by each entity caching the results of previous > public key operations. The cache is discarded when the entity logs out.. > > When Bob sends an authenticated and secure message to Ann, saying "Hi Ann, > how are things?" it would use intolerable bandwidth if that message, and > each of the various acks and nacks by various entities required to locate > Ann and set up and send the message, required a verisign style public key > signature, or pgp style public key signatue. > > Instead, for any two entities, there will be a unique DH shared secret, > constructed from each one's DH key. Each obtains the other's public DH key > from the others security server. That unique shared secret will not change > as long as both entities remain logged on to their security server. Since > each ack and nack will be sent encrypted using that unique and unchanging > shared secret, no public key operations will be needed to prove who is > sending the ack, since only the apparent author or the apparent recipient > could decrypt it or encrypt it. We have only one public key operation per > logon time per pair of entities that need to communicate securely, which > will have an insignificant bandwidth and computational cost, not several > public key operations per ack and nack, as would be required if we employed > a signature system similar to that employed by verisign or PGP. > > --digsig > James A. Donald > 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG > i4N8MYu3lFyxRz7rj6IX3CMlEt8P5QsQNrYF+dGO > 478RouxqobjnPMPR6Cg+Lf/c/t2dukyvpj+QkrgkK > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > 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 Sep 1 15:22: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 ESMTP id PAA18627 for ; Fri, 1 Sep 2000 15:22: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 7B30444376; Fri, 1 Sep 2000 14:20:31 -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 15DA24436C for ; Fri, 1 Sep 2000 14:20:25 -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 PAA21202; Fri, 1 Sep 2000 15:20:12 -0400 (EDT) Message-ID: <39AE728D.AE5AAF81@cs.columbia.edu> Date: Thu, 31 Aug 2000 10:58:21 -0400 From: Henning Schulzrinne X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Michael Thomas Cc: Jonathan Rosenberg , David Harris , sip Subject: Re: [SIP] Re: SIP gateways and authentication References: <89866A7EC9C0D1119C950000F8BCC282016352E9@zrtpd00n.us.nortel.com> <39A6035E.4DDC74C0@dynamicsoft.com> <14758.38134.851139.496078@thomasm-u1.cisco.com> <39A6B1C4.E424802F@cs.columbia.edu> <14758.48066.388917.988364@thomasm-u1.cisco.com> <39A6C0C3.7BEC4838@cs.columbia.edu> <14758.49815.427708.431582@thomasm-u1.cisco.com> <39A6C49E.9844FF65@cs.columbia.edu> <14758.51787.331133.132625@thomasm-u1.cisco.com> <39A6D968.647FBFDB@cs.columbia.edu> <14765.12335.868273.287866@thomasm-u1.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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Removing sip-implementors, since this is really not an implementation issue. > > With Kerberos based key distribution, Digest could > be almost aribitrarily large given cross realm > operation. With PKCROSS, you move the PKI > problem to the KDC which makes for an even more > scalable solution than pure PKI solutions. > Effectively, KDC's become PKI aggregators which > shield the vagueries of cross realm policy from > mere mortals. I know you like Kerberos; since a large fraction of us want to first make the existing mechanisms (which do not include Kerberos work), it might, at this stage, be more helpful to write this up as an I-D rather than have one-message discussions. That said, Basic/Digest (and the other mechanisms) have the advantage that they work using either no infrastructure (for Basic/Digest) or existing infrastructure (company or domain-name-based certs). I also suspect that any new security infrastructure will likely be developed and deployed as part of a more generic AAA mechanism rather than be SIP-specific. (Indeed, if we assume that mobile providers have to share authentication information to allow roaming, the step to making subsets of that available for caller identification is not that large.) Thus, maybe Kerberos-based discussions may have a better home in the AAA WGs or should at least be coordinated with folks there.) > > > See above. Again, at the danger of repeating myself, I'm talking about Please read the sentence above, in case you missed it. > > things we can do today and where they might be useful. (Beyond the > > do-I-trust-this-caller-id problem, public-key signed requests are also > > useful for the is-this-call-really-from-the-local-gas-company problem. > > Secret-based authentication, as in Basic and Digest, does nothing for me > > there.) > > Not true. A cross realm Kerberos based solution > would be more than adequate to give you a high At the danger of repeating myself (again): We do not have a Kerberos-based solution today, except as vague email messages. Please don't just ignore my repeated comments to this effect. > > > Are there statistics on the typical cert size? > > Probably, but I don't have any handy. I've > heard that typical certs are ~500 bytes and > that you need to ship part of the hierarchy > which may include a cert or two more. Even if > it's half, it's still problematic for multiple > realms. Statistics would be most helpful here. If you have the model used by today's web browsers, it would be presumably one certificate (with pre-configured CA certificates). Given 512 bit public keys (64 bytes), the estimate sounds close. > > Again, none of this addresses current capabilities and models. > > Is that actually true? If you posit a > pre-shared symmetric key between the two > entities, both digest and PGP provide a > means of doing symmetric key signatures. > It's true that there isn't a SIP endorsed > means of shipping Kerberos credentials, but and no global Kerberos infrastructure, which seems the harder part > that doesn't mean that symmetric key PGP or > Basic/Digest couldn't be used as-is. I've > promised to write an ID by this fall on how > to do this, so we shall see. Good idea. I look forward to reading it. > > Mike _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Sep 1 17:32: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 ESMTP id RAA20788 for ; Fri, 1 Sep 2000 17:32: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 40C2D4434D; Fri, 1 Sep 2000 16: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 84B0144336 for ; Fri, 1 Sep 2000 16:31:58 -0400 (EDT) Received: from dynamicsoft.com (1Cust214.tnt4.freehold.nj.da.uu.net [63.36.112.214]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id RAA10764; Fri, 1 Sep 2000 17:33:44 -0400 (EDT) Message-ID: <39B02015.12C92FFA@dynamicsoft.com> Date: Fri, 01 Sep 2000 17:31:01 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: vkg@lucent.com Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Forking proxy and OPTIONS References: <39AFD22B.6E65E404@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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit "Vijay K. Gurbani" wrote: > > All: > > What should the behavior of a forking proxy be when the very first > request it gets from it's upstream client is an OPTIONS request. Let's > assume that the callee has been registered with multiple Contacts at the > proxy. > > Should the proxy treat the OPTIONS as it does INVITEs and spawn several > downstream requests? It can fork in parallel or sequential, as it would for invite. The overall request processing is largely no different; the differences relate to retransmission rules and handling of multiple 200 OK (all sent upstream for INVITE, only one for anything else, including OPTIONS). -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 Fri Sep 1 18:55: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 ESMTP id SAA22345 for ; Fri, 1 Sep 2000 18:55: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 F39ED44358; Fri, 1 Sep 2000 17:55:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from exchange.efusion.com (mail.efusion.com [208.137.117.8]) by lists.bell-labs.com (Postfix) with ESMTP id 0EE8444336 for ; Fri, 1 Sep 2000 17:54:59 -0400 (EDT) Received: by EXCHANGE with Internet Mail Service (5.5.2650.21) id ; Fri, 1 Sep 2000 15:54:56 -0700 Message-ID: <72350563B44ED211B52700805F65CEE70113F3A7@EXCHANGE> From: Gideon Stocek To: sip@lists.bell-labs.com Date: Fri, 1 Sep 2000 15:54:56 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] Question regarding param-reserved/param-unreserved difference bet ween I-D and PDF Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Sorry if this has already been addressed; > The draft-ietf-sip-rfc2543bis-01.html ABNF uses which > contains > a "?" literal. This is in line with the draft-ietf-sip-rfc2543bis-01.txt > spec on the IETF site. > > Yet the BIS-00 and BIS-01 PDFs on the SIP site refer to > with > the "?" literal removed. BIS-00.pdf predates the BIS-01.txt > Gideon Stocek _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Sep 1 19:24: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 ESMTP id TAA22649 for ; Fri, 1 Sep 2000 19:24: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 E96AD44343; Fri, 1 Sep 2000 18:23:42 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from brmx1.fl.icn.siemens.com (brmx1.fl.icn.siemens.com [208.158.176.132]) by lists.bell-labs.com (Postfix) with ESMTP id 8447E44336 for ; Fri, 1 Sep 2000 18:23:39 -0400 (EDT) Received: from boca210a.boca.ssc.siemens.com (boca210a.boca.ssc.siemens.com [135.1.69.210]) by brmx1.fl.icn.siemens.com (8.9.3/8.9.3) with ESMTP id TAA04846 for ; Fri, 1 Sep 2000 19:22:18 -0400 (EDT) Received: by boca210a.boca.ssc.siemens.com with Internet Mail Service (5.5.2650.21) id ; Fri, 1 Sep 2000 19:23:37 -0400 Message-ID: <2FF13E24F61AD41193130008C791A76020EA50@boca215a.boca.ssc.siemens.com> From: "Prato, Francesco" To: "'sip@lists.bell-labs.com'" Date: Fri, 1 Sep 2000 19:20:56 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] draft-ietf-sip-session-timer-02.txt Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com I have a question about the draft-ietf-sip-session-timer-02.txt It is not clear to me the scenario where neither UA support the session timer but SPS inserts a required header. Let's take the following example: the UAC sends an INVITE request which does not contain the supported header (or when contained the tag TIMER is not present). Now, let's suppose that "the proxy wishes to insist that the call is only established if the UAS supports session timer, it MAY insert a Require header into the request, with the value "timer". (from the draft) Question-1: How does respond UAS? As the scenario described in 8.8 or with a 420 Bad Extension, or should UAS reject the call? Question-2: How does react SPS in this case? In case of 8.8 should SPS reject the call or should just ignore it? I was not able to find in the draft any clear statement about that. TNX Francesco Francesco Prato System Engineer SIEMENS ICM Boca Raton (Florida) _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Sep 1 20: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 ESMTP id UAA23113 for ; Fri, 1 Sep 2000 20:04: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 9B6B844343; Fri, 1 Sep 2000 19:03:37 -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 7F3E044336 for ; Fri, 1 Sep 2000 19:03:33 -0400 (EDT) Received: from dynamicsoft.com (ip69.honxr1.ras.tele.dk [195.249.119.69]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id UAA11070; Fri, 1 Sep 2000 20:05:13 -0400 (EDT) Message-ID: <39B043BE.E3F7D56F@dynamicsoft.com> Date: Sat, 02 Sep 2000 02:03:10 +0200 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: "Prato, Francesco" Cc: "'sip@lists.bell-labs.com'" Subject: Re: [SIP] draft-ietf-sip-session-timer-02.txt References: <2FF13E24F61AD41193130008C791A76020EA50@boca215a.boca.ssc.siemens.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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit "Prato, Francesco" wrote: > > I have a question about the draft-ietf-sip-session-timer-02.txt > > It is not clear to me the scenario where neither UA support the session > timer but SPS inserts a required header. > > Let's take the following example: > > the UAC sends an INVITE request which does not contain the supported header > (or when contained the tag TIMER is not present). > Now, let's suppose that "the proxy wishes to insist that the call is only > established if the UAS supports session timer, it MAY insert a Require > header into the request, with the value "timer". (from the draft) > Question-1: How does respond UAS? As the scenario described in 8.8 or with a > 420 Bad Extension, or should UAS reject the call? If the UAS supports the timer extension it proceeds as usual, e.g. alerting a user and accepting the INVITE as appropriate. If the UAS does not support timers it MUST reject the request with a 420 as per the SIP spec. > Question-2: How does react SPS in this case? In case of 8.8 should SPS > reject the call or should just ignore it? On receiving the response the proxy just acts as usual, i.e. forwards the final response to the caller. Since in this case it's the proxy that insists on using timers it will probably want to stay on the signaling path and monitor the call leg for re-INVITEs refreshing the timer. -- 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 Sep 1 20:22: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 ESMTP id UAA23290 for ; Fri, 1 Sep 2000 20:22: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 35E0144338; Fri, 1 Sep 2000 19:22:11 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ns1.nuance.com (ns1.nuance.com [63.199.150.199]) by lists.bell-labs.com (Postfix) with ESMTP id BC23544336 for ; Fri, 1 Sep 2000 15:44:41 -0400 (EDT) Received: from sims.nuance.com (sims.nuance.com [10.0.0.15]) by ns1.nuance.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id e81Kgvt26086 for ; Fri, 1 Sep 2000 13:42:57 -0700 (PDT) Received: from talon ([10.3.1.186]) by sims.nuance.com (Sun Internet Mail Server sims.3.5.2000.03.23.18.03.p10) with SMTP id <0G0800M026WXGE@sims.nuance.com> for sip@lists.bell-labs.com; Fri, 1 Sep 2000 13:43:46 -0700 (PDT) Date: Fri, 01 Sep 2000 16:44:56 -0400 From: Raymond Nadeau To: sip@lists.bell-labs.com Message-id: <0d9401c01455$7f04f1a0$ba01030a@nuance.com> MIME-version: 1.0 X-Mailer: Microsoft Outlook Express 5.00.2314.1300 Content-type: multipart/alternative; boundary="----=_NextPart_000_0D91_01C01433.F5E420B0" X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 X-Priority: 3 Subject: [SIP] End-to-end transport Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com This is a multi-part message in MIME format. ------=_NextPart_000_0D91_01C01433.F5E420B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Is there any way we can force a SIP transaction going through multiple = nodes to be TCP end-to-end? =20 =20 For example, A sends an Invite to B and that Invite is routed through = two proxies P and Q. My understanding is that the A-P and Q-B = connections can be over TCP for example but that the P-Q connection can = be either UDP or TCP. Or will the transport protocol parameter in the = request URI forces all the proxies along the way to use TCP? Thanks, Raymond Nadeau ------=_NextPart_000_0D91_01C01433.F5E420B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Is there any way we can force a SIP = transaction=20 going through multiple nodes to be TCP end-to-end?  =
 
For example, A sends an Invite to B and = that Invite=20 is routed through two proxies P and Q. My understanding is that the A-P = and Q-B=20 connections can be over TCP for example but that the P-Q connection can = be=20 either UDP or TCP. Or will the transport protocol parameter in the = request URI=20 forces all the proxies along the way to use TCP?
 
Thanks,
 
Raymond Nadeau
 
------=_NextPart_000_0D91_01C01433.F5E420B0-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Sep 1 20:23: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 ESMTP id UAA23301 for ; Fri, 1 Sep 2000 20:23: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 5192644363; Fri, 1 Sep 2000 19:22:25 -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 39E7C44336 for ; Fri, 1 Sep 2000 17:12:03 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Fri Sep 1 18:11:38 EDT 2000 Received: by lists.bell-labs.com (Postfix) id A436844347; Fri, 1 Sep 2000 17:58:29 -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 566FD44341 for ; Fri, 1 Sep 2000 17:58:29 -0400 (EDT) Received: by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id QAA22684; Fri, 1 Sep 2000 16:58:27 -0500 Cc: sip@lists.bell-labs.com Received: from lucent.com by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id QAA22674; Fri, 1 Sep 2000 16:58:25 -0500 Message-ID: <39B02682.B08C0D4C@lucent.com> Date: Fri, 01 Sep 2000 16:58:26 -0500 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 Subject: Re: [SIP] Forking proxy and OPTIONS References: <39AFD22B.6E65E404@lucent.com> <39B02015.12C92FFA@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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit I asked: > What should the behavior of a forking proxy be when the very first > request it gets from it's upstream client is an OPTIONS request. > Let's assume that the callee has been registered with multiple > Contacts at the proxy. > > Should the proxy treat the OPTIONS as it does INVITEs and spawn > several downstream requests? Jonathan Rosenberg replied: > It can fork in parallel or sequential, as it would for invite. The > overall request processing is largely no different; the differences > relate to retransmission rules and handling of multiple 200 OK (all > sent upstream for INVITE, only one for anything else, including > OPTIONS). Jonathan: Right; that's what I thought. But (there's always a "but"), how does the proxy make the determination which "200 OK" to send upstream? FCFS? What if the "200 OK" send upstream is not from the desired recepient? A later "200 OK" which gets to the proxy from the desired recepient will be silently discarded. Realistically speaking, I am not sure how often this will happen, or indeed if it is worth the discussion. Just happened to run into this problem while re-doing some of my code; I'm thinking of implementing FCFS for all it is worth. Thanks, - vijay -- Vijay K. Gurbani vkg@lucent.com vkg@research.bell-labs.com vkg@acm.org Internet Software Group/Intelligent Network and Instant Messaging 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 Sep 1 22:34: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 ESMTP id WAA26426 for ; Fri, 1 Sep 2000 22:34: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 F066544361; Fri, 1 Sep 2000 21:34:21 -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 A932A4435B for ; Fri, 1 Sep 2000 21:34:18 -0400 (EDT) Received: from dynamicsoft.com (1Cust214.tnt4.freehold.nj.da.uu.net [63.36.112.214]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id WAA11158; Fri, 1 Sep 2000 22:34:16 -0400 (EDT) Message-ID: <39B06683.FE987438@dynamicsoft.com> Date: Fri, 01 Sep 2000 22:31:31 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Neil Deason Cc: Hisham Khartabil , Loita.Jahnsson@uab.ericsson.se, jhornsby@ubiquity.net, sip@lists.bell-labs.com Subject: Re: [SIP] transaction identification References: <002e01c011c2$94a85000$4e34c3c1@ubiquity.co.uk> <39AC83A0.68A61CA@dynamicsoft.com> <39AE1096.95161017@uab.ericsson.se> <39AE38A0.526A55F8@ubiquity.net> <39AF4ADB.B8751B55@dynamicsoft.com> <39AF51F7.CDBFE713@ericsson.fi> <39AF563A.8EEB995@dynamicsoft.com> <39AF7E14.FE7886BB@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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Neil Deason wrote: > > Jonathan Rosenberg wrote: > > > > Hisham Khartabil wrote: > [...] > > > > 2. the branch ID, in addition to the two components mentioned in the bis > > > > draft, also now contains a third piece, which is sufficient extra info > > > > to make the branch ID unique across all transactions as defined in 1. > > > > Note that this uniqueness piece must be separable -i.e., you can't > > > > include it in the hash of the incoming R-URI, TO, From,CSeq, Call-ID > > > > defined in bis. Otherwise, you can't detect spirals. This could be the > > > > transaction ID + server instance. > > > > > > Would this be just for the encrypted via headers only? > > > > Well, nearly as I can tell it would only be needed if there is Via > > hiding being done. > > Correct. The branch param is not one of the encrypted > components when Via hiding is performed. This means > that if we make the branch param globally unique there > is no longer a requirement on Proxies to try and decrypt > all Via headers marked as hidden to perform loop detection. > A proxy can just just recognise it's own globally unique > branch param within any hidden Vias. It might be worthwhile to take a step back and examine whether or not this kind of fix (just needed for via hiding) can rather be addressed by ditching via hiding and doing something else entirely. I don't think its widely implemented, and there are definintely issues with the security model (the next hop provides the feature for you). -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 Sat Sep 2 04: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 ESMTP id EAA11381 for ; Sat, 2 Sep 2000 04:45: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 E48B64435B; Sat, 2 Sep 2000 03:44:45 -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 458BE44336 for ; Sat, 2 Sep 2000 03:44:25 -0400 (EDT) Received: from bigboy ([203.197.20.141]) by hd2.dot.net.in (8.8.8/8.8.8) with SMTP id OAA16783 for ; Sat, 2 Sep 2000 14:10:40 +0530 (IST) Message-ID: <000301c014ba$444c5660$8d14c5cb@bigboy> Reply-To: "farhan" From: "farhan" To: "sip" Date: Sat, 2 Sep 2000 14:16:17 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Subject: [SIP] SIP] SIP feature services Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit i guess this is a reprise of what i was trying to figure out somewhile ago on this list ... if an application server is capable of offering a service, it is agreed that the proxies need have no understanding of the service beyong plain message forwarding. accepted. should a client UA be aware and have specially programmed features to make use of the service being offered by a server? the answer SHOULD be No. Ideally a service should be accesible from any SIP UA that has a few basic capabilities built-in. take your POTS phone for instance. the phone instrument is not aware of the fact that I am dialing the changed number service, listening to the instructions, punching in the old number and hearing the changed number being read out. this is all being done without the phone instrument being aware of the application level interactivity. i would expect the same sort of genralised interactivity to be possible within the SIP framwork. i will therfore argue for a method that prompts and accepts text input from the user (through the user agent) and another method that will diplay simple text messages. This is what MESSAGE does already and we may possibly need something like a PROMPT method (displaying a prompt and getting a user response). A poor man's equivalent of sip forms (aka HTML forms). Just like there are a lot of people building great applications over SMS service, I expect that we will also build some great apps riding over MESSAGE/PROMPT (or whatever the scheme is). As Dr. Rosenberg pointed out on this list a couple of days ago, MESSAGE is not restricted to just plain text. I can send URLs that point to HTML forms, media streams (even another sip url!!!, hehe okay okay we are not redirecting anything here...) and the works. the interactivity paradigm using messages is dialog based (I dont mean the dialog windows, but textual dialogs). People who have played MUD in their younger days (or dotage) will remember what it was like. - farhan _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sat Sep 2 11:14: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 ESMTP id LAA14168 for ; Sat, 2 Sep 2000 11:14: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 4AA364435F; Sat, 2 Sep 2000 10:14:29 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from proxy2.ba.best.com (proxy2.ba.best.com [206.184.139.14]) by lists.bell-labs.com (Postfix) with ESMTP id F215A44336 for ; Sat, 2 Sep 2000 10:14:25 -0400 (EDT) Received: from amd.echeque.com (jamesd.vip.best.com [204.156.153.125]) by proxy2.ba.best.com (8.9.3/8.9.2/best.out) with ESMTP id IAA05541; Sat, 2 Sep 2000 08:13:19 -0700 (PDT) Message-Id: <4.3.1.2.20000902081022.027e6a60@shell11.ba.best.com> X-Sender: jamesd@shell11.ba.best.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Sat, 02 Sep 2000 08:12:38 -0700 To: Michael Thomas , Henning Schulzrinne , Jonathan Rosenberg , David Harris , "Sip-Implementors (E-mail)" , sip From: "James A. Donald" Subject: Re: [SIP] Re: SIP gateways and authentication 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com -- At 09:59 AM 8/31/2000 -0700, Michael Thomas wrote: > It looks like your argument is not with the SIP WG but with the CAT > WG. I'm sure a lot of folks there would be willing to entertain (or > not) this argument. In particular, the assertion that that Kerberos > is inherently subject to dictionary attacks looks more like an > indictment against symmetric key cryptography in general, rather > than Kerberos in particular. There is nothing special about symmetric key cryptography that makes it particularly subject to dictionary attacks. In all public key solutions, the public keys are used to set up a symmetric key that is not subject to dictionary attacks. It is probably possible to set up a system with properties similar to those that I outlined using nothing but symmetric key cryptography, though it would be more complex, hence harder to understand and harder to get right. Existing symmetric key solutions (Kerberos) are vulnerable to dictionary attack Existing public key solutions are hard to use and unpopular. This is a property of the particular implementations, and the particular tasks for which they are used, not a property of the underrlying technology Most proposed alternatives to Kerberos work the same way as kerberos does for the user, and are arguably simpler in their internal implementation, but employ public key operations internally. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG sz1++Q1L/bMWO8371Rxt7o5B/H0Xsn6u/sX227rI 4PFseTKUfAEU9X1rCbMXXjjvrDk7PeeoknjQHHjJr _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sat Sep 2 12:55: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 ESMTP id MAA14697 for ; Sat, 2 Sep 2000 12: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 B59C044363; Sat, 2 Sep 2000 11:54:32 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from proxy2.ba.best.com (proxy2.ba.best.com [206.184.139.14]) by lists.bell-labs.com (Postfix) with ESMTP id C6B9144336 for ; Sat, 2 Sep 2000 11:54:28 -0400 (EDT) Received: from amd.echeque.com (jamesd.vip.best.com [204.156.153.125]) by proxy2.ba.best.com (8.9.3/8.9.2/best.out) with ESMTP id JAA07064; Sat, 2 Sep 2000 09:52:34 -0700 (PDT) Message-Id: <4.3.1.2.20000902094940.030e9a40@shell11.ba.best.com> X-Sender: jamesd@shell11.ba.best.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Sat, 02 Sep 2000 09:51:32 -0700 To: "Brian Stucker" , "'Henry Sinnreich'" , Michael Thomas , Michael Thomas , Jonathan Rosenberg , "David Harris" , "Sip-Implementors (E-mail)" , sip From: "James A. Donald" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [SIP] SIP gateways and authentication Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com -- From: Henry Sinnreich [mailto:Henry.Sinnreich@WCOM.com]: > > Am not sure such complexity is jutified for phone calls having the > > cost close to e-mail. At 10:10 AM 9/1/2000 -0500, Brian Stucker wrote: > Cheap or not, do you really want to start chipping away at the image > that people have that a phone call is ubiquitous, reliable, and > (relatively) secure transaction in their minds? It took decades > of > marketing and technical performance to get to that point, why not > try to maintain that in the future? Possibly you understood Henry Sinnreich as referring to the computational cost of preventing offline dictionary attacks. I understood him to be referring to the user experience. The user experience should of course be unaffected by the defence against dictionary attack, if that defense is correctly implemented, but he is correct to claim there is a computational cost, In the scheme I described, there is one public key operation per pair of entities interacting, per logon session, not several public key operations per interaction. Several public key operations per interaction would indeed be an unacceptable expense. One public key operation per pair of interacting entities per logon session, not per message, is unlikely to be a significant expense. A single https web page takes many public key operations, typically eight to twelve per web page, and this has been a significant, but tolerable, barrier to the deployment of https. To implement security at a cost similar to that of https would indeed be an unacceptable cost, because of the large number of very small interactions we expect. The proposal I described was designed to minimize the cost of public key operations, to keep them to a level much lower than those of https. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG F4BXeae+tmDuVH7AGWuWikXT20fqIq6Narhv2/0C 4gHoCmYD2HS/uDHpSCaIQuLuU707H/TjqyEoPD2s1 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sat Sep 2 14: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 ESMTP id OAA15210 for ; Sat, 2 Sep 2000 14: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 074924436C; Sat, 2 Sep 2000 13:13:33 -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 0663944336 for ; Sat, 2 Sep 2000 13:13:12 -0400 (EDT) Received: from bigboy ([203.197.20.111]) by hd2.dot.net.in (8.8.8/8.8.8) with SMTP id XAA07667 for ; Sat, 2 Sep 2000 23:39:27 +0530 (IST) Message-ID: <001f01c01509$b9c10ea0$6f14c5cb@bigboy> Reply-To: "farhan" From: "farhan" To: "sip" Date: Sat, 2 Sep 2000 23:45:06 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Subject: [SIP] INVITE timeout in a gateway queue Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit the response code 182 is generated when your call is in the queue. 182 is a provisional response. this means that the 182 response is not final and hence, INVITE is retransmitted until a final response is received. it is quite normal to have nearly 15-20 callers waiting to call on some of our gateway deployments. For instance, our gateway at Hyderabad, India is the only gateway for a city of 5 million people. In such a case what should be the behaviour of the UAS as well as UAC ? Please do remember that an average phone call is of 3 minutes. The very idea of a queue makes sense only when we can have atleast 2 callers in the queue (otherwise it is a trivial case of just a call-waiting). Thus, an invite should be capable of being 'alive' for as long as the queue times 3 minutes. how is this achieved? 1. the UAC will keep re-transmitting INVITEs and keep getting back 182 reponse code. After a minute, the UAC could erroneously time-out. Thus, is it implicit that as long as the provisional responses are coming in from the UAS, we keep the UAC 'alive' with the INVITE request? 2. Upon receiving a 182 response, can or should the UAC stop retranmitting INVITEs? The UAS will, in anycase keep transmitting the final response until an ACK or timeout. 3. Suppose, a particular call is n callers away in the queue. Each time a call finishes, we can generate a new queue message. This queue message has to be sent to all the other callers in the queue with their latest position in the queue. How do we handle out of order queue messages? How do we (and should we) reliably deliver the queue updation messages to all the UACs in the queue ? how does a reference stack like sipd or that of dynamicsoft handle this? - farhan _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sat Sep 2 15:41: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 ESMTP id PAA15732 for ; Sat, 2 Sep 2000 15:41: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 6F37444370; Sat, 2 Sep 2000 14:40:46 -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 7F33444336 for ; Sat, 2 Sep 2000 14:40:42 -0400 (EDT) Received: from marta.cs.columbia.edu (marta.cs.columbia.edu [128.59.19.195]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id PAA21940; Sat, 2 Sep 2000 15:40:40 -0400 (EDT) Received: from localhost (kns10@localhost) by marta.cs.columbia.edu (8.9.3/8.9.3) with ESMTP id PAA21101; Sat, 2 Sep 2000 15:40:40 -0400 (EDT) Date: Sat, 2 Sep 2000 15:40:40 -0400 (EDT) From: Kundan Singh To: farhan Cc: sip Subject: Re: [SIP] INVITE timeout in a gateway queue In-Reply-To: <001f01c01509$b9c10ea0$6f14c5cb@bigboy> 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com > the response code 182 is generated when your call is in the queue. > 182 is a provisional response. this means that the 182 response is not final > and hence, INVITE is retransmitted until a final response is received. No. INVITE retransmission stops after you receive a provisional response. This is different from other methods. Read 10.5.1 of 2543bis. > > it is quite normal to have nearly 15-20 callers waiting to call on some of > our gateway deployments. For instance, our gateway at Hyderabad, India is > the only gateway for a city of 5 million people. In such a case what should > be the behaviour of the UAS as well as UAC ? > Please do remember that an average phone call is of 3 minutes. The very idea > of a queue makes sense only when we can have atleast 2 callers in the queue > (otherwise it is a trivial case of just a call-waiting). Thus, an invite > should be capable of being 'alive' for as long as the queue times 3 minutes. > how is this achieved? > > 1. the UAC will keep re-transmitting INVITEs and keep getting back 182 > reponse code. After a minute, the UAC could erroneously time-out. Thus, is > it implicit that as long as the provisional responses are coming in from the > UAS, we keep the UAC 'alive' with the INVITE request? > 2. Upon receiving a 182 response, can or should the UAC stop retranmitting > INVITEs? The UAS will, in anycase keep transmitting the final response until > an ACK or timeout. > 3. Suppose, a particular call is n callers away in the queue. Each time a > call finishes, we can generate a new queue message. This queue message has > to be sent to all the other callers in the queue with their latest position > in the queue. How do we handle out of order queue messages? How do we (and > should we) reliably deliver the queue updation messages to all the UACs in > the queue ? > > how does a reference stack like sipd or that of dynamicsoft handle this? > > - farhan > > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > 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 Sat Sep 2 21:59: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 ESMTP id VAA18982 for ; Sat, 2 Sep 2000 21:59: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 048D344370; Sat, 2 Sep 2000 20:58:51 -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 D718F44336 for ; Sat, 2 Sep 2000 20:58:47 -0400 (EDT) Received: from dynamicsoft.com (1Cust182.tnt5.freehold.nj.da.uu.net [63.36.113.182]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id WAA11897; Sat, 2 Sep 2000 22:00:23 -0400 (EDT) Message-ID: <39B1B01A.A0AA8584@dynamicsoft.com> Date: Sat, 02 Sep 2000 21:57:46 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: farhan Cc: sip Subject: Re: [SIP] SIP] SIP feature services References: <000301c014ba$444c5660$8d14c5cb@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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit farhan wrote: > > i guess this is a reprise of what i was trying to figure out somewhile ago > on this list ... > > if an application server is capable of offering a service, it is agreed that > the proxies need have no understanding of the service beyong plain message > forwarding. accepted. > > should a client UA be aware and have specially programmed features to make > use of the service being offered by a server? the answer SHOULD be No. > Ideally a service should be accesible from any SIP UA that has a few basic > capabilities built-in. I agree that many services should not require service specific capabilities in the client. But, there are a few caveats: 1. certain services require explicit invocation, as opposed to being invoked as side effects of other, normal processing. Classic example is call hold. We need clients to explicitly have support for this (and indeed its specified in sip). 2. you can also build services into phones if you like; the SIP architecture is very good in this regard, in that certain services can equally well live in either place. > i would expect the same sort of genralised interactivity to be possible > within the SIP framwork. i will therfore argue for a method that prompts and > accepts text input from the user (through the user agent) and another method > that will diplay simple text messages. This is what MESSAGE does already > and we may possibly need something like a PROMPT method (displaying a prompt > and getting a user response). A poor man's equivalent of sip forms (aka HTML > forms). I agree that prompting for data is critical, but we already have a fantastic way of doing it, through http/html forms. I see little need to replicate this with a SIP specific version. messaging (that is, displaying of content), can be done in many ways, many of which don't even require the MESSAGE method. -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 Sat Sep 2 22:21: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 ESMTP id WAA19152 for ; Sat, 2 Sep 2000 22:21:53 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id EE3CA44381; Sat, 2 Sep 2000 21:21:35 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from smtp-out2.bellatlantic.net (smtp-out2.bellatlantic.net [199.45.39.157]) by lists.bell-labs.com (Postfix) with ESMTP id 05D0344336 for ; Sat, 2 Sep 2000 21:21:31 -0400 (EDT) Received: from cs.columbia.edu (adsl-151-198-20-48.bellatlantic.net [151.198.20.48]) by smtp-out2.bellatlantic.net (8.9.1/8.9.1) with ESMTP id WAA28809; Sat, 2 Sep 2000 22:21:24 -0400 (EDT) Message-ID: <39B1B5B3.66E5B6EA@cs.columbia.edu> Date: Sat, 02 Sep 2000 22:21:39 -0400 From: Henning Schulzrinne X-Mailer: Mozilla 4.7 [en]C-CCK-MCD BA45DSL (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: sip@lists.bell-labs.com Subject: Re: [SIP] transaction identification References: <002e01c011c2$94a85000$4e34c3c1@ubiquity.co.uk> <39AC83A0.68A61CA@dynamicsoft.com> <39AE1096.95161017@uab.ericsson.se> <39AE38A0.526A55F8@ubiquity.net> <39AF4ADB.B8751B55@dynamicsoft.com> <39AF51F7.CDBFE713@ericsson.fi> <39AF563A.8EEB995@dynamicsoft.com> <39AF7E14.FE7886BB@ubiquity.net> <39B06683.FE987438@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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit > It might be worthwhile to take a step back and examine whether or not > this kind of fix (just needed for via hiding) can rather be addressed by > ditching via hiding and doing something else entirely. I don't think its > widely implemented, and there are definintely issues with the security > model (the next hop provides the feature for you). > This is only one of the problems. With hindsight, my other concerns about Via hiding: - complexity, particularly hidden "gotchas" that surface at various points (as in this instance); - interference with loop detection and debugging; - over-promise: unlike HTTP, where via-hiding makes some sense since all data is in one place, Via-hiding in SIP by itself does nothing to hide the caller. (I'm having a hard time thinking of applications where hiding the caller doesn't matter, but where hiding a proxy does.) There's all kind of other information leakage: - Contact - Route/Record-Route - SDP (various places, including o=, c=) - possibly accidental leakage in User-Agent header and Call-ID, depending on how they're generated Also, unless this is implemented everywhere, the feature is not likely to be very useful, without the sender having any recourse such as "don't route this request unless you can hide". I would guess that almost all existing proxies simply ignore the Hide header. Thus, there is a danger of asking for via-hiding and then deluding oneself that this indeed provides anonymity. I think we should welcome opportunities to simplify the spec by removing marginally useful features. For real anonymity, a back-to-back UA (that creates a "fresh" SDP entry and otherwise scrubs the request of identifying information) seems about the only viable approach. Email has existed for many years without this feature, with "mixers" for anonymity. If this is truly needed, I would argue that this should be an extension specified separately, with a Proxy-Require header. Henning _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sun Sep 3 00:11: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 ESMTP id AAA21147 for ; Sun, 3 Sep 2000 00:11: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 D43844437C; Sat, 2 Sep 2000 23:11:24 -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 07F7244336 for ; Sat, 2 Sep 2000 23:11:21 -0400 (EDT) Received: from dynamicsoft.com (1Cust182.tnt5.freehold.nj.da.uu.net [63.36.113.182]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA11950; Sun, 3 Sep 2000 00:13:02 -0400 (EDT) Message-ID: <39B1CF30.F4457C28@dynamicsoft.com> Date: Sun, 03 Sep 2000 00:10:24 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Raymond Nadeau Cc: sip@lists.bell-labs.com Subject: Re: [SIP] End-to-end transport References: <0d9401c01455$7f04f1a0$ba01030a@nuance.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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit No, you cannot "force it". It can be TCP end to end if all the nodes along the path support it and prefer to be contacted via TCP. You would use SRV records and assign a higher priority to the TCP records. In your particular example, if Q publishes a TCP SRV record with higher priority than the UDP one, the P->Q connection will be TCP. -Jonathan R. > Raymond Nadeau wrote: > > Is there any way we can force a SIP transaction going through multiple > nodes to be TCP end-to-end? > > For example, A sends an Invite to B and that Invite is routed through > two proxies P and Q. My understanding is that the A-P and Q-B > connections can be over TCP for example but that the P-Q connection > can be either UDP or TCP. Or will the transport protocol parameter in > the request URI forces all the proxies along the way to use TCP? > > Thanks, > > Raymond Nadeau > -- 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 Sun Sep 3 00:19: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 ESMTP id AAA21176 for ; Sun, 3 Sep 2000 00:19: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 4060844382; Sat, 2 Sep 2000 23:18:47 -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 2695944371 for ; Sat, 2 Sep 2000 23:18:44 -0400 (EDT) Received: from dynamicsoft.com (1Cust182.tnt5.freehold.nj.da.uu.net [63.36.113.182]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA11971; Sun, 3 Sep 2000 00:20:25 -0400 (EDT) Message-ID: <39B1D0EB.BDD51690@dynamicsoft.com> Date: Sun, 03 Sep 2000 00:17:47 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: vkg@lucent.com Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Forking proxy and OPTIONS References: <39AFD22B.6E65E404@lucent.com> <39B02015.12C92FFA@dynamicsoft.com> <39B02682.B08C0D4C@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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit "Vijay K. Gurbani" wrote: > > > It can fork in parallel or sequential, as it would for invite. The > > overall request processing is largely no different; the differences > > relate to retransmission rules and handling of multiple 200 OK (all > > sent upstream for INVITE, only one for anything else, including > > OPTIONS). > > Jonathan: > > Right; that's what I thought. But (there's always a "but"), how does > the proxy make the determination which "200 OK" to send upstream? FCFS? > What if the "200 OK" send upstream is not from the desired recepient? > A later "200 OK" which gets to the proxy from the desired recepient will > be silently discarded. FCFS. Remember, the methods here are not seeking to INVITE a user; so, I am not sure there is really a useful definition of "desired recipient". > > Realistically speaking, I am not sure how often this will happen, or > indeed if it is worth the discussion. For BYE, never with the bis draft, since its routing is handled by Route headers. Similarly for INFO. OPTIONS can be sent as the "initial" request, and thus might fork. The result is that you get back one of the possible several capabilities. REGISTER might fork, but this is unlikely since it is not targeted at a user, but rather a domain. -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 Sun Sep 3 00:24: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 ESMTP id AAA21203 for ; Sun, 3 Sep 2000 00:24: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 83E2A4438D; Sat, 2 Sep 2000 23:23:11 -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 E4A3444389 for ; Sat, 2 Sep 2000 23:23:06 -0400 (EDT) Received: from bigboy ([203.197.20.11]) by hd2.dot.net.in (8.8.8/8.8.8) with SMTP id JAA10663 for ; Sun, 3 Sep 2000 09:49:25 +0530 (IST) Message-ID: <001001c0155e$f08dae20$0b14c5cb@bigboy> Reply-To: "farhan" From: "farhan" To: "sip" Date: Sun, 3 Sep 2000 09:55:05 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Subject: [SIP] Re: SIP feature services Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit the only problem with using http/html forms for prompting and display is that we will be making sip dependent upon another 'bag' - an html browser is a pretty huge thing. it will also be difficult to implement one in all its glory on the phone devices (witness the buzz/noise being made for WAP). there are both sides to this issue. 1. it is a lazy sip programmers ideal solution to hand over display/prompting to http. It is pretty flexible too. Integrating the existing browsers like Internet Explorer into a UA is a child's play (you just drop in an activex webbrowser control onto your UA's interface). It can be trivially done in about 10 lines of code, calling the Navigate method of webbrowser interface is all you have to do. On the other hand, combining javascript, dhtml, et all, it will be a total redefintion of all that telephony is about and the way it integrates with web experience. 2. it will be a pretty drab alternative to use simple text to prompt users. This maybe all that is required in 90% of the cases. We have used it very effectively in our hotfoon.com experiment (this was before i became a sip convert). Hotfoon, when started is just a dumb terminal that displays lines of streaming text and accepts text inputs from a single edit box. The idea was to have a user interface that can be used anywhere from Windows to Linux to Palm to a small LCD display on a mobile phone. The issue is therefore, do we make web browsing a complusory facility to be available alongside a sip UA? Allowing it so will in make sip-ping a top class experience. It will integrate web browsing, emailing and everthing else into a unified experience. example: 1. you need to talk to a sales person, you click on the sip url of the browser and the sip ua starts up. 2. In order to connect you to the right person, the sip ua launches another web browser window and display a form asking you for preferred language you select Hindi. 3. the sip proxy redirects you now to a sip based call-center in bombay. the phone rings in bombay it is 2 am. no one picks it up. 4. You time-out, the sip app server/proxy in turn suggests that you send them a voice mail, simultaneously the voice mailer starts (your sip UA spawned the browser with a voice mail request). Your recorded enquiry is now dropped into your email UA. An incredibly useful and 'silent' experience (the end-user is unaware of the technicalities, she is just filling html forms and clicking on the chosen alternatives). All this said, I will still want a simpler alternative of plain text prompting/display for the sake of those devices that cannot afford a web browser. 1. sip is completely implementable with just a UDP stack (and a little bit of ICMP thrown in). It will be nice to keep it that way. implementing UDP on embedded systems is pretty easy. getting TCP going is resource intensive. for http UDP is a must. 2. most of the time, the dialog between the user and the telephony service provider is in short simple messages like "Do u want to leave a message?" or "Welcome to Acme service center. Enter you model number:". These should be possible without the need for a browser. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sun Sep 3 00:43: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 ESMTP id AAA21344 for ; Sun, 3 Sep 2000 00:43: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 9B5EA4437C; Sat, 2 Sep 2000 23:43:37 -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 6BE8644336 for ; Sat, 2 Sep 2000 23:43:34 -0400 (EDT) Received: from dynamicsoft.com (1Cust182.tnt5.freehold.nj.da.uu.net [63.36.113.182]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA12016; Sun, 3 Sep 2000 00:45:19 -0400 (EDT) Message-ID: <39B1D6C1.2CBEA6D4@dynamicsoft.com> Date: Sun, 03 Sep 2000 00:42:41 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Hong Chen Cc: Anders Kristensen , sip@lists.bell-labs.com Subject: Re: [SIP] SIP feature services References: <39AEACDE.F5686B52@cisco.com> <39AF5E23.A98F4EC9@dynamicsoft.com> <39AFD999.AAE9F83@cisco.com> <39AFF3AC.B71D4C5@dynamicsoft.com> <39AFFB3A.7FA1C772@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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Hong Chen wrote: > > > Request URIs won't (usually) contain info that identifies services to be > > invoked. Maybe you subscribe to feature-i at some proxy -- it is then up > > to that proxy to figure out to apply feature-i to your calls. > > > > Yes, some services can be subscribed by users and can be trigged inside SIP > proxy. > But the issues are: > - Do we need to define the trig points (for both originating and > terminating trigs) and their conditions in Proxy? A trigger point is simply some kind of system event that is useful for the purposes of doing something service related. SIP as a protocol defines various state machines and messages, any of which might serve as a useful trigger for doing something. I see no need for any additional standardization. > This could be a design and implementation issue. > - Further more, it may not possible to define and implement trigs for some > feature services. > How can we handle these services by SIP? I cannot answer that without some examples or a more precise definition. > - How can we use SIP to implement user based and/or call based feature > services? Has that not been the discussion of this thread to date? As Anders has pointed out, the services are encapsulated within the logic of proxies and other SIP devices along the session establishment path. -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 Sun Sep 3 01:00: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 ESMTP id BAA21390 for ; Sun, 3 Sep 2000 01:00: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 A20534438F; Sat, 2 Sep 2000 23:59:55 -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 6D38B44371 for ; Sat, 2 Sep 2000 23:59:51 -0400 (EDT) Received: from bigboy ([203.197.20.11]) by hd2.dot.net.in (8.8.8/8.8.8) with SMTP id KAA07368 for ; Sun, 3 Sep 2000 10:26:11 +0530 (IST) Message-ID: <003d01c01564$139c57e0$0b14c5cb@bigboy> Reply-To: "farhan" From: "farhan" To: "sip" Date: Sun, 3 Sep 2000 10:31:51 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Subject: [SIP] sip chat (group messaging) Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit while sip is not really meant for an irc like service, we cannot deny that : 1. text chat is a real time session. 2. it needs initiation as much as video conference does. 3. it sip's holy duty to provide for group messaging. (it is the most primitive of real time conferences on the Net). MESSAGE does a good job of two-party chat. How does it evolve into a multiway chat? where in a group of users, every message of a user goes to every other user? Dr. Schulzrinne has recommended the use of sip:groupchat@chatserver.com as a way out. the userid here, is ofcourse, a moniker for the group. much like a mailing list. This has two deployments alternatives: 1. a group is hosted (much like a mailing list) by a separate host computer. this means that it is impossible to create groups dynamically. If I am chatting with A and I get a message from B and I want to chat together with A and B such that when I type a message both A and B get it and vice versa (or is it multi-versa?). I will not be able to dynamically create and cleardown chat groups. 2. The groupchat can also be hosted by one of the participants of the chat by colocating a group messaging server along with the UA (the group messaging server is not a very complicated thing once you already have a MESSAGE capabilty on your basic sip stack). If the users who hosts the group logs out, the group tumbles. An ideal solution would be that all the chatters in the group should be sending separate MESSAGEs to each of the participants of the group. Therefore the group is completely peer-to-peer (wow! we are with it now!). As the text messages are typically small (less than 64 bytes on an average) and the groups are typically about 4-5 people rarely going to 10 (I only once saw a group of about 500 when roger waters of the group pink floyd came onto MSN chat). This means that bandwidth is not really an issue and it is quite normal to expect a user to have enough bandwidth to send 100 byte messages to 5 people every 15-20 seconds (if you are a very chatty person). We have an experimental system under test wherein this is what we are doing: 1. All the users chatting in a group share a common Call-ID. The call-Id helps in differentiating between a message meant for the group (so that the receiving user knows that others in the group have also read/seen the message) and a private message from the same sender meant only for the receiver's eyes. 2. When a new user is added to the group, it is done by sending a message to the new user with the call-id of the group, thus the reply messages from the new group member use the same callid. 3. Until here, everything is exactly as per the rosenberg-im draft document. this where things start getting murky. 4. How does a new user know who else are in the group? we need a way to pass the group member's list to the new user. 5. When a new member sends a message to the each of the group members, the group members add the sip url of the new member to the group list. Right now a new member is being JOINed by a flagrant voilation of sip protocol: we are using INVITE method to signal to a new user that she should join the group. sdp describes the session as "m=application 5060 SIP/2.0 MESSAGE" and lists the participants as a number of "a=participant:" fields. are there any suggestions for a better alternative? I would like to preserve being independent of a group chat servers for the simple reason that there are no resource constraints that require anything beyond what any user on the internet has and the rest is engineering. - farhan. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sun Sep 3 01:16: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 ESMTP id BAA22634 for ; Sun, 3 Sep 2000 01: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 0C72944391; Sun, 3 Sep 2000 00:15:44 -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 B8A6044336 for ; Sun, 3 Sep 2000 00:15:40 -0400 (EDT) Received: from dynamicsoft.com (1Cust182.tnt5.freehold.nj.da.uu.net [63.36.113.182]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA12052; Sun, 3 Sep 2000 01:14:41 -0400 (EDT) Message-ID: <39B1DDA3.1B5D29B@dynamicsoft.com> Date: Sun, 03 Sep 2000 01:12:03 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Phil Hoffer Cc: sip@lists.bell-labs.com References: <006701c01350$e890d090$5334c3c1@ubiquity.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] Re: Open issue with Quotes in WWW-Authenticate ?? Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit The problem is in rfc2617, which is inconsistent in the usage of quoted strings for certain parameters, namely the uri. The BNF is clear in that it is not quoted: > 3.2.2 The Authorization Request Header > > The client is expected to retry the request, passing an Authorization > header line, which is defined according to the framework above, > utilized as follows. > > credentials = "Digest" digest-response > digest-response = 1#( username | realm | nonce | digest-uri > | response | [ algorithm ] | [cnonce] | > [opaque] | [message-qop] | > [nonce-count] | [auth-param] ) > > username = "username" "=" username-value > username-value = quoted-string > digest-uri = "uri" "=" digest-uri-value > digest-uri-value = request-uri ; As specified by HTTP/1.1 but the examples show the uri value to be a quoted string: > Authorization: Digest username="Mufasa", > realm="testrealm@host.com", > nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", > uri="/dir/index.html", > qop=auth, > nc=00000001, > cnonce="0a4f113b", > response="6629fae49393a05397450978507c4ef1", > opaque="5ccc069c403ebaf9f0171e9517f40e41" > So, the issue is which one to use. Common usage appears to be quoted, so the proposal is to go with that. -Jonathan R. Phil Hoffer wrote: > > Hi Jonathan, > > In your SIP ML Open Issues presentation for IETF48 .... > > http://www.softarmor.com/sipwg/meets/IETF48/slides/pres-rosenburg-sipwg_jul0 > 0_listissues.ppt > > the last slide mentions "Quotes in WWW-Authenticate" and details.... > > > > BNF and examples for params in WWW-Authenticate inconsistent in http > Do we use quotes or not? > Proposal: > Quotes > > > > I'm confused with this slide as I'm unaware of an open issue in this area. > The BNF is quite clear, however the examples given in "SIP Telephony Call > Flow Examples" > (http://search.ietf.org/internet-drafts/draft-ietf-sip-call-flows-01.txt) > are inconsistent with the SIP specification. > This might have led to the confusion which appears to surround the four > headers used for authentication. > > I can appreciate that there is some scope for lenient parsing of the > parameters in the authentication related headers, but as far as I'm > concerned the spec seems fine. > > Can you clear up my confusion? > > Thanks In Advance > Phil Hoffer > > http://www.ubiquity.net -- 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 Sun Sep 3 22: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 ESMTP id WAA14834 for ; Sun, 3 Sep 2000 22:19: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 898AD44393; Sun, 3 Sep 2000 21:18:51 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from proxy2.ba.best.com (proxy2.ba.best.com [206.184.139.14]) by lists.bell-labs.com (Postfix) with ESMTP id 1706144348 for ; Sun, 3 Sep 2000 21:18:48 -0400 (EDT) Received: from amd.echeque.com (jamesd.vip.best.com [204.156.153.125]) by proxy2.ba.best.com (8.9.3/8.9.2/best.out) with ESMTP id TAA02798; Sun, 3 Sep 2000 19:16:31 -0700 (PDT) Message-Id: <4.3.1.2.20000903191303.0301b578@shell11.ba.best.com> X-Sender: jamesd@shell11.ba.best.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Sun, 03 Sep 2000 19:14:25 -0700 To: Henning Schulzrinne , Brian Stucker From: "James A. Donald" Subject: [SIP] Re: SIP gateways and authentication Cc: sip 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com -- At 1214 PM 9/1/2000 -0400, Henning Schulzrinne wrote > As has been said a few times on this list already This group is > *not* chartered to develop new encryption or authentication > algorithms or protocols. To make cell phones work satisfactorily, to prevent cloning, the cell phone protocol had to be an encryption protocol. If SIP is secure, it WILL be an encryption protocol, using standard long established algorithms, almost certainly protocol analogous to that of kerberos, and an algorithm similar to that of SPEKE. If it is not an encryption protocol, it WILL NOT be secure. Let us look at what happened with cell phones. Cell phones were insecure, and suffered cloning, with users who had at all times kept complete control over their phone finding themselves charged by the phone company with bills of tens of thousands of dollars, and no way to prove or disprove who was responsible for those phone calls. To remedy this problem, crappy encryption was belatedly retrofitted into cell phones. It turned out that the encryption was not good enough, being a classic snake oil product, probably concocted by the french spy agency who did not want people using good encryption, and a better encryption had to be retrofitted. So the cell phone protocol had to be redone twice, and is still fouled up by this process. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG 4QR3Fl3XkhVHbkpFuVQ7WaKz+C0cYWlkohKFp1Jm 4ehFpyOhRgF8Oecry6vjW1k6r/XUV4s8Z4S0MGqoQ _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sun Sep 3 22:47: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 ESMTP id WAA15866 for ; Sun, 3 Sep 2000 22:47: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 3E08B44396; Sun, 3 Sep 2000 21:46:49 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from proxy2.ba.best.com (proxy2.ba.best.com [206.184.139.14]) by lists.bell-labs.com (Postfix) with ESMTP id 84C2B44348 for ; Sun, 3 Sep 2000 21:46:46 -0400 (EDT) Received: from amd.echeque.com (jamesd.vip.best.com [204.156.153.125]) by proxy2.ba.best.com (8.9.3/8.9.2/best.out) with ESMTP id TAA07461; Sun, 3 Sep 2000 19:45:12 -0700 (PDT) Message-Id: <4.3.1.2.20000903194205.024564a0@shell11.ba.best.com> X-Sender: jamesd@shell11.ba.best.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Sun, 03 Sep 2000 19:43:37 -0700 To: Henning Schulzrinne , Brian Stucker From: "James A. Donald" Cc: sip Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [SIP] SIP gateways and authentication Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com -- At 12:14 PM 9/1/2000 -0400, Henning Schulzrinne wrote: > [...] > > - authenticate resource reservation requests (where resources may > include, particularly for wireless, basic IP connectivity) > > [...] As has been said a few times on this list already: This group > is *not* chartered to develop new encryption or authentication > algorithms or protocols. Application of existing algorithms, if > described in sufficient detail, are obviously appropriate Obviously, if SIP is going to be used to "allocate resources", we are going to need a SIP encryption protocol to avoid what happened, and is still happening, with cell phones. Thus encryption protocols must be designed, just as they eventually were for cell phones. No one on this list has ever proposed a new encryption *algorithm*, and no one with sufficient expertise to propose an new encryption *algorithm* has posted on this list. I believe I know the names of everyone in the world with sufficient expertise to propose new encryption algorithms. It is not a very long list, and I am not on it. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG IgGbVt8kpu4ifrxTQGyUU16bxIOyEJfGKBT5j/36 4I3x9qP1pEGA8nDV3yh19s15T4F9unUCrqp5iHK/D _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sun Sep 3 23:25: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 ESMTP id XAA16154 for ; Sun, 3 Sep 2000 23:25: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 007F044398; Sun, 3 Sep 2000 22:25:24 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from proxy4.ba.best.com (proxy4.ba.best.com [206.184.139.15]) by lists.bell-labs.com (Postfix) with ESMTP id 8ABF344348 for ; Sun, 3 Sep 2000 22:25:21 -0400 (EDT) Received: from amd.echeque.com (jamesd.vip.best.com [204.156.153.125]) by proxy4.ba.best.com (8.9.3/8.9.2/best.out) with ESMTP id UAA07951; Sun, 3 Sep 2000 20:24:49 -0700 (PDT) Message-Id: <4.3.1.2.20000903195550.07770ea8@shell11.ba.best.com> X-Sender: jamesd@shell11.ba.best.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Sun, 03 Sep 2000 20:00:51 -0700 To: Henning Schulzrinne , Jonathan Rosenberg , David Harris , "Sip-Implementors (E-mail)" , sip From: "James A. Donald" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [SIP] SIP gateways and authentication Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com -- James A. Donald writes: > > In all public key solutions,the public keys are used to set up a > > symmetric key that is not subject to dictionary attacks. At 09:32 AM 9/1/2000 -0700, Michael Thomas wrote: > False. A public key solution that chose bad symmetric keys would be > subject to dictionary attacks and much more. All existing public key protocols, for example https, generate ephemeral computer generated symmetric keys that are invulnerable to dictionary attack. The SPEKE protocol, the various EKE protocols and the PGP phone protocol also generate ephemeral computer generated private keys that are invulnerable to dictionary attack, as well as generating ephemeral computer generated symmetric keys that are invulnerable to dictionary attack. James A. Donald: > > Existing symmetric key solutions (Kerberos) are vulnerable to > > dictionary attack Michael Thomas > This is a ludicrous strawman. This is a simple fact, as has been proven by experiment. Once again, I point you to http://theory.stanford.edu/~tjw/krbpass.html > People choose dictionary attackable symmetric keys, not Kerberos. People will always choose such passphrases. Kerberos allows the attack. Modern systems do not. Modern systems, such as SPEKE, are secure even when people choose such passwords, as they almost always do. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG UP7kKPgsDeT0+7xcZCaBx+MpR1w99cX8FWDKmH3Z 4/komD2VbLq1nRMs2vSomlGd1IBRC+OkbOsQGFW6x _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Sep 4 03:34: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 ESMTP id DAA00426 for ; Mon, 4 Sep 2000 03:34: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 ABF7C4436B; Mon, 4 Sep 2000 02:33:56 -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 3205144348 for ; Mon, 4 Sep 2000 02:33:53 -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 e847XXw01873; Mon, 4 Sep 2000 09:33:33 +0200 (MEST) Received: from uabx04c148.uab.ericsson.se.uab.ericsson.se (uabx04c148 [134.138.228.163]) by ms.uab.ericsson.se (8.10.0/8.10.0/uab-2.26) with ESMTP id e847XXL23364; Mon, 4 Sep 2000 09:33:33 +0200 (MET DST) Received: from uab.ericsson.se by uabx04c148.uab.ericsson.se.uab.ericsson.se (8.8.7/client-1.3uab1) id JAA07111; Mon, 4 Sep 2000 09:33:31 +0200 (MET DST) Message-ID: <39B3504B.1D793E29@uab.ericsson.se> Date: Mon, 04 Sep 2000 09:33:31 +0200 From: Loita Jahnsson Organization: Ericsson Utvecklings AB X-Mailer: Mozilla 4.7C-CCK-MCD [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: sv,en-US MIME-Version: 1.0 To: Jonathan Rosenberg , sip@lists.bell-labs.com Subject: Re: [SIP] transaction identification References: <002e01c011c2$94a85000$4e34c3c1@ubiquity.co.uk> <39AC83A0.68A61CA@dynamicsoft.com> <39AE1096.95161017@uab.ericsson.se> <39AE38A0.526A55F8@ubiquity.net> <39AF4ADB.B8751B55@dynamicsoft.com> <39AF51F7.CDBFE713@ericsson.fi> <39AF563A.8EEB995@dynamicsoft.com> <39AF7E14.FE7886BB@ubiquity.net> <39B06683.FE987438@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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Hi, > It might be worthwhile to take a step back and examine whether or not > this kind of fix (just needed for via hiding) can rather be addressed by > ditching via hiding and doing something else entirely. I don't think its > widely implemented, and there are definintely issues with the security > model (the next hop provides the feature for you). Ditching via hiding sounds fair enough to me :) If skipping the branch-id, you might want to consider this (theoretical) case (or variations of it): client-a ---> proxy-1 ---> proxy-2 proxy-1 <--- proxy-2 proxy-1 ---> proxy-2 client-b <--- proxy-1 <--- proxy-2 Consider proxy-1 and proxy-2 to be record-routing. When client-b issues it's BYE it will imply a request-URI of "user-a@client-a" throughout the proxy-chain. If only looking at request-URI, cseq, to, from, call-id, and top-most via I guess there would be no way for the proxies to separate the transactions if they would like to. If it should be possible for the proxies to separate the transactions in cases like this (or variations of it) you might want to consider some alternative solution, if skipping the branch-ID. Best Regards, Loita Jahnsson SIP SW Designer _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Sep 4 03:50: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 ESMTP id DAA00561 for ; Mon, 4 Sep 2000 03: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 EE7C1443A1; Mon, 4 Sep 2000 02:49:59 -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 B936444348 for ; Mon, 4 Sep 2000 02:49:54 -0400 (EDT) Received: by mail.in.huawei.com with Internet Mail Service (5.5.2650.21) id ; Mon, 4 Sep 2000 13:21:50 +0530 Message-ID: <30B58D519274D41187630050BAD918AF07386F@mail.in.huawei.com> From: Bodgey Yin Shaohua To: sip@lists.bell-labs.com Date: Mon, 4 Sep 2000 13:21:49 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C01644.FB4BED40" Subject: [SIP] A question about Request-URI: Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com 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_01C01644.FB4BED40 Content-Type: text/plain; charset="iso-8859-1" Hi: I find a difference among different versons of the draft of SIP Telephony Call Flow Examples: Before May 2000, in the Request-URI of SIP INVITE, there is a address of the Pxory the message will head, but the version after this time, there is Callee's address the message will head. In section 4.3 of RFC2543, there writes "Typically, the UAC sets the Request-URI and TO to the same SIP URL, pesumed to remain unchanged over long time periods", so the latter case is right. But it is difficult to explain the following word in this section that is "The host part of the Request-URI typically agrees with one of the host name of the receiving server. If it does not, the sever SHOULD proxy the request to the address indicated or return 404 response if it is unwilling to do so". I don't know what is meaning of the "receiving server"? If the receiving server is a proxy server, for the latter case, it may lead to proxy server return 404 reponse and the call fails because the Request-URI is not the address the Proxy server. Therefore, it is a fuzzy or an error description. we need give a more clear description. Best regards! Bodgey Yin Engineering Division Huawei Technology India Private, LTD Tel:+91-80-8410061/753/755 Fax:+91-80-8410063 E-mail: bodgey@in.huawei.com ------_=_NextPart_001_01C01644.FB4BED40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable A question about Request-URI:

Hi:
      I find = a difference among different versons of the draft of SIP Telephony Call Flow = Examples:  Before May 2000, = in the Request-URI of SIP INVITE, there is a address of the Pxory the = message will head, but the version after this time, there is Callee's = address the message will head.

     In section = 4.3 of RFC2543, there writes "Typically, the UAC sets the = Request-URI and TO to the same SIP URL, pesumed to remain unchanged = over long time periods", so the latter case is right. But it is = difficult to explain the following word in this section that is = "The host part of the Request-URI typically agrees with one of the = host name of the receiving server. If it does not, the sever SHOULD = proxy the request to the address indicated or return 404 response if it = is unwilling to do so".  I don't know what is meaning of the = "receiving server"? If the receiving server is a proxy = server, for the latter case, it may lead to proxy server return 404 = reponse and the call fails because the Request-URI is not the address = the Proxy server.

     = Therefore,  it is a fuzzy or an error description. we need give a = more clear description.
     Best = regards!

Bodgey = Yin
 
Engineering = Division
Huawei = Technology India Private, LTD
Tel:+91-80-8410061/753/755
Fax:+91-80-8410063
E-mail: = bodgey@in.huawei.com


------_=_NextPart_001_01C01644.FB4BED40-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Sep 4 04: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 ESMTP id EAA00899 for ; Mon, 4 Sep 2000 04:25: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 28B8444351; Mon, 4 Sep 2000 03:24:39 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id 37F9144338 for ; Mon, 4 Sep 2000 03:24:35 -0400 (EDT) Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id JAA04368; Mon, 4 Sep 2000 09:22:22 +0100 (BST) Message-ID: <39B34DAC.5AFF899F@ubiquity.net> Date: Mon, 04 Sep 2000 08:22:20 +0100 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: Hisham Khartabil , Loita.Jahnsson@uab.ericsson.se, jhornsby@ubiquity.net, sip@lists.bell-labs.com Subject: Re: [SIP] transaction identification References: <002e01c011c2$94a85000$4e34c3c1@ubiquity.co.uk> <39AC83A0.68A61CA@dynamicsoft.com> <39AE1096.95161017@uab.ericsson.se> <39AE38A0.526A55F8@ubiquity.net> <39AF4ADB.B8751B55@dynamicsoft.com> <39AF51F7.CDBFE713@ericsson.fi> <39AF563A.8EEB995@dynamicsoft.com> <39AF7E14.FE7886BB@ubiquity.net> <39B06683.FE987438@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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > Neil Deason wrote: > > > > Jonathan Rosenberg wrote: > > > [...] > > > Well, nearly as I can tell it would only be needed if there is Via > > > hiding being done. > > > > Correct. The branch param is not one of the encrypted > > components when Via hiding is performed. This means > > that if we make the branch param globally unique there > > is no longer a requirement on Proxies to try and decrypt > > all Via headers marked as hidden to perform loop detection. > > A proxy can just just recognise it's own globally unique > > branch param within any hidden Vias. > > It might be worthwhile to take a step back and examine whether or not > this kind of fix (just needed for via hiding) can rather be addressed by > ditching via hiding and doing something else entirely. I don't think its > widely implemented, and there are definintely issues with the security > model (the next hop provides the feature for you). This possible fix was not introduced just for Via hiding. The original discussion was about request retransmissions on reverse spirals when record routing is in operation. A -INV-> P1 -INV-> P2 -INV-> P1 -INV-> B A is originating UA, B is receiving UA, P1 & P2 are proxies that Record-Route. B now sends a BYE. When the P2-P1 "portion" of the BYE reaches P1, how will it distinguish that request from the initial B-P1 as the spec stands? So the idea was to change the definition of isomorphic requests to include a globally unique branch param. This also helped solve a problem with Via hiding. That said I am no fan of Via hiding and would welcome us dropping the whole thing. However, making the branch param unique is still a fix for the original problem. I note that it also helps improve general robustness. A proxy which detects a loop down the chain from where it actually happened, can use it to differentiate ACKs/CANCELs for the 1st/2nd time it saw the request. Of course this shouldn't happen unless a broken implementation up the chain failed to detect the loop itself. 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 Sep 4 05:18: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 ESMTP id FAA01340 for ; Mon, 4 Sep 2000 05:18: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 38AB644351; Mon, 4 Sep 2000 04:18:55 -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 9C8FF44338 for ; Mon, 4 Sep 2000 04:18: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 e849Imp26102; Mon, 4 Sep 2000 11:18:49 +0200 (MEST) Received: from ericsson.fi (E0080C7FA22D6.lmf.ericsson.se [131.160.30.48]) by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id MAA12801; Mon, 4 Sep 2000 12:18:48 +0300 (EET DST) Message-ID: <39B3689C.25FE6724@ericsson.fi> Date: Mon, 04 Sep 2000 12:17:16 +0300 From: Hisham Khartabil X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Neil Deason Cc: sip@lists.bell-labs.com Subject: Re: [SIP] transaction identification References: <002e01c011c2$94a85000$4e34c3c1@ubiquity.co.uk> <39AC83A0.68A61CA@dynamicsoft.com> <39AE1096.95161017@uab.ericsson.se> <39AE38A0.526A55F8@ubiquity.net> <39AF4ADB.B8751B55@dynamicsoft.com> <39AF51F7.CDBFE713@ericsson.fi> <39AF563A.8EEB995@dynamicsoft.com> <39AF7E14.FE7886BB@ubiquity.net> <39B06683.FE987438@dynamicsoft.com> <39B34DAC.5AFF899F@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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit I thought this third part of the branch id is used for a proxy to id itself, and I'm assuming it would be the same everytime. So, how does that make it unique when it comes to identifying a transaction? Here is my suggestion: The calculated branch (the hash part) the came with the INVITE would be stored as a generic-param in the Record-Route and then copied into route. The proxy would then use that to compare the BYE's (this is assuming that the legal loop detection rules where followed) what does everyone think? Regards, Hisham Neil Deason wrote: > Jonathan Rosenberg wrote: > > > > Neil Deason wrote: > > > > > > Jonathan Rosenberg wrote: > > > > > [...] > > > > Well, nearly as I can tell it would only be needed if there is Via > > > > hiding being done. > > > > > > Correct. The branch param is not one of the encrypted > > > components when Via hiding is performed. This means > > > that if we make the branch param globally unique there > > > is no longer a requirement on Proxies to try and decrypt > > > all Via headers marked as hidden to perform loop detection. > > > A proxy can just just recognise it's own globally unique > > > branch param within any hidden Vias. > > > > It might be worthwhile to take a step back and examine whether or not > > this kind of fix (just needed for via hiding) can rather be addressed by > > ditching via hiding and doing something else entirely. I don't think its > > widely implemented, and there are definintely issues with the security > > model (the next hop provides the feature for you). > > This possible fix was not introduced just for Via hiding. > The original discussion was about request retransmissions > on reverse spirals when record routing is in operation. > > A -INV-> P1 -INV-> P2 -INV-> P1 -INV-> B > > A is originating UA, B is receiving UA, P1 & P2 are proxies > that Record-Route. B now sends a BYE. When the P2-P1 "portion" > of the BYE reaches P1, how will it distinguish that request > from the initial B-P1 as the spec stands? So the idea was to > change the definition of isomorphic requests to include a > globally unique branch param. > > This also helped solve a problem with Via hiding. That said > I am no fan of Via hiding and would welcome us dropping the > whole thing. > > However, making the branch param unique is still a > fix for the original problem. I note that it also helps > improve general robustness. A proxy which detects a loop > down the chain from where it actually happened, can > use it to differentiate ACKs/CANCELs for the 1st/2nd > time it saw the request. Of course this shouldn't happen > unless a broken implementation up the chain failed to detect > the loop itself. > > 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 Sep 4 05:48: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 ESMTP id FAA01541 for ; Mon, 4 Sep 2000 05:48: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 5C81F4437C; Mon, 4 Sep 2000 04:48:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id 7745744351 for ; Mon, 4 Sep 2000 04:48:00 -0400 (EDT) Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id KAA02166; Mon, 4 Sep 2000 10:46:15 +0100 (BST) Message-ID: <39B36F63.102F31C2@ubiquity.net> Date: Mon, 04 Sep 2000 10:46:11 +0100 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: Hisham Khartabil Cc: sip@lists.bell-labs.com Subject: Re: [SIP] transaction identification References: <002e01c011c2$94a85000$4e34c3c1@ubiquity.co.uk> <39AC83A0.68A61CA@dynamicsoft.com> <39AE1096.95161017@uab.ericsson.se> <39AE38A0.526A55F8@ubiquity.net> <39AF4ADB.B8751B55@dynamicsoft.com> <39AF51F7.CDBFE713@ericsson.fi> <39AF563A.8EEB995@dynamicsoft.com> <39AF7E14.FE7886BB@ubiquity.net> <39B06683.FE987438@dynamicsoft.com> <39B34DAC.5AFF899F@ubiquity.net> <39B3689C.25FE6724@ericsson.fi> 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Hisham Khartabil wrote: > > I thought this third part of the branch id is used for a proxy to id itself, > and I'm assuming it would be the same everytime. So, how does that make it > unique when it comes to identifying a transaction? No. The new proposed third piece would be used to make the the branch ID globally unique. > Here is my suggestion: > > The calculated branch (the hash part) the came with the INVITE would be stored > as a generic-param in the Record-Route and then copied into route. The proxy > would then use that to compare the BYE's (this is assuming that the legal loop > detection rules where followed) > > what does everyone think? Not backwards compatible. Only maddr parameters are copied from the Record-Route into the Route. 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 Sep 4 12: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 ESMTP id MAA05056 for ; Mon, 4 Sep 2000 12:22: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 083AC44338; Mon, 4 Sep 2000 11:22:53 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from pc2call.com (unknown [212.187.178.58]) by lists.bell-labs.com (Postfix) with ESMTP id 61DE944337 for ; Mon, 4 Sep 2000 11:22:49 -0400 (EDT) Received: from mail.pc2call.com - 127.0.0.1 by pc2call.com with Microsoft SMTPSVC(5.5.1774.114.11); Mon, 4 Sep 2000 17:20:49 +0100 Received: from 212.187.178.62 by mail.pc2call.com ([212.187.178.58] running VPOP3) with ESMTP for ; Mon, 4 Sep 2000 17:20:49 +0100 Message-ID: <39B3CC1E.9BEAE040@switchlab.net> Date: Mon, 04 Sep 2000 17:21:50 +0100 From: Benny Prijono X-Mailer: Mozilla 4.7 [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 X-Server: VPOP3 V1.4.0b - Registered to: Switchlab Ltd Subject: [SIP] Tag in provisional response Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Hi all, Issue regarding to TAG in provisional responses: Current bis-01 draft doesn't mandate servers to add tag in provisional response for the initial INVITE request, as written in Section 6.43 (last paragraph, page 56): "These servers MAY add the tag for informational responses during the initial INVITE transaction, but MUST add a tag to informational responses for all subsequent transactions." Shouldn't it be changed to MUST, so that the client can distinguish which response goes to which server? I imagine that a GUI client will display two different feedback messages if it gets two provisional responses with different tags, so that the client/user awares that his/her call has reached two different destinations. For example, the first line is "call 1: queued, 1 person ahead" and second line is "call 2: ringing". And this is only possible if the tag is present in the provisional response. Comments? cheers, Bennylp _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Sep 4 20:30: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 ESMTP id UAA08355 for ; Mon, 4 Sep 2000 20:30: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 4F02A4433C; Mon, 4 Sep 2000 19:30:16 -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 1963C44337 for ; Mon, 4 Sep 2000 19:30:13 -0400 (EDT) Received: by mail.mediatrix.com with Internet Mail Service (5.5.2650.21) id ; Mon, 4 Sep 2000 20:23:38 -0400 Message-ID: From: Eric Tremblay To: "Robert Sparks (E-mail)" Cc: sip@lists.bell-labs.com Date: Mon, 4 Sep 2000 20:23:37 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] Possible REFER problem? Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Hi, I think I see a possible problem with the REFER request in the context of a call transfer with consultation: Suppose that Transferor and Transferee are connected. Transferor puts Transferee on hold and calls Transfer Target (TT). After the brief call between Transferor and TT, Transferor sends a REFER request to Transferee: Transferor has 2 choices for the URL to put into the Refer-To header of the REFER request. It can either use the contact it has received in the 200 response of the call with TT or it can use the original URL it has used to establish the call to TT (which usually points to a proxy or redirect server). I think that using the contact URL in the Refer-To is not the best thing to do because this could bypass some of the system policies that requires all calls to go trough a proxy (for tracing, billing or whatever services). Note that this is fixed by having TT return a 305 response to the INVITE received from Transferee, in which case Transferee should resend the INVITE to a proxy. On the other hand, when using the original URL in the Refer-To, I think it is possible that the call from Transferee to TT will be routed to a totaly different destination, probably because the proxy has forked and someone else has answered before TT could. I think the problem is as follows: How can we make sure that the INVITE from Transferee to TT will be answered by the same UA as the INVITE from Transferor to TT? I think that we want to allow some mobility to TT, but I also think that we would like to reach the exact same UA as the call between Transferor and TT. 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. First, is this really a problem or I'm forgetting something? 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 From sip-admin@lists.bell-labs.com Mon Sep 4 21:52: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 ESMTP id VAA09920 for ; Mon, 4 Sep 2000 21:52: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 D63ED4434E; Mon, 4 Sep 2000 20:51:23 -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 6B43B44338 for ; Mon, 4 Sep 2000 04:01:58 -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 e8491uw26358 for ; Mon, 4 Sep 2000 11:01:56 +0200 (MEST) Received: from uabx04c411.uab.ericsson.se.uab.ericsson.se (uabx04c411 [134.138.229.171]) by ms.uab.ericsson.se (8.10.0/8.10.0/uab-2.26) with ESMTP id e8491uL08695 for ; Mon, 4 Sep 2000 11:01:56 +0200 (MET DST) Received: from uab.ericsson.se by uabx04c411.uab.ericsson.se.uab.ericsson.se (8.8.7/client-1.3uab1) id LAA23572; Mon, 4 Sep 2000 11:01:54 +0200 (MET DST) Message-ID: <39B36501.DF71A769@uab.ericsson.se> Date: Mon, 04 Sep 2000 11:01:53 +0200 From: Bertil Engelholm Organization: Ericsson Utvecklings AB X-Mailer: Mozilla 4.7C-CCK-MCD [en] (X11; U; SunOS 5.6 sun4m) X-Accept-Language: sv,en-US MIME-Version: 1.0 To: SIP@lists.bell-labs.com Subject: Re: [SIP] transaction identification References: <002e01c011c2$94a85000$4e34c3c1@ubiquity.co.uk> <39AC83A0.68A61CA@dynamicsoft.com> <39AE1096.95161017@uab.ericsson.se> <39AE38A0.526A55F8@ubiquity.net> <39AF4ADB.B8751B55@dynamicsoft.com> <39AF51F7.CDBFE713@ericsson.fi> <39AF563A.8EEB995@dynamicsoft.com> <39AF7E14.FE7886BB@ubiquity.net> <39B06683.FE987438@dynamicsoft.com> <8oso18$r62$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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > > > This is only one of the problems. With hindsight, my other concerns > about Via hiding: > > - complexity, particularly hidden "gotchas" that surface at various > points (as in this instance); > > - interference with loop detection and debugging; > > - over-promise: unlike HTTP, where via-hiding makes some sense since all > data is in one place, Via-hiding in SIP by itself does nothing to hide > the caller. (I'm having a hard time thinking of applications where > hiding the caller doesn't matter, but where hiding a proxy does.) > There's all kind of other information leakage: > > - Contact > - Route/Record-Route > - SDP (various places, including o=, c=) > - possibly accidental leakage in User-Agent header and Call-ID, > depending on how they're generated > > Also, unless this is implemented everywhere, the feature is not likely > to be very useful, without the sender having any recourse such as "don't > route this request unless you can hide". I would guess that almost all > existing proxies simply ignore the Hide header. > > Thus, there is a danger of asking for via-hiding and then deluding > oneself that this indeed provides anonymity. > > I think we should welcome opportunities to simplify the spec by removing > marginally useful features. This was exactly what I suggested a few weeks ago. I'm glad that you also agree that we should try and remove "unnecessary" things from the specification. The things I beleave is marginally useful features which could be removed is : * The compact form. * The comma separated lists. * Line folding. There are also a number of other things I would like to remove from the protocol which does not add any functionality what so ever to the protocol. I.E : * The possibility to add extra spaces basically whereever you like. * The possibility to use upper and lower case as you like. These things are not that important to remove but since I beleave they only add unnecessary complexity without any gain at all I would prefer having them removed. /Bertil -- 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 Sep 4 21:54: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 ESMTP id VAA09950 for ; Mon, 4 Sep 2000 21:54: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 B753D44353; Mon, 4 Sep 2000 20:51:34 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id 68F9544338 for ; Mon, 4 Sep 2000 04:11:53 -0400 (EDT) Received: from phoffer by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id KAA20168; Mon, 4 Sep 2000 10:09:59 +0100 (BST) Message-ID: <009b01c0164f$fc3827e0$5334c3c1@ubiquity.co.uk> From: "Phil Hoffer" To: "Jonathan Rosenberg" Cc: References: <006701c01350$e890d090$5334c3c1@ubiquity.co.uk> <39B1DDA3.1B5D29B@dynamicsoft.com> Date: Mon, 4 Sep 2000 10:10:35 +0100 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] Re: Open issue with Quotes in WWW-Authenticate ?? Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit ----- Original Message ----- From: Jonathan Rosenberg To: Phil Hoffer Cc: Sent: Sunday, September 03, 2000 6:12 AM Subject: Re: Open issue with Quotes in WWW-Authenticate ?? > The problem is in rfc2617, which is inconsistent in the usage of quoted > strings for certain parameters, namely the uri. The BNF is clear in that > it is not quoted: > > > 3.2.2 The Authorization Request Header > > > > The client is expected to retry the request, passing an Authorization > > header line, which is defined according to the framework above, > > utilized as follows. > > > > credentials = "Digest" digest-response > > digest-response = 1#( username | realm | nonce | digest-uri > > | response | [ algorithm ] | [cnonce] | > > [opaque] | [message-qop] | > > [nonce-count] | [auth-param] ) > > > > username = "username" "=" username-value > > username-value = quoted-string > > digest-uri = "uri" "=" digest-uri-value > > digest-uri-value = request-uri ; As specified by HTTP/1.1 > > > but the examples show the uri value to be a quoted string: > > > Authorization: Digest username="Mufasa", > > realm="testrealm@host.com", > > nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", > > uri="/dir/index.html", > > qop=auth, > > nc=00000001, > > cnonce="0a4f113b", > > response="6629fae49393a05397450978507c4ef1", > > opaque="5ccc069c403ebaf9f0171e9517f40e41" > > > > So, the issue is which one to use. Common usage appears to be quoted, so > the proposal is to go with that. Hi Jonathan, My understanding was that a vote was taken at the 4th bakeoff, and it was decided that quotes MUST be used. In fact in Section 14.3 Digest Authentication in rfc2543bis, subsection 2 it talks about the inconsistency in rfc2617 and states that "For SIP, the URI MUST be enclosed in quotation marks". So it appears that this is a closed issue. From the bakeoffs, it would appear that the main areas of confusion wrt authentication appear to be the quoting of the qop parameter in the response, and the general quoting/non-quoting of the other parameters in the authetication headers. To add to the confusion the authentication headers in the SIP Telephony Call Flow Examples, draft-ietf-sip-call-flows-01.txt, are inconsistent with the rfc2543bis and rfc2617 and MUST be corrected, as they are bound to add to the confusion in their current state. Regards Phil Hoffer 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 Sep 4 21:57: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 ESMTP id VAA09966 for ; Mon, 4 Sep 2000 21:57: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 D341944358; Mon, 4 Sep 2000 20:52:00 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from email.com.cn (unknown [202.106.186.230]) by lists.bell-labs.com (Postfix) with SMTP id 3E61444337 for ; Mon, 4 Sep 2000 08:18:02 -0400 (EDT) Received: from email.com.cn([202.106.186.230]) by email.com.cn(JetMail 2.5.3.0) with SMTP id jme39b3cbbc; Mon, 4 Sep 2000 13:16:30 -0000 Received: from cs.columbia.edu([128.59.16.20]) by email.com.cn(JetMail 2.5.3.0) with SMTP id jm3139aeb4b0; Thu, 31 Aug 2000 19:15:54 -0000 Received: (from majordom@localhost) by cs.columbia.edu (8.9.3/8.9.3) id NAA16775 for sip-implementors-outgoing; Thu, 31 Aug 2000 13:00:24 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id NAA16769; Thu, 31 Aug 2000 13:00:21 -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 KAA03819; Thu, 31 Aug 2000 10:00:08 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA26234; Thu, 31 Aug 2000 09:59:50 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14766.36613.901750.929369@thomasm-u1.cisco.com> Date: Thu, 31 Aug 2000 09:59:49 -0700 (PDT) To: "James A. Donald" Cc: Michael Thomas , Henning Schulzrinne , Jonathan Rosenberg , David Harris , "Sip-Implementors (E-mail)" , sip Subject: Re: [SIP] Re: SIP gateways and authentication In-Reply-To: <4.3.1.2.20000830092306.00bbeeb0@shell11.ba.best.com> References: <39A6D968.647FBFDB@cs.columbia.edu> <89866A7EC9C0D1119C950000F8BCC282016352E9@zrtpd00n.us.nortel.com> <39A6035E.4DDC74C0@dynamicsoft.com> <14758.38134.851139.496078@thomasm-u1.cisco.com> <39A6B1C4.E424802F@cs.columbia.edu> <14758.48066.388917.988364@thomasm-u1.cisco.com> <39A6C0C3.7BEC4838@cs.columbia.edu> <14758.49815.427708.431582@thomasm-u1.cisco.com> <39A6C49E.9844FF65@cs.columbia.edu> <14758.51787.331133.132625@thomasm-u1.cisco.com> <4.3.1.2.20000830092306.00bbeeb0@shell11.ba.best.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! Precedence: bulk Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit It looks like your argument is not with the SIP WG but with the CAT WG. I'm sure a lot of folks there would be willing to entertain (or not) this argument. In particular, the assertion that that Kerberos is inherently subject to dictionary attacks looks more like an indictment against symmetric key cryptography in general, rather than Kerberos in particular. Mike James A. Donald writes: > -- > At 09:02 AM 8/30/2000 -0700, Michael Thomas wrote: > > A cross realm Kerberos based solution would be more than adequate to > > give you a high level of confidence that a piece of information came > > from the realm it claims to have come from. > > While you are correct that we should use Kerberos like security > servers, Kerberos itself is broken. It has been broken for some time. > > The problem is described in http://theory.stanford.edu/~tjw/krbpass.html, > and with the passage of time the problem becomes ever worse, due to the > increased power of offline dictionary attack hardware and software. > > A modern security system, (which kerberos is not) must only permit online > attacks on the password. Kerberos permits offline attacks. In a modern > system the attacker must only be able to test his guesses by using the > guessed password to attempt to establish a secure connection to the > security server. After some large number of consecutive failures, the > security server will temporarily disable the account, and send to the user > an insecure notification containing a log of all information about the > failed attempts. After each successful logon, the system sends the user > information about all previous failed attempts through the secure connection. > > The proposal to use PGP keys or verisign keys uses modern security > techniques to solve the wrong problem. > > The proposal to use kerberos techniques addresses the right problem in the > right way, but the particular details of the solution are obsolete. > > I propose the following EKE like solution, similar to that described in my > web page http://catalog.com/jamesd/kong/secure_video.htm > > The user establishes a secure connection with the secure personal presence > server. > > The personal presence client logs in to the personal presence server using > the name and password. The password is never revealed to the server. An > outside attacker would have to try his guessed password by attempting to > log on. If he tried lots of logons, this would become noticeable. > > The server knows, not the password p , but h(p)*G where G is an elliptic > point that the server makes known to anyone. > > When the user created his account, his client software informed the server > of h(p)*G through https. The software ensures that it gave this account > creation information only to the real server, thanks to the usual https > mechanism, which guarantees the server's true name. The server does not > need to verify the users true name. > > Lower case letters stand for very large integers, upper case letters stand > for elliptic points. h(x) means "one way hash of x " > > The object of the logon protocol is to ensure that the client program is > communicating with a server that knows h(p)*G , and the server knows it is > communicating with a client who knows h(p) In this the protocol differs > from SPEKE, where both the client and the security server both know > p. The implementors have to keep in mind the usual EKE concerns described > in http://world.std.com/~dpj/speke97.html. > > When the user logs on he sends the server his logon name in the clear, The > server generates a true random number b , and sends the user b*G . > > The client similarly generates a true random number c and sends the server c*G. > > An attacker can discover c*G, b*G, and G, but cannot calculate c or b from > this information. > > The client then generates the secret elliptic point (b*G)*[c+h(p)] > > The server similarly generates the secret elliptic point b*[(c*G)+(h(p)*G)] > , which will be equal to the point generated by the client. This elliptic > point is then used as the symmetric secret key for secure communications > between client and the security server until the user logs off. > > In order to succeed with the protocol, in order for the client to construct > a secret elliptic point equal to that of the server, it must know h(p) > corresponding to the server's h(p)*G > Of course, ultimately our objective is not secure communications with the > security server, but secure communications between any two users, and > secure communications between a user and all the various entities that are > involved in setting up his communication. > > The simplest way of solving this is the classic DH method, now patent free, > where each entity generates one true random transient public/private key > pair, which lasts the duration of a login session. Each security server > authenticates the public keys of its users and entities, and only the user > or entity knows the private key. > > This could potentially lead to a very large number of public key > operations, which are quite slow Because the keys change infrequently, > this problem can be solved by each entity caching the results of previous > public key operations. The cache is discarded when the entity logs out.. > > When Bob sends an authenticated and secure message to Ann, saying "Hi Ann, > how are things?" it would use intolerable bandwidth if that message, and > each of the various acks and nacks by various entities required to locate > Ann and set up and send the message, required a verisign style public key > signature, or pgp style public key signatue. > > Instead, for any two entities, there will be a unique DH shared secret, > constructed from each one's DH key. Each obtains the other's public DH key > from the others security server. That unique shared secret will not change > as long as both entities remain logged on to their security server. Since > each ack and nack will be sent encrypted using that unique and unchanging > shared secret, no public key operations will be needed to prove who is > sending the ack, since only the apparent author or the apparent recipient > could decrypt it or encrypt it. We have only one public key operation per > logon time per pair of entities that need to communicate securely, which > will have an insignificant bandwidth and computational cost, not several > public key operations per ack and nack, as would be required if we employed > a signature system similar to that employed by verisign or PGP. > > > --digsig > James A. Donald > 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG > i4N8MYu3lFyxRz7rj6IX3CMlEt8P5QsQNrYF+dGO > 478RouxqobjnPMPR6Cg+Lf/c/t2dukyvpj+QkrgkK > > > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Sep 4 22: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 ESMTP id WAA10056 for ; Mon, 4 Sep 2000 22:01: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 D3B2F44362; Mon, 4 Sep 2000 20:52:24 -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 7D8B844337 for ; Mon, 4 Sep 2000 12:48: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 NAA06649; Mon, 4 Sep 2000 13:44:16 -0400 (EDT) Message-ID: <39B3DF70.46752EC9@cs.columbia.edu> Date: Mon, 04 Sep 2000 13:44:16 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Neil Deason Cc: sip@lists.bell-labs.com Subject: Re: [SIP] transaction identification References: <002e01c011c2$94a85000$4e34c3c1@ubiquity.co.uk> <39AC83A0.68A61CA@dynamicsoft.com> <39AE1096.95161017@uab.ericsson.se> <39AE38A0.526A55F8@ubiquity.net> <39AF4ADB.B8751B55@dynamicsoft.com> <39AF51F7.CDBFE713@ericsson.fi> <39AF563A.8EEB995@dynamicsoft.com> <39AF7E14.FE7886BB@ubiquity.net> <39B06683.FE987438@dynamicsoft.com> <39B34DAC.5AFF899F@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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Neil Deason wrote: > > > This possible fix was not introduced just for Via hiding. > The original discussion was about request retransmissions > on reverse spirals when record routing is in operation. > > A -INV-> P1 -INV-> P2 -INV-> P1 -INV-> B > > A is originating UA, B is receiving UA, P1 & P2 are proxies > that Record-Route. B now sends a BYE. When the P2-P1 "portion" > of the BYE reaches P1, how will it distinguish that request > from the initial B-P1 as the spec stands? So the idea was to > change the definition of isomorphic requests to include a > globally unique branch param. Added to the spec. The definition of the second branch parameter was always pretty vague, including "a sequence number", which presumably would do as long as the count is across all transactions. > > This also helped solve a problem with Via hiding. That said > I am no fan of Via hiding and would welcome us dropping the > whole thing. Unless there's loud protest, it will vanish soon, so speak up if you're fond of Via hiding. > > However, making the branch param unique is still a > fix for the original problem. I note that it also helps > improve general robustness. A proxy which detects a loop > down the chain from where it actually happened, can > use it to differentiate ACKs/CANCELs for the 1st/2nd > time it saw the request. Of course this shouldn't happen > unless a broken implementation up the chain failed to detect > the loop itself. -- 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 Sep 4 22:03: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 ESMTP id WAA10088 for ; Mon, 4 Sep 2000 22:03: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 BF4C74436D; Mon, 4 Sep 2000 20:52:50 -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 DB6B744337 for ; Mon, 4 Sep 2000 19:23:45 -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 UAA21164 for ; Mon, 4 Sep 2000 20:23:43 -0400 (EDT) Message-ID: <39B43D0F.35DB92BA@cs.columbia.edu> Date: Mon, 04 Sep 2000 20:23:43 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.72 [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] REFER Referred-By syntax is broken Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit The Referred-By syntax is badly broken. It uses commas in the middle, not as a way to separate replications of the header and just lists a bunch of parameters separated by spaces. This violates the SIP extension rules, besides being a pain to parse (since it requires a special-purpose parser just for that line). This may be similar in some way to the WWW-Authenticate mess, but we don't have to replicate this here... The header should be using the normal ;parameter mechanism. -- 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 Sep 4 22:32: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 ESMTP id WAA11173 for ; Mon, 4 Sep 2000 22:32: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 DF39744343; Mon, 4 Sep 2000 21:32:11 -0400 (EDT) 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 63E244433A for ; Mon, 4 Sep 2000 21:32:08 -0400 (EDT) Received: by EXCHANGESVR with Internet Mail Service (5.5.2650.21) id ; Mon, 4 Sep 2000 19:31:51 -0700 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'Bertil Engelholm'" , SIP@lists.bell-labs.com Subject: RE: [SIP] transaction identification Date: Mon, 4 Sep 2000 19:31:50 -0700 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Bertil, There's a difference between removing marginally useless headers/features and changing the whole protocol syntax - thereby making the protocol no longer backwards compatible. There are too many SIP implementations already out there to make these changes now (even if as implementors we would like to make these simplifications). I beleive the recent discussions about simplifying the SIP syntax were suggesting that implementations SHOULD generate messages in the canonical form but still MUST still be able to parse anything (for backwards compat) - as distinct from removing these annoying elements form the protocol altogether. Regards, Robert. > > I think we should welcome opportunities to simplify the > spec by removing > > marginally useful features. > > This was exactly what I suggested a few weeks ago. I'm glad that you > also agree that we should try and remove "unnecessary" things from > the specification. The things I beleave is marginally useful features > which could be removed is : > > * The compact form. > * The comma separated lists. > * Line folding. > > There are also a number of other things I would like to remove > from the protocol which does not add any functionality what so > ever to the protocol. I.E : > > * The possibility to add extra spaces basically whereever you like. > * The possibility to use upper and lower case as you like. > > These things are not that important to remove but since I beleave > they only add unnecessary complexity without any gain at all I > would prefer having them removed. > > /Bertil > > -- > 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 Sep 4 23:02: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 ESMTP id XAA11394 for ; Mon, 4 Sep 2000 23: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 A88D744346; Mon, 4 Sep 2000 22:01:48 -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 1422344336 for ; Mon, 4 Sep 2000 22:01:45 -0400 (EDT) Received: from dynamicsoft.com (1Cust235.tnt1.freehold.nj.da.uu.net [63.17.113.235]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id XAA02070; Mon, 4 Sep 2000 23:03:19 -0400 (EDT) Message-ID: <39B461DC.CFA76D5A@dynamicsoft.com> Date: Mon, 04 Sep 2000 23:00:44 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Benny Prijono Cc: "sip@lists.bell-labs.com" Subject: Re: [SIP] Tag in provisional response References: <39B3CC1E.9BEAE040@switchlab.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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Best we can really do is SHOULD. MUST doesn't help you since its not compatible with rfc2543 in that case. -Jonathan R. Benny Prijono wrote: > > Hi all, > > Issue regarding to TAG in provisional responses: > > Current bis-01 draft doesn't mandate servers to add tag in provisional > response for the initial INVITE request, as written in Section 6.43 > (last paragraph, page 56): > > "These servers MAY add the tag for informational responses during > the initial INVITE transaction, but MUST add a tag to informational > responses for all subsequent transactions." > > Shouldn't it be changed to MUST, so that the client can distinguish > which response goes to which server? I imagine that a GUI client will > display two different feedback messages if it gets two provisional > responses with different tags, so that the client/user awares that > his/her call has reached two different destinations. For example, the > first line is "call 1: queued, 1 person ahead" and second line is > "call 2: ringing". And this is only possible if the tag is present in > the provisional response. > > Comments? > > cheers, > Bennylp > > _______________________________________________ > 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: (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 Mon Sep 4 23:04: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 ESMTP id XAA11447 for ; Mon, 4 Sep 2000 23:04: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 8B8B144353; Mon, 4 Sep 2000 22:03:28 -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 66C0944348 for ; Mon, 4 Sep 2000 22:03:25 -0400 (EDT) Received: from dynamicsoft.com (1Cust235.tnt1.freehold.nj.da.uu.net [63.17.113.235]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id XAA02062; Mon, 4 Sep 2000 23:01:24 -0400 (EDT) Message-ID: <39B46168.83C15332@dynamicsoft.com> Date: Mon, 04 Sep 2000 22:58:48 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Eric Tremblay Cc: "Robert Sparks (E-mail)" , sip@lists.bell-labs.com Subject: Re: [SIP] Possible REFER problem? 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Eric Tremblay wrote: > > I think that using the contact URL in the Refer-To is not the best thing to > do because this could bypass some of the system policies that requires all > calls to go trough a proxy (for tracing, billing or whatever services). > Note that this is fixed by having TT return a 305 response to the INVITE > received from Transferee, in which case Transferee should resend the INVITE > to a proxy. Correct. It should not use the Contact URL. > > On the other hand, when using the original URL in the Refer-To, I think it > is possible that the call from Transferee to TT will be routed to a totaly > different destination, probably because the proxy has forked and someone > else has answered before TT could. No. It would not be routed to a "totally" different location. Forking in SIP is not meant to be a randomization process; its meant to be a means of finding the user where they are currently available. In a reasonable SIP system, if they are available at some destination for a first call, a second call should be able to "ring" that same phone as well. > > 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. > > First, is this really a problem or I'm forgetting something? I do not believe it is a real 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: (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 Mon Sep 4 23:28: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 ESMTP id XAA11554 for ; Mon, 4 Sep 2000 23:28: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 BEF7A4434E; Mon, 4 Sep 2000 22:28:30 -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 984BB44336 for ; Mon, 4 Sep 2000 22:28:25 -0400 (EDT) Received: from dynamicsoft.com (1Cust235.tnt1.freehold.nj.da.uu.net [63.17.113.235]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id XAA02158; Mon, 4 Sep 2000 23:27:49 -0400 (EDT) Message-ID: <39B4679A.2F10020E@dynamicsoft.com> Date: Mon, 04 Sep 2000 23:25:14 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Bodgey Yin Shaohua Cc: sip@lists.bell-labs.com Subject: Re: [SIP] A question about Request-URI: References: <30B58D519274D41187630050BAD918AF07386F@mail.in.huawei.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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit > Bodgey Yin Shaohua wrote: > > Hi: > I find a difference among different versons of the draft of SIP > Telephony Call Flow Examples: Before May 2000, in the Request-URI of > SIP INVITE, there is a address of the Pxory the message will head, but > the version after this time, there is Callee's address the message > will head. > > In section 4.3 of RFC2543, there writes "Typically, the UAC sets > the Request-URI and TO to the same SIP URL, pesumed to remain > unchanged over long time periods", so the latter case is right. But it > is difficult to explain the following word in this section that is > "The host part of the Request-URI typically agrees with one of the > host name of the receiving server. If it does not, the sever SHOULD > proxy the request to the address indicated or return 404 response if > it is unwilling to do so". I don't know what is meaning of the > "receiving server"? Its the server that receives the request. Perhaps an example will illustrate. Lets say I am making a call to joe@example.com. I would send an INVITE that looks like: INVITE sip:joe@example.com SIP/2.0 To: sip:joe@example.com Now, in one case, I will take example.com, look it up in DNS, and send it to the IP address of a server I discover through this process. The example.com server receives the request (it is the receiving server here). Now, the host part of the request-URI (example.com) matches to domain of that server (also example.com), so it knows how to handle requests for this domain. In another case, I am using a local outboud proxy at dynamicsoft.com. So, instead of sending the above request there, I send it to the IP address of the dynamicsoft.com proxy, which my UAC is configured with. Now, for this proxy, the domain of the request URI (example.com) does not match the domain of the receiving serer (dynamicsoft.com). So, the proxy can either forward it to example.com, or reject it with 404. -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 Mon Sep 4 23:32: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 ESMTP id XAA11989 for ; Mon, 4 Sep 2000 23:32: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 42A1A4434A; Mon, 4 Sep 2000 22:32:40 -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 2D97344344 for ; Mon, 4 Sep 2000 22:32:37 -0400 (EDT) Received: from dynamicsoft.com (1Cust235.tnt1.freehold.nj.da.uu.net [63.17.113.235]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id XAA02170; Mon, 4 Sep 2000 23:34:15 -0400 (EDT) Message-ID: <39B4691B.91BA28BB@dynamicsoft.com> Date: Mon, 04 Sep 2000 23:31:39 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: farhan Cc: sip Subject: Re: [SIP] Re: SIP feature services References: <001001c0155e$f08dae20$0b14c5cb@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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit farhan wrote: > > the only problem with using http/html forms for prompting and display is > that we will be making sip dependent upon another 'bag' - an html browser is > a pretty huge thing. it will also be difficult to implement one in all its > glory on the phone devices (witness the buzz/noise being made for WAP). > there are both sides to this issue. No one said an HTML renderer was needed. Nothing is wrong with text/plain or application/wxml. Thats what our MIME headers are for: INVITE sip:user@host SIP/2.0 Accept: text/plain, application/sdp > > 1. it is a lazy sip programmers ideal solution to hand over > display/prompting to http. Lazy is not the right word here. We have an extensive system for transferrance of content, both simple and rich. I don't want to reinvent that based on a notion of "greater simplicity through reinventing the wheel". You can do a minimal http client stack very easily. > The issue is therefore, do we make web browsing a complusory facility to be > available alongside a sip UA? Compulsory? No. Thats the beauty here - we can figure out what type of content the caller can support. With the Caller preferences extension to SIP, we can even figure out what URL schemes they can be redirected to. This allows applications to be built that deliver the rich content to full blown PC phones, and do more limited stuff to more limited devices. -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 Mon Sep 4 23:46: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 ESMTP id XAA12149 for ; Mon, 4 Sep 2000 23:46: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 97A3844365; Mon, 4 Sep 2000 22:45:32 -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 107894433A for ; Mon, 4 Sep 2000 22:45:29 -0400 (EDT) Received: from dynamicsoft.com (1Cust235.tnt1.freehold.nj.da.uu.net [63.17.113.235]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id XAA02183; Mon, 4 Sep 2000 23:43:30 -0400 (EDT) Message-ID: <39B46B47.5582895@dynamicsoft.com> Date: Mon, 04 Sep 2000 23:40:55 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Henning Schulzrinne Cc: Neil Deason , sip@lists.bell-labs.com Subject: Re: [SIP] transaction identification References: <002e01c011c2$94a85000$4e34c3c1@ubiquity.co.uk> <39AC83A0.68A61CA@dynamicsoft.com> <39AE1096.95161017@uab.ericsson.se> <39AE38A0.526A55F8@ubiquity.net> <39AF4ADB.B8751B55@dynamicsoft.com> <39AF51F7.CDBFE713@ericsson.fi> <39AF563A.8EEB995@dynamicsoft.com> <39AF7E14.FE7886BB@ubiquity.net> <39B06683.FE987438@dynamicsoft.com> <39B34DAC.5AFF899F@ubiquity.net> <39B3DF70.46752EC9@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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > > Neil Deason wrote: > > > > > > > This possible fix was not introduced just for Via hiding. > > The original discussion was about request retransmissions > > on reverse spirals when record routing is in operation. > > > > A -INV-> P1 -INV-> P2 -INV-> P1 -INV-> B > > > > A is originating UA, B is receiving UA, P1 & P2 are proxies > > that Record-Route. B now sends a BYE. When the P2-P1 "portion" > > of the BYE reaches P1, how will it distinguish that request > > from the initial B-P1 as the spec stands? So the idea was to > > change the definition of isomorphic requests to include a > > globally unique branch param. > > Added to the spec. The definition of the second branch parameter was > always pretty vague, including "a sequence number", which presumably > would do as long as the count is across all transactions. Just to be clear here; the discussion to date of having a third component that is globally unique is going to be folded into the second component. That component was used for the actual "branch" identification - if a proxy forks, and the response comes, for which forked request is the response? So, a globally unique ID will be used here instead of a simple sequence number that resets for each transaction. -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 Mon Sep 4 23:48: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 ESMTP id XAA12160 for ; Mon, 4 Sep 2000 23:48: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 3D83A4436E; Mon, 4 Sep 2000 22:47:59 -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 B84C144367 for ; Mon, 4 Sep 2000 22:47:55 -0400 (EDT) Received: from dynamicsoft.com (1Cust235.tnt1.freehold.nj.da.uu.net [63.17.113.235]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id XAA02187; Mon, 4 Sep 2000 23:46:55 -0400 (EDT) Message-ID: <39B46C14.5D921D73@dynamicsoft.com> Date: Mon, 04 Sep 2000 23:44:20 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Neil Deason Cc: Hisham Khartabil , sip@lists.bell-labs.com Subject: Re: [SIP] transaction identification References: <002e01c011c2$94a85000$4e34c3c1@ubiquity.co.uk> <39AC83A0.68A61CA@dynamicsoft.com> <39AE1096.95161017@uab.ericsson.se> <39AE38A0.526A55F8@ubiquity.net> <39AF4ADB.B8751B55@dynamicsoft.com> <39AF51F7.CDBFE713@ericsson.fi> <39AF563A.8EEB995@dynamicsoft.com> <39AF7E14.FE7886BB@ubiquity.net> <39B06683.FE987438@dynamicsoft.com> <39B34DAC.5AFF899F@ubiquity.net> <39B3689C.25FE6724@ericsson.fi> <39B36F63.102F31C2@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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Neil Deason wrote: > > Hisham Khartabil wrote: > > > > I thought this third part of the branch id is used for a proxy to id itself, > > and I'm assuming it would be the same everytime. So, how does that make it > > unique when it comes to identifying a transaction? > > No. The new proposed third piece would be used to make the > the branch ID globally unique. > > > Here is my suggestion: > > > > The calculated branch (the hash part) the came with the INVITE would be stored > > as a generic-param in the Record-Route and then copied into route. The proxy > > would then use that to compare the BYE's (this is assuming that the legal loop > > detection rules where followed) > > > > what does everyone think? > > Not backwards compatible. Only maddr parameters are copied > from the Record-Route into the Route. maddr is a URI parameter. All URI parameters should be copied, not just those. As for record-route parameters, rfc2543 says: > The calling user agent client copies the Record-Route header into a > Route header field of subsequent requests within the same call leg, > reversing the order of requests, so that the first entry is closest > to the user agent client. to me, this would indicate that this includes record-route header parameters as well. That aside, this isn't backwards compatible because the UAs don't copy Via parameters into 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: (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 Sep 5 01:18: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 ESMTP id BAA13907 for ; Tue, 5 Sep 2000 01:18: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 EC3534433B; Tue, 5 Sep 2000 00:17:32 -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 7A27844336 for ; Tue, 5 Sep 2000 00:16:39 -0400 (EDT) Received: by mail.in.huawei.com with Internet Mail Service (5.5.2650.21) id ; Tue, 5 Sep 2000 10:48:22 +0530 Message-ID: <30B58D519274D41187630050BAD918AF073A5C@mail.in.huawei.com> From: Bodgey Yin Shaohua To: Jonathan Rosenberg Cc: SIP@lists.bell-labs.com Subject: RE: [SIP] A question about Request-URI: Date: Tue, 5 Sep 2000 10:48:16 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C016F8.B566C9D0" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com 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_01C016F8.B566C9D0 Content-Type: text/plain; charset="iso-8859-1" Hi,Jonathan: Thank you for your reply.But I also have a puzzle according to your answer. Let take a example of a successful call flow. (The section 3.1.2 of draft-ietf-sip-call-flows-01a.txt) User A Proxy 1 Proxy 2 User B | | | | | INVITE F1 | | | |--------------->| | | | 407 F2 | | | |<---------------| | | | ACK F3 | | | |--------------->| | | | INVITE F4 | | | |--------------->| INVITE F5 | | | (100) F6 |--------------->| INVITE F7 | |<---------------| (100) F8 |--------------->| | |<---------------| | The F4 is : INVITE sip:UserB@there.com SIP/2.0 To: LittleGuy Via: SIP/2.0/UDP here.com:5060 The F5 is: INVITE sip:UserB@there.com SIP/2.0 To: LittleGuy Via: SIP/2.0/UDP ss1.wcom.com:5060;branch=2d4790.1 Via: SIP/2.0/UDP here.com:5060 The F7 is: INVITE sip:UserB@there.com SIP/2.0 To: LittleGuy Via: SIP/2.0/UDP ss2.wcom.com:5060;branch=721e418c4.1 Via: SIP/2.0/UDP ss1.wcom.com:5060;branch=2d4790.1 Via: SIP/2.0/UDP here.com:5060 The Proxy1 and Proxy2 have different host from the there.com, so it may proxy the message to there.com as indicated in the figure. Or, it may reject the message with 404 response, so the Call is not successful. In the early version of the Call flow, the Request-URI is the Proxy's address (ss1.wcom.com for F4 and ss2.wcom.com for F5) which is right according to your explaining. So I don't which condition is right? If we choose a situation, the RFC2543 may change somewhat in order to give clear contradiction. Please check it. Best regards! Bodgey > Bodgey Yin Shaohua wrote: > > Hi: > I find a difference among different versons of the draft of SIP > Telephony Call Flow Examples: Before May 2000, in the Request-URI of > SIP INVITE, there is a address of the Pxory the message will head, but > the version after this time, there is Callee's address the message > will head. > > In section 4.3 of RFC2543, there writes "Typically, the UAC sets > the Request-URI and TO to the same SIP URL, pesumed to remain > unchanged over long time periods", so the latter case is right. But it > is difficult to explain the following word in this section that is > "The host part of the Request-URI typically agrees with one of the > host name of the receiving server. If it does not, the sever SHOULD > proxy the request to the address indicated or return 404 response if > it is unwilling to do so". I don't know what is meaning of the > "receiving server"? Its the server that receives the request. Perhaps an example will illustrate. Lets say I am making a call to joe@example.com. I would send an INVITE that looks like: INVITE sip:joe@example.com SIP/2.0 To: sip:joe@example.com Now, in one case, I will take example.com, look it up in DNS, and send it to the IP address of a server I discover through this process. The example.com server receives the request (it is the receiving server here). Now, the host part of the request-URI (example.com) matches to domain of that server (also example.com), so it knows how to handle requests for this domain. In another case, I am using a local outboud proxy at dynamicsoft.com. So, instead of sending the above request there, I send it to the IP address of the dynamicsoft.com proxy, which my UAC is configured with. Now, for this proxy, the domain of the request URI (example.com) does not match the domain of the receiving serer (dynamicsoft.com). So, the proxy can either forward it to example.com, or reject it with 404. -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 ------_=_NextPart_001_01C016F8.B566C9D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [SIP] A question about Request-URI:

Hi,Jonathan:
    Thank you for your reply.But I = also have a puzzle according to your answer. Let take a example of a = successful call flow. (The section 3.1.2 of = draft-ietf-sip-call-flows-01a.txt)

   User = A          Proxy = 1          Proxy = 2          User B
     = |            = ;    = |            = ;    = |            = ;    |
     |   INVITE = F1    = |            = ;    = |            = ;    |
     = |--------------->|        &nb= sp;       = |            = ;    |
     |     = 407 F2     = |            = ;    = |            = ;    |
     = |<---------------|        &nb= sp;       = |            = ;    |
     |     = ACK F3     = |            = ;    = |            = ;    |
     = |--------------->|        &nb= sp;       = |            = ;    |
     |   INVITE = F4    = |            = ;    = |            = ;    |
     = |--------------->|   INVITE F5    = |            = ;    |
     |    (100) = F6    |--------------->|   INVITE = F7    |
     = |<---------------|    (100) F8    = |--------------->|
     = |            = ;    = |<---------------|        &nb= sp;       |

 The F4 is :
   INVITE sip:UserB@there.com = SIP/2.0
   To: LittleGuy = <sip:UserB@there.com>
   Via: SIP/2.0/UDP here.com:5060

 The F5 is:
   INVITE sip:UserB@there.com = SIP/2.0
   To: LittleGuy = <sip:UserB@there.com>
   Via: SIP/2.0/UDP = ss1.wcom.com:5060;branch=3D2d4790.1
   Via: SIP/2.0/UDP here.com:5060

 The F7 is:
   INVITE sip:UserB@there.com = SIP/2.0
   To: LittleGuy = <sip:UserB@there.com>
   Via: SIP/2.0/UDP = ss2.wcom.com:5060;branch=3D721e418c4.1
   Via: SIP/2.0/UDP = ss1.wcom.com:5060;branch=3D2d4790.1
   Via: SIP/2.0/UDP here.com:5060

   The Proxy1 and Proxy2 have different = host from the there.com, so it may proxy the message to there.com as = indicated in the figure. Or, it may reject the message with 404 = response, so the Call is not successful. 

   In the early version of the Call flow, = the Request-URI is the Proxy's address (ss1.wcom.com for F4 and = ss2.wcom.com for F5) which is right according to your explaining. =

   So I don't which condition is right? If = we choose a situation, the RFC2543 may change somewhat in order to give = clear contradiction.

   Please check it.
   Best regards!
 
Bodgey

> Bodgey Yin Shaohua wrote:
>
> Hi:
>       I find a = difference among different versons of the draft of SIP
> Telephony Call Flow Examples:  Before May = 2000, in the Request-URI of
> SIP INVITE, there is a address of the Pxory the = message will head, but
> the version after this time, there is Callee's = address the message
> will head.
>
>      In section 4.3 of = RFC2543, there writes "Typically, the UAC sets
> the Request-URI and TO to the same SIP URL, = pesumed to remain
> unchanged over long time periods", so the = latter case is right. But it
> is difficult to explain the following word in = this section that is
> "The host part of the Request-URI = typically agrees with one of the
> host name of the receiving server. If it does = not, the sever SHOULD
> proxy the request to the address indicated or = return 404 response if
> it is unwilling to do so".  I don't = know what is meaning of the
> "receiving server"?

Its the server that receives the request.

Perhaps an example will illustrate. Lets say I am = making a call to
joe@example.com. I would send an INVITE that looks = like:

INVITE sip:joe@example.com SIP/2.0
To: sip:joe@example.com

Now, in one case, I will take example.com, look it up = in DNS, and send
it to the IP address of a server I discover through = this process. The
example.com server receives the request (it is the = receiving server
here). Now, the host part of the request-URI = (example.com) matches to
domain of that server (also example.com), so it = knows how to handle
requests for this domain.

In another case, I am using a local outboud proxy at = dynamicsoft.com.
So, instead of sending the above request there, I = send it to the IP
address of the dynamicsoft.com proxy, which my UAC = is configured with.
Now, for this proxy, the domain of the request URI = (example.com) does
not match the domain of the receiving serer = (dynamicsoft.com). So, the
proxy can either forward it to example.com, or = reject it with 404.

-Jonathan R.

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


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

------_=_NextPart_001_01C016F8.B566C9D0-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Sep 5 01:23: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 ESMTP id BAA14369 for ; Tue, 5 Sep 2000 01:23: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 2D16C44355; Tue, 5 Sep 2000 00:23:11 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from proxy2.ba.best.com (proxy2.ba.best.com [206.184.139.14]) by lists.bell-labs.com (Postfix) with ESMTP id 3DB0544345 for ; Tue, 5 Sep 2000 00:23:07 -0400 (EDT) Received: from amd.echeque.com (jamesd.vip.best.com [204.156.153.125]) by proxy2.ba.best.com (8.9.3/8.9.2/best.out) with ESMTP id WAA25000; Mon, 4 Sep 2000 22:22:43 -0700 (PDT) Message-Id: <4.3.1.2.20000904221628.0300a038@shell11.ba.best.com> X-Sender: jamesd@shell11.ba.best.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Mon, 04 Sep 2000 22:20:40 -0700 To: Henning Schulzrinne , Michael Thomas From: "James A. Donald" Subject: Re: [SIP] Re: SIP gateways and authentication Cc: Jonathan Rosenberg , David Harris , sip In-Reply-To: <39AE728D.AE5AAF81@cs.columbia.edu> References: <89866A7EC9C0D1119C950000F8BCC282016352E9@zrtpd00n.us.nortel.com> <39A6035E.4DDC74C0@dynamicsoft.com> <14758.38134.851139.496078@thomasm-u1.cisco.com> <39A6B1C4.E424802F@cs.columbia.edu> <14758.48066.388917.988364@thomasm-u1.cisco.com> <39A6C0C3.7BEC4838@cs.columbia.edu> <14758.49815.427708.431582@thomasm-u1.cisco.com> <39A6C49E.9844FF65@cs.columbia.edu> <14758.51787.331133.132625@thomasm-u1.cisco.com> <39A6D968.647FBFDB@cs.columbia.edu> <14765.12335.868273.287866@thomasm-u1.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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com -- At 10:58 AM 8/31/2000 -0400, Henning Schulzrinne wrote: > That said, Basic/Digest (and the other mechanisms) have the > advantage that they work using either no infrastructure (for > Basic/Digest) or existing infrastructure (company or > domain-name-based certs). But existing infrastructure is close non-existent. Further, any system that uses external authentication is going to be a pain. The users are still going to need passwords and accounts, and then they will need to somehow create a mapping between the identity provided by the external system, and the identity provided by passwords and accounts. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG Lnv4Xqow/SrLQBLy9Zsgi1mP0lyd3vJuHCQe7Gc/ 4B/GAaUW8T9qoYXG2ML4lysggFXszPJkTRhQ/wNvM _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Sep 5 01: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 ESMTP id BAA14696 for ; Tue, 5 Sep 2000 01: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 0C44B44361; Tue, 5 Sep 2000 00:25:08 -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 212A944358 for ; Tue, 5 Sep 2000 00:25:04 -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 e855P1w07743; Tue, 5 Sep 2000 07:25:01 +0200 (MEST) Received: from ericsson.fi (E0080C7FA22D6.lmf.ericsson.se [131.160.30.48]) by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id IAA01931; Tue, 5 Sep 2000 08:25:00 +0300 (EET DST) Message-ID: <39B4834F.483DDA6B@ericsson.fi> Date: Tue, 05 Sep 2000 08:23:27 +0300 From: Hisham Khartabil X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: sip@lists.bell-labs.com Subject: Re: [SIP] transaction identification References: <002e01c011c2$94a85000$4e34c3c1@ubiquity.co.uk> <39AC83A0.68A61CA@dynamicsoft.com> <39AE1096.95161017@uab.ericsson.se> <39AE38A0.526A55F8@ubiquity.net> <39AF4ADB.B8751B55@dynamicsoft.com> <39AF51F7.CDBFE713@ericsson.fi> <39AF563A.8EEB995@dynamicsoft.com> <39AF7E14.FE7886BB@ubiquity.net> <39B06683.FE987438@dynamicsoft.com> <39B34DAC.5AFF899F@ubiquity.net> <39B3689C.25FE6724@ericsson.fi> <39B36F63.102F31C2@ubiquity.net> <39B46C14.5D921D73@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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit I apologise if I didn't make myself clear. The suggestion was for the proxy itself to put a copy of the calculated branch into the record-route, not the UA. The UA copies the record-route into route, the branch is copied in the process. Jonathan Rosenberg wrote: > Neil Deason wrote: > > > > Hisham Khartabil wrote: > > > > > > I thought this third part of the branch id is used for a proxy to id itself, > > > and I'm assuming it would be the same everytime. So, how does that make it > > > unique when it comes to identifying a transaction? > > > > No. The new proposed third piece would be used to make the > > the branch ID globally unique. > > > > > Here is my suggestion: > > > > > > The calculated branch (the hash part) the came with the INVITE would be stored > > > as a generic-param in the Record-Route and then copied into route. The proxy > > > would then use that to compare the BYE's (this is assuming that the legal loop > > > detection rules where followed) > > > > > > what does everyone think? > > > > Not backwards compatible. Only maddr parameters are copied > > from the Record-Route into the Route. > > maddr is a URI parameter. All URI parameters should be copied, not just > those. > > As for record-route parameters, rfc2543 says: > > > The calling user agent client copies the Record-Route header into a > > Route header field of subsequent requests within the same call leg, > > reversing the order of requests, so that the first entry is closest > > to the user agent client. > > to me, this would indicate that this includes record-route header > parameters as well. > > That aside, this isn't backwards compatible because the UAs don't copy > Via parameters into 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: (732) 741-7244 > 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 Sep 5 02:10: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 ESMTP id CAA25187 for ; Tue, 5 Sep 2000 02: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 25F9D44352; Tue, 5 Sep 2000 01:09:43 -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 3715044336 for ; Tue, 5 Sep 2000 01:09: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 e8569Yw23568; Tue, 5 Sep 2000 08:09:34 +0200 (MEST) Received: from ericsson.fi (E0080C7FA22D6.lmf.ericsson.se [131.160.30.48]) by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id JAA05073; Tue, 5 Sep 2000 09:09:33 +0300 (EET DST) Message-ID: <39B48DC0.60E96959@ericsson.fi> Date: Tue, 05 Sep 2000 09:08:00 +0300 From: Hisham Khartabil X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Bodgey Yin Shaohua Cc: SIP@lists.bell-labs.com Subject: Re: [SIP] A question about Request-URI: References: <30B58D519274D41187630050BAD918AF073A5C@mail.in.huawei.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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit The authors of the call flows draft where under the misconception that the request-uri has to have the proxy server address in the host part. This was corrected in later releases. If a proxy server receives a request with the host part matching it domain, you handle the request by, for example, tooking up registrations (in the registrar) for that user-name. If no registrations are found, a 404 is returned, otherwise, the request is forwarded to the address found in the registrar. If a proxy server recieves a request with the host part NOT matching its domain, the server will just forward the request to the host specified in the request-uri WITHOUT modifying the request-uri. Regards, Hisham Bodgey Yin Shaohua wrote: > > > Hi,Jonathan: > Thank you for your reply.But I also have a puzzle according to > your answer. Let take a example of a successful call flow. (The > section 3.1.2 of draft-ietf-sip-call-flows-01a.txt) > > User A Proxy 1 Proxy 2 User B > | | | | > | INVITE F1 | | | > |--------------->| | | > | 407 F2 | | | > |<---------------| | | > | ACK F3 | | | > |--------------->| | | > | INVITE F4 | | | > |--------------->| INVITE F5 | | > | (100) F6 |--------------->| INVITE F7 | > |<---------------| (100) F8 |--------------->| > | |<---------------| | > > The F4 is : > INVITE sip:UserB@there.com SIP/2.0 > To: LittleGuy > Via: SIP/2.0/UDP here.com:5060 > > The F5 is: > INVITE sip:UserB@there.com SIP/2.0 > To: LittleGuy > Via: SIP/2.0/UDP ss1.wcom.com:5060;branch=2d4790.1 > Via: SIP/2.0/UDP here.com:5060 > > The F7 is: > INVITE sip:UserB@there.com SIP/2.0 > To: LittleGuy > Via: SIP/2.0/UDP ss2.wcom.com:5060;branch=721e418c4.1 > Via: SIP/2.0/UDP ss1.wcom.com:5060;branch=2d4790.1 > Via: SIP/2.0/UDP here.com:5060 > > The Proxy1 and Proxy2 have different host from the there.com, so it > may proxy the message to there.com as indicated in the figure. Or, it > may reject the message with 404 response, so the Call is not > successful. > > In the early version of the Call flow, the Request-URI is the > Proxy's address (ss1.wcom.com for F4 and ss2.wcom.com for F5) which is > right according to your explaining. > > So I don't which condition is right? If we choose a situation, the > RFC2543 may change somewhat in order to give clear contradiction. > > Please check it. > Best regards! > > Bodgey > > > Bodgey Yin Shaohua wrote: > > > > Hi: > > I find a difference among different versons of the draft of > SIP > > Telephony Call Flow Examples: Before May 2000, in the Request-URI > of > > SIP INVITE, there is a address of the Pxory the message will head, > but > > the version after this time, there is Callee's address the message > > will head. > > > > In section 4.3 of RFC2543, there writes "Typically, the UAC > sets > > the Request-URI and TO to the same SIP URL, pesumed to remain > > unchanged over long time periods", so the latter case is right. But > it > > is difficult to explain the following word in this section that is > > "The host part of the Request-URI typically agrees with one of the > > host name of the receiving server. If it does not, the sever SHOULD > > proxy the request to the address indicated or return 404 response if > > > it is unwilling to do so". I don't know what is meaning of the > > "receiving server"? > > Its the server that receives the request. > > Perhaps an example will illustrate. Lets say I am making a call to > joe@example.com. I would send an INVITE that looks like: > > INVITE sip:joe@example.com SIP/2.0 > To: sip:joe@example.com > > Now, in one case, I will take example.com, look it up in DNS, and send > > it to the IP address of a server I discover through this process. The > example.com server receives the request (it is the receiving server > here). Now, the host part of the request-URI (example.com) matches to > domain of that server (also example.com), so it knows how to handle > requests for this domain. > > In another case, I am using a local outboud proxy at dynamicsoft.com. > So, instead of sending the above request there, I send it to the IP > address of the dynamicsoft.com proxy, which my UAC is configured with. > > Now, for this proxy, the domain of the request URI (example.com) does > not match the domain of the receiving serer (dynamicsoft.com). So, the > > proxy can either forward it to example.com, or reject it with 404. > > -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 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Sep 5 03:53: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 ESMTP id DAA25815 for ; Tue, 5 Sep 2000 03:53: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 44ABA4433B; Tue, 5 Sep 2000 02:53:04 -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 A91F444336 for ; Tue, 5 Sep 2000 02:52:29 -0400 (EDT) Received: by mail.in.huawei.com with Internet Mail Service (5.5.2650.21) id ; Tue, 5 Sep 2000 13:23:58 +0530 Message-ID: <30B58D519274D41187630050BAD918AF073AD4@mail.in.huawei.com> From: Bodgey Yin Shaohua To: Hisham Khartabil , jdrosen@dynamicsoft.com Cc: SIP@lists.bell-labs.com Subject: RE: [SIP] A question about Request-URI: Date: Tue, 5 Sep 2000 13:23:55 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0170E.71AA00B0" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com 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_01C0170E.71AA00B0 Content-Type: text/plain; charset="iso-8859-1" Hi, Hisham: It is a good interpretation. If so, RFC2543 need describe it more clear. When a Server proxy a message WITHOUT modifying the request-uri, The problem how to select a best route to proxy the message in order to let it go to the destination more directly is worth considering. For instance, in the following example, why the Proxy1 don't proxy the message to there.com directly but to Proxy2? It need a reasoned interpretation. Best regards! Bodgey -----Original Message----- From: Hisham Khartabil [mailto:hisham.khartabil@lmf.ericsson.se] Sent: Monday, September 04, 2000 11:08 PM To: Bodgey Yin Shaohua Cc: SIP@lists.bell-labs.com Subject: Re: [SIP] A question about Request-URI: The authors of the call flows draft where under the misconception that the request-uri has to have the proxy server address in the host part. This was corrected in later releases. If a proxy server receives a request with the host part matching it domain, you handle the request by, for example, tooking up registrations (in the registrar) for that user-name. If no registrations are found, a 404 is returned, otherwise, the request is forwarded to the address found in the registrar. If a proxy server recieves a request with the host part NOT matching its domain, the server will just forward the request to the host specified in the request-uri WITHOUT modifying the request-uri. Regards, Hisham Bodgey Yin Shaohua wrote: > > > Hi,Jonathan: > Thank you for your reply.But I also have a puzzle according to > your answer. Let take a example of a successful call flow. (The > section 3.1.2 of draft-ietf-sip-call-flows-01a.txt) > > User A Proxy 1 Proxy 2 User B > | | | | > | INVITE F1 | | | > |--------------->| | | > | 407 F2 | | | > |<---------------| | | > | ACK F3 | | | > |--------------->| | | > | INVITE F4 | | | > |--------------->| INVITE F5 | | > | (100) F6 |--------------->| INVITE F7 | > |<---------------| (100) F8 |--------------->| > | |<---------------| | > > The F4 is : > INVITE sip:UserB@there.com SIP/2.0 > To: LittleGuy > Via: SIP/2.0/UDP here.com:5060 > > The F5 is: > INVITE sip:UserB@there.com SIP/2.0 > To: LittleGuy > Via: SIP/2.0/UDP ss1.wcom.com:5060;branch=2d4790.1 > Via: SIP/2.0/UDP here.com:5060 > > The F7 is: > INVITE sip:UserB@there.com SIP/2.0 > To: LittleGuy > Via: SIP/2.0/UDP ss2.wcom.com:5060;branch=721e418c4.1 > Via: SIP/2.0/UDP ss1.wcom.com:5060;branch=2d4790.1 > Via: SIP/2.0/UDP here.com:5060 > > The Proxy1 and Proxy2 have different host from the there.com, so it > may proxy the message to there.com as indicated in the figure. Or, it > may reject the message with 404 response, so the Call is not > successful. > > In the early version of the Call flow, the Request-URI is the > Proxy's address (ss1.wcom.com for F4 and ss2.wcom.com for F5) which is > right according to your explaining. > > So I don't which condition is right? If we choose a situation, the > RFC2543 may change somewhat in order to give clear contradiction. > > Please check it. > Best regards! > > Bodgey > > > Bodgey Yin Shaohua wrote: > > > > Hi: > > I find a difference among different versons of the draft of > SIP > > Telephony Call Flow Examples: Before May 2000, in the Request-URI > of > > SIP INVITE, there is a address of the Pxory the message will head, > but > > the version after this time, there is Callee's address the message > > will head. > > > > In section 4.3 of RFC2543, there writes "Typically, the UAC > sets > > the Request-URI and TO to the same SIP URL, pesumed to remain > > unchanged over long time periods", so the latter case is right. But > it > > is difficult to explain the following word in this section that is > > "The host part of the Request-URI typically agrees with one of the > > host name of the receiving server. If it does not, the sever SHOULD > > proxy the request to the address indicated or return 404 response if > > > it is unwilling to do so". I don't know what is meaning of the > > "receiving server"? > > Its the server that receives the request. > > Perhaps an example will illustrate. Lets say I am making a call to > joe@example.com. I would send an INVITE that looks like: > > INVITE sip:joe@example.com SIP/2.0 > To: sip:joe@example.com > > Now, in one case, I will take example.com, look it up in DNS, and send > > it to the IP address of a server I discover through this process. The > example.com server receives the request (it is the receiving server > here). Now, the host part of the request-URI (example.com) matches to > domain of that server (also example.com), so it knows how to handle > requests for this domain. > > In another case, I am using a local outboud proxy at dynamicsoft.com. > So, instead of sending the above request there, I send it to the IP > address of the dynamicsoft.com proxy, which my UAC is configured with. > > Now, for this proxy, the domain of the request URI (example.com) does > not match the domain of the receiving serer (dynamicsoft.com). So, the > > proxy can either forward it to example.com, or reject it with 404. > > -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 ------_=_NextPart_001_01C0170E.71AA00B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [SIP] A question about Request-URI:

Hi, Hisham:
    It is a good interpretation. If = so, RFC2543 need describe it more clear.
    When a Server proxy a message = WITHOUT modifying the request-uri, The problem how to select a best = route to proxy the message in order to let it go to the destination = more directly is worth considering. For instance, in the following = example, why the Proxy1 don't proxy the message to there.com directly = but to Proxy2? It need a reasoned interpretation.

    Best regards!
   
Bodgey  

-----Original Message-----
From: Hisham Khartabil [mailto:hisham.khartabil= @lmf.ericsson.se]
Sent: Monday, September 04, 2000 11:08 PM
To: Bodgey Yin Shaohua
Cc: SIP@lists.bell-labs.com
Subject: Re: [SIP] A question about = Request-URI:


The authors of the call flows draft where under the = misconception that
the request-uri has to have the proxy server address = in the host part.
This was corrected in later releases.

If a proxy server receives a request with the host = part matching it
domain, you handle the request by, for example, = tooking up registrations
(in the registrar) for that user-name.  If no = registrations are found, a
404 is returned, otherwise, the request is forwarded = to the address
found in the registrar.

If a proxy server recieves a request with the host = part NOT matching its
domain, the server will just forward the request to = the host specified
in the request-uri WITHOUT modifying the = request-uri.

Regards,
Hisham

Bodgey Yin Shaohua wrote:

>
>
> Hi,Jonathan:
>     Thank you for your = reply.But I also have a puzzle according to
> your answer. Let take a example of a successful = call flow. (The
> section 3.1.2 of = draft-ietf-sip-call-flows-01a.txt)
>
>    User = A          Proxy = 1          Proxy = 2          User B
>      = |            = ;    = |            = ;    = |            = ;    |
>      |   = INVITE F1    = |            = ;    = |            = ;    |
>      = |--------------->|        &nb= sp;       = |            = ;    |
>      = |     407 F2     = |            = ;    = |            = ;    |
>      = |<---------------|        &nb= sp;       = |            = ;    |
>      = |     ACK F3     = |            = ;    = |            = ;    |
>      = |--------------->|        &nb= sp;       = |            = ;    |
>      |   = INVITE F4    = |            = ;    = |            = ;    |
>      = |--------------->|   INVITE F5    = |            = ;    |
>      = |    (100) F6    = |--------------->|   INVITE F7    |
>      = |<---------------|    (100) F8    = |--------------->|
>      = |            = ;    = |<---------------|        &nb= sp;       |
>
>  The F4 is :
>    INVITE sip:UserB@there.com = SIP/2.0
>    To: LittleGuy = <sip:UserB@there.com>
>    Via: SIP/2.0/UDP = here.com:5060
>
>  The F5 is:
>    INVITE sip:UserB@there.com = SIP/2.0
>    To: LittleGuy = <sip:UserB@there.com>
>    Via: SIP/2.0/UDP = ss1.wcom.com:5060;branch=3D2d4790.1
>    Via: SIP/2.0/UDP = here.com:5060
>
>  The F7 is:
>    INVITE sip:UserB@there.com = SIP/2.0
>    To: LittleGuy = <sip:UserB@there.com>
>    Via: SIP/2.0/UDP = ss2.wcom.com:5060;branch=3D721e418c4.1
>    Via: SIP/2.0/UDP = ss1.wcom.com:5060;branch=3D2d4790.1
>    Via: SIP/2.0/UDP = here.com:5060
>
>    The Proxy1 and Proxy2 have = different host from the there.com, so it
> may proxy the message to there.com as indicated = in the figure. Or, it
> may reject the message with 404 response, so = the Call is not
> successful.
>
>    In the early version of the = Call flow, the Request-URI is the
> Proxy's address (ss1.wcom.com for F4 and = ss2.wcom.com for F5) which is
> right according to your explaining.
>
>    So I don't which condition is = right? If we choose a situation, the
> RFC2543 may change somewhat in order to give = clear contradiction.
>
>    Please check it.
>    Best regards!
>
> Bodgey
>
> > Bodgey Yin Shaohua wrote:
> >
> > Hi:
> >       I find = a difference among different versons of the draft of
> SIP
> > Telephony Call Flow Examples:  Before = May 2000, in the Request-URI
> of
> > SIP INVITE, there is a address of the = Pxory the message will head,
> but
> > the version after this time, there is = Callee's address the message
> > will head.
> >
> >      In section = 4.3 of RFC2543, there writes "Typically, the UAC
> sets
> > the Request-URI and TO to the same SIP = URL, pesumed to remain
> > unchanged over long time periods", so = the latter case is right. But
> it
> > is difficult to explain the following word = in this section that is
> > "The host part of the Request-URI = typically agrees with one of the
> > host name of the receiving server. If it = does not, the sever SHOULD
> > proxy the request to the address indicated = or return 404 response if
>
> > it is unwilling to do so".  I = don't know what is meaning of the
> > "receiving server"?
>
> Its the server that receives the = request.
>
> Perhaps an example will illustrate. Lets say I = am making a call to
> joe@example.com. I would send an INVITE that = looks like:
>
> INVITE sip:joe@example.com SIP/2.0
> To: sip:joe@example.com
>
> Now, in one case, I will take example.com, look = it up in DNS, and send
>
> it to the IP address of a server I discover = through this process. The
> example.com server receives the request (it is = the receiving server
> here). Now, the host part of the request-URI = (example.com) matches to
> domain of that server (also example.com), so it = knows how to handle
> requests for this domain.
>
> In another case, I am using a local outboud = proxy at dynamicsoft.com.
> So, instead of sending the above request there, = I send it to the IP
> address of the dynamicsoft.com proxy, which my = UAC is configured with.
>
> Now, for this proxy, the domain of the request = URI (example.com) does
> not match the domain of the receiving serer = (dynamicsoft.com). So, the
>
> proxy can either forward it to example.com, or = reject it with 404.
>
> -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: (732) 741-7244
> http://www.dynamicsoft.com
>
> = _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip

------_=_NextPart_001_01C0170E.71AA00B0-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Sep 5 04:57: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 ESMTP id EAA26195 for ; Tue, 5 Sep 2000 04:57: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 C78144433B; Tue, 5 Sep 2000 03:57:06 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id DF8D644336 for ; Tue, 5 Sep 2000 03:57:01 -0400 (EDT) Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id JAA21284; Tue, 5 Sep 2000 09:54:58 +0100 (BST) Message-ID: <39B4B4E1.1D25AE90@ubiquity.net> Date: Tue, 05 Sep 2000 09:54:57 +0100 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: Hisham Khartabil , sip@lists.bell-labs.com Subject: Re: [SIP] transaction identification References: <002e01c011c2$94a85000$4e34c3c1@ubiquity.co.uk> <39AC83A0.68A61CA@dynamicsoft.com> <39AE1096.95161017@uab.ericsson.se> <39AE38A0.526A55F8@ubiquity.net> <39AF4ADB.B8751B55@dynamicsoft.com> <39AF51F7.CDBFE713@ericsson.fi> <39AF563A.8EEB995@dynamicsoft.com> <39AF7E14.FE7886BB@ubiquity.net> <39B06683.FE987438@dynamicsoft.com> <39B34DAC.5AFF899F@ubiquity.net> <39B3689C.25FE6724@ericsson.fi> <39B36F63.102F31C2@ubiquity.net> <39B46C14.5D921D73@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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > Neil Deason wrote: > > > > Hisham Khartabil wrote: > > > > > > I thought this third part of the branch id is used for a proxy to id itself, > > > and I'm assuming it would be the same everytime. So, how does that make it > > > unique when it comes to identifying a transaction? > > > > No. The new proposed third piece would be used to make the > > the branch ID globally unique. > > > > > Here is my suggestion: > > > > > > The calculated branch (the hash part) the came with the INVITE would be stored > > > as a generic-param in the Record-Route and then copied into route. The proxy > > > would then use that to compare the BYE's (this is assuming that the legal loop > > > detection rules where followed) > > > > > > what does everyone think? > > > > Not backwards compatible. Only maddr parameters are copied > > from the Record-Route into the Route. > > maddr is a URI parameter. All URI parameters should be copied, not just > those. What you copy from Record-Route into Route depends on whether the UA finds the Record-Route in a request or a response. If it is in a response then it copies the Record-Route into Route header fields. If it finds it in a request it only copies the maddr param and any port [bis-01]. The remainder of the Route name-addr value being taken from the originating name-addr value, i.e. the Contact or From header. > As for record-route parameters, rfc2543 says: > > > The calling user agent client copies the Record-Route header into a > > Route header field of subsequent requests within the same call leg, > > reversing the order of requests, so that the first entry is closest > > to the user agent client. > > to me, this would indicate that this includes record-route header > parameters as well. bis-01 says: If a UAC finds a Record-Route header in a response, it copies it into Route header fields of all subsequent requests within the same call leg, reversing the order of fields, so that the first entry is the server closest to the UAC. ... If a UA finds a Record-Route header in a request received as a UAS, it copies the Record-Route maddr parameters and any port value, maintaining their ordering, to the Route header field of future requests issued as a UAC. > That aside, this isn't backwards compatible because the UAs don't copy > Via parameters into the route headers. The suggestion was that a Via branch hash also be stored as a generic param in the Record-Route. Unfortunately generic params do not make it from the Record-Route into the Route. (Remember the discussion about state pushing through Route) 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 Sep 5 05:12: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 ESMTP id FAA26324 for ; Tue, 5 Sep 2000 05:12: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 6B6D344353; Tue, 5 Sep 2000 04:12:28 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id E50B84434F for ; Tue, 5 Sep 2000 04:12:19 -0400 (EDT) Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id KAA27073; Tue, 5 Sep 2000 10:10:01 +0100 (BST) Message-ID: <39B4B86A.59AF86DF@ubiquity.net> Date: Tue, 05 Sep 2000 10:10:02 +0100 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: Hisham Khartabil Cc: Jonathan Rosenberg , sip@lists.bell-labs.com Subject: Re: [SIP] transaction identification References: <002e01c011c2$94a85000$4e34c3c1@ubiquity.co.uk> <39AC83A0.68A61CA@dynamicsoft.com> <39AE1096.95161017@uab.ericsson.se> <39AE38A0.526A55F8@ubiquity.net> <39AF4ADB.B8751B55@dynamicsoft.com> <39AF51F7.CDBFE713@ericsson.fi> <39AF563A.8EEB995@dynamicsoft.com> <39AF7E14.FE7886BB@ubiquity.net> <39B06683.FE987438@dynamicsoft.com> <39B34DAC.5AFF899F@ubiquity.net> <39B3689C.25FE6724@ericsson.fi> <39B36F63.102F31C2@ubiquity.net> <39B46C14.5D921D73@dynamicsoft.com> <39B4834F.483DDA6B@ericsson.fi> 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Hisham Khartabil wrote: > > I apologise if I didn't make myself clear. > > The suggestion was for the proxy itself to put a copy of the calculated branch into > the record-route, not the UA. The UA copies the record-route into route, the branch > is copied in the process. Generic params added to a Record-Route by the Proxy are not subsequently returned in the Route. We have been there before see the slide 'State pushing through Route' in Jonathan's open issues presentation from the 48th IETF meeting. However, in this case unless there is a problem with making the branch ID globally unique to solve the original problem this probably isn't worth getting too excited about. Cheers, Neil -- Ubiquity Software Corporation, UK http://www.ubiquity.net > Jonathan Rosenberg wrote: > > > Neil Deason wrote: > > > > > > Hisham Khartabil wrote: > > > > > > > > I thought this third part of the branch id is used for a proxy to id itself, > > > > and I'm assuming it would be the same everytime. So, how does that make it > > > > unique when it comes to identifying a transaction? > > > > > > No. The new proposed third piece would be used to make the > > > the branch ID globally unique. > > > > > > > Here is my suggestion: > > > > > > > > The calculated branch (the hash part) the came with the INVITE would be stored > > > > as a generic-param in the Record-Route and then copied into route. The proxy > > > > would then use that to compare the BYE's (this is assuming that the legal loop > > > > detection rules where followed) > > > > > > > > what does everyone think? > > > > > > Not backwards compatible. Only maddr parameters are copied > > > from the Record-Route into the Route. > > > > maddr is a URI parameter. All URI parameters should be copied, not just > > those. > > > > As for record-route parameters, rfc2543 says: > > > > > The calling user agent client copies the Record-Route header into a > > > Route header field of subsequent requests within the same call leg, > > > reversing the order of requests, so that the first entry is closest > > > to the user agent client. > > > > to me, this would indicate that this includes record-route header > > parameters as well. > > > > That aside, this isn't backwards compatible because the UAs don't copy > > Via parameters into the route headers. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Sep 5 05:35: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 ESMTP id FAA26478 for ; Tue, 5 Sep 2000 05:35: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 5255D44365; Tue, 5 Sep 2000 04:34:49 -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 6902444336 for ; Tue, 5 Sep 2000 04:34: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 e859YGw10254; Tue, 5 Sep 2000 11:34:16 +0200 (MEST) Received: from ericsson.fi (E0080C7FA22D6.lmf.ericsson.se [131.160.30.48]) by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id MAA20563; Tue, 5 Sep 2000 12:34:15 +0300 (EET DST) Message-ID: <39B4BDB9.3428B8A8@ericsson.fi> Date: Tue, 05 Sep 2000 12:32:42 +0300 From: Hisham Khartabil X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Bodgey Yin Shaohua Cc: SIP@lists.bell-labs.com Subject: Re: [SIP] A question about Request-URI: References: <30B58D519274D41187630050BAD918AF073AD4@mail.in.huawei.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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit I think section 1.4.2 of the bis clearly describes the steps to be taken (SRV, DNS, etc). Regards, Hisham Bodgey Yin Shaohua wrote: > > > Hi, Hisham: > It is a good interpretation. If so, RFC2543 need describe it more > clear. > When a Server proxy a message WITHOUT modifying the request-uri, > The problem how to select a best route to proxy the message in order > to let it go to the destination more directly is worth considering. > For instance, in the following example, why the Proxy1 don't proxy the > message to there.com directly but to Proxy2? It need a reasoned > interpretation. > > Best regards! > > Bodgey > > -----Original Message----- > From: Hisham Khartabil [mailto:hisham.khartabil@lmf.ericsson.se] > Sent: Monday, September 04, 2000 11:08 PM > To: Bodgey Yin Shaohua > Cc: SIP@lists.bell-labs.com > Subject: Re: [SIP] A question about Request-URI: > > The authors of the call flows draft where under the misconception that > > the request-uri has to have the proxy server address in the host part. > > This was corrected in later releases. > > If a proxy server receives a request with the host part matching it > domain, you handle the request by, for example, tooking up > registrations > (in the registrar) for that user-name. If no registrations are found, > a > 404 is returned, otherwise, the request is forwarded to the address > found in the registrar. > > If a proxy server recieves a request with the host part NOT matching > its > domain, the server will just forward the request to the host specified > > in the request-uri WITHOUT modifying the request-uri. > > Regards, > Hisham > > Bodgey Yin Shaohua wrote: > > > > > > > Hi,Jonathan: > > Thank you for your reply.But I also have a puzzle according to > > your answer. Let take a example of a successful call flow. (The > > section 3.1.2 of draft-ietf-sip-call-flows-01a.txt) > > > > User A Proxy 1 Proxy 2 User B > > | | | | > > | INVITE F1 | | | > > |--------------->| | | > > | 407 F2 | | | > > |<---------------| | | > > | ACK F3 | | | > > |--------------->| | | > > | INVITE F4 | | | > > |--------------->| INVITE F5 | | > > | (100) F6 |--------------->| INVITE F7 | > > |<---------------| (100) F8 |--------------->| > > | |<---------------| | > > > > The F4 is : > > INVITE sip:UserB@there.com SIP/2.0 > > To: LittleGuy > > Via: SIP/2.0/UDP here.com:5060 > > > > The F5 is: > > INVITE sip:UserB@there.com SIP/2.0 > > To: LittleGuy > > Via: SIP/2.0/UDP ss1.wcom.com:5060;branch=2d4790.1 > > Via: SIP/2.0/UDP here.com:5060 > > > > The F7 is: > > INVITE sip:UserB@there.com SIP/2.0 > > To: LittleGuy > > Via: SIP/2.0/UDP ss2.wcom.com:5060;branch=721e418c4.1 > > Via: SIP/2.0/UDP ss1.wcom.com:5060;branch=2d4790.1 > > Via: SIP/2.0/UDP here.com:5060 > > > > The Proxy1 and Proxy2 have different host from the there.com, so > it > > may proxy the message to there.com as indicated in the figure. Or, > it > > may reject the message with 404 response, so the Call is not > > successful. > > > > In the early version of the Call flow, the Request-URI is the > > Proxy's address (ss1.wcom.com for F4 and ss2.wcom.com for F5) which > is > > right according to your explaining. > > > > So I don't which condition is right? If we choose a situation, > the > > RFC2543 may change somewhat in order to give clear contradiction. > > > > Please check it. > > Best regards! > > > > Bodgey > > > > > Bodgey Yin Shaohua wrote: > > > > > > Hi: > > > I find a difference among different versons of the draft of > > SIP > > > Telephony Call Flow Examples: Before May 2000, in the Request-URI > > > of > > > SIP INVITE, there is a address of the Pxory the message will head, > > > but > > > the version after this time, there is Callee's address the message > > > > will head. > > > > > > In section 4.3 of RFC2543, there writes "Typically, the UAC > > sets > > > the Request-URI and TO to the same SIP URL, pesumed to remain > > > unchanged over long time periods", so the latter case is right. > But > > it > > > is difficult to explain the following word in this section that is > > > > "The host part of the Request-URI typically agrees with one of the > > > > host name of the receiving server. If it does not, the sever > SHOULD > > > proxy the request to the address indicated or return 404 response > if > > > > > it is unwilling to do so". I don't know what is meaning of the > > > "receiving server"? > > > > Its the server that receives the request. > > > > Perhaps an example will illustrate. Lets say I am making a call to > > joe@example.com. I would send an INVITE that looks like: > > > > INVITE sip:joe@example.com SIP/2.0 > > To: sip:joe@example.com > > > > Now, in one case, I will take example.com, look it up in DNS, and > send > > > > it to the IP address of a server I discover through this process. > The > > example.com server receives the request (it is the receiving server > > here). Now, the host part of the request-URI (example.com) matches > to > > domain of that server (also example.com), so it knows how to handle > > requests for this domain. > > > > In another case, I am using a local outboud proxy at > dynamicsoft.com. > > So, instead of sending the above request there, I send it to the IP > > address of the dynamicsoft.com proxy, which my UAC is configured > with. > > > > Now, for this proxy, the domain of the request URI (example.com) > does > > not match the domain of the receiving serer (dynamicsoft.com). So, > the > > > > proxy can either forward it to example.com, or reject it with 404. > > > > -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 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Sep 5 06:57: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 ESMTP id GAA27606 for ; Tue, 5 Sep 2000 06:57: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 78B5A4433F; Tue, 5 Sep 2000 05:57:37 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from pc2call.com (unknown [212.187.178.58]) by lists.bell-labs.com (Postfix) with ESMTP id B32D044336 for ; Tue, 5 Sep 2000 05:57:32 -0400 (EDT) Received: from mail.pc2call.com - 127.0.0.1 by pc2call.com with Microsoft SMTPSVC(5.5.1774.114.11); Tue, 5 Sep 2000 11:55:39 +0100 Received: from 212.187.178.62 by mail.pc2call.com ([212.187.178.58] running VPOP3) with ESMTP; Tue, 5 Sep 2000 11:55:38 +0100 Message-ID: <39B4D17B.7490B29F@switchlab.net> Date: Tue, 05 Sep 2000 11:56:59 +0100 From: Benny Prijono X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: "sip@lists.bell-labs.com" Subject: Re: [SIP] Tag in provisional response References: <39B3CC1E.9BEAE040@switchlab.net> <39B461DC.CFA76D5A@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Server: VPOP3 V1.4.0b - Registered to: Switchlab Ltd Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > Best we can really do is SHOULD. MUST doesn't help you since its not > compatible with rfc2543 in that case. > > -Jonathan R. > Yes, I think that's the best we can do. There's another scenario actually, where I think the presence of tag is important. Consider a client receives two provisional responses (from two servers), and both of them have SDP body. Both SDPs have different codecs. Without a tag, the client will happily (or unhappily) change its codec each time it receives SDP from each server, because it assumes that it has received SDP from one server only, and that server is changing its codecs. With a tag in the provisional response, the client will know that it has received SDP from two different servers, thus it may disable processing of SDP (and RTP) from one server if it wish. Or it can prepare two codecs and a mixing device if it can. > Benny Prijono wrote: > > > > Hi all, > > > > Issue regarding to TAG in provisional responses: > > > > Current bis-01 draft doesn't mandate servers to add tag in provisional > > response for the initial INVITE request, as written in Section 6.43 > > (last paragraph, page 56): > > > > "These servers MAY add the tag for informational responses during > > the initial INVITE transaction, but MUST add a tag to informational > > responses for all subsequent transactions." > > > > Shouldn't it be changed to MUST, so that the client can distinguish > > which response goes to which server? I imagine that a GUI client will > > display two different feedback messages if it gets two provisional > > responses with different tags, so that the client/user awares that > > his/her call has reached two different destinations. For example, the > > first line is "call 1: queued, 1 person ahead" and second line is > > "call 2: ringing". And this is only possible if the tag is present in > > the provisional response. > > > > Comments? > > > > cheers, > > Bennylp > > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Sep 5 07:08: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 ESMTP id HAA27805 for ; Tue, 5 Sep 2000 07:08: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 C8BC34435E; Tue, 5 Sep 2000 06:07:47 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id 167F644353 for ; Tue, 5 Sep 2000 06:07:44 -0400 (EDT) Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id MAA15896; Tue, 5 Sep 2000 12:05:47 +0100 (BST) From: "Jo Hornsby" To: "Benny Prijono" , "Jonathan Rosenberg" Cc: Subject: RE: [SIP] Tag in provisional response Date: Tue, 5 Sep 2000 12:05:48 +0100 Message-ID: <006801c01729$3f1347a0$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: <39B4D17B.7490B29F@switchlab.net> Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit > There's another scenario actually, where I think the presence of tag > is important. Consider a client receives two provisional responses > (from two servers), and both of them have SDP body. Both SDPs have > different codecs. Without a tag, the client will happily (or > unhappily) change its codec each time it receives SDP from each > server, because it assumes that it has received SDP from one server > only, and that server is changing its codecs. > > With a tag in the provisional response, the client will know that it > has received SDP from two different servers, thus it may disable > processing of SDP (and RTP) from one server if it wish. Or it can > prepare two codecs and a mixing device if it can. This probably isn't a massive problem, since if the SDP is important, the Server involved will probably be using Reliable Provisional Responses; the Reliable Provisional Response Draft mandates the use of a tag. 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 Tue Sep 5 08:06: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 ESMTP id IAA29352 for ; Tue, 5 Sep 2000 08:06: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 EC5DF4433F; Tue, 5 Sep 2000 07:06:39 -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 AA8BE44336 for ; Tue, 5 Sep 2000 07:03:17 -0400 (EDT) Received: by mail.in.huawei.com with Internet Mail Service (5.5.2650.21) id ; Tue, 5 Sep 2000 17:14:06 +0530 Message-ID: <30B58D519274D41187630050BAD918AF073B8E@mail.in.huawei.com> From: Bodgey Yin Shaohua To: Hisham Khartabil Cc: SIP@lists.bell-labs.com Subject: RE: [SIP] A question about Request-URI: Date: Tue, 5 Sep 2000 17:13:59 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0172E.982395C0" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com 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_01C0172E.982395C0 Content-Type: text/plain; charset="iso-8859-1" Hi: The "Clear" means your interpretation"If a proxy server recieves a request with the host part NOT matching its domain, the server will just forward the request to the host specified in the request-uri WITHOUT modifying the request-uri" have a contradiction with the section 4.3.Because there is "return 404 response if it is unwilling to do so", If your opinon is right, so RFC2543 need change somewhat. I have known how to select the SIP server, thanks! Best regards! Bodgey -----Original Message----- From: Hisham Khartabil [mailto:hisham.khartabil@lmf.ericsson.se] Sent: Tuesday, September 05, 2000 2:33 AM To: Bodgey Yin Shaohua Cc: SIP@lists.bell-labs.com Subject: Re: [SIP] A question about Request-URI: I think section 1.4.2 of the bis clearly describes the steps to be taken (SRV, DNS, etc). Regards, Hisham Bodgey Yin Shaohua wrote: > > > Hi, Hisham: > It is a good interpretation. If so, RFC2543 need describe it more > clear. > When a Server proxy a message WITHOUT modifying the request-uri, > The problem how to select a best route to proxy the message in order > to let it go to the destination more directly is worth considering. > For instance, in the following example, why the Proxy1 don't proxy the > message to there.com directly but to Proxy2? It need a reasoned > interpretation. > > Best regards! > > Bodgey > > -----Original Message----- > From: Hisham Khartabil [mailto:hisham.khartabil@lmf.ericsson.se] > Sent: Monday, September 04, 2000 11:08 PM > To: Bodgey Yin Shaohua > Cc: SIP@lists.bell-labs.com > Subject: Re: [SIP] A question about Request-URI: > > The authors of the call flows draft where under the misconception that > > the request-uri has to have the proxy server address in the host part. > > This was corrected in later releases. > > If a proxy server receives a request with the host part matching it > domain, you handle the request by, for example, tooking up > registrations > (in the registrar) for that user-name. If no registrations are found, > a > 404 is returned, otherwise, the request is forwarded to the address > found in the registrar. > > If a proxy server recieves a request with the host part NOT matching > its > domain, the server will just forward the request to the host specified > > in the request-uri WITHOUT modifying the request-uri. > > Regards, > Hisham > > Bodgey Yin Shaohua wrote: > > > > > > > Hi,Jonathan: > > Thank you for your reply.But I also have a puzzle according to > > your answer. Let take a example of a successful call flow. (The > > section 3.1.2 of draft-ietf-sip-call-flows-01a.txt) > > > > User A Proxy 1 Proxy 2 User B > > | | | | > > | INVITE F1 | | | > > |--------------->| | | > > | 407 F2 | | | > > |<---------------| | | > > | ACK F3 | | | > > |--------------->| | | > > | INVITE F4 | | | > > |--------------->| INVITE F5 | | > > | (100) F6 |--------------->| INVITE F7 | > > |<---------------| (100) F8 |--------------->| > > | |<---------------| | > > > > The F4 is : > > INVITE sip:UserB@there.com SIP/2.0 > > To: LittleGuy > > Via: SIP/2.0/UDP here.com:5060 > > > > The F5 is: > > INVITE sip:UserB@there.com SIP/2.0 > > To: LittleGuy > > Via: SIP/2.0/UDP ss1.wcom.com:5060;branch=2d4790.1 > > Via: SIP/2.0/UDP here.com:5060 > > > > The F7 is: > > INVITE sip:UserB@there.com SIP/2.0 > > To: LittleGuy > > Via: SIP/2.0/UDP ss2.wcom.com:5060;branch=721e418c4.1 > > Via: SIP/2.0/UDP ss1.wcom.com:5060;branch=2d4790.1 > > Via: SIP/2.0/UDP here.com:5060 > > > > The Proxy1 and Proxy2 have different host from the there.com, so > it > > may proxy the message to there.com as indicated in the figure. Or, > it > > may reject the message with 404 response, so the Call is not > > successful. > > > > In the early version of the Call flow, the Request-URI is the > > Proxy's address (ss1.wcom.com for F4 and ss2.wcom.com for F5) which > is > > right according to your explaining. > > > > So I don't which condition is right? If we choose a situation, > the > > RFC2543 may change somewhat in order to give clear contradiction. > > > > Please check it. > > Best regards! > > > > Bodgey > > > > > Bodgey Yin Shaohua wrote: > > > > > > Hi: > > > I find a difference among different versons of the draft of > > SIP > > > Telephony Call Flow Examples: Before May 2000, in the Request-URI > > > of > > > SIP INVITE, there is a address of the Pxory the message will head, > > > but > > > the version after this time, there is Callee's address the message > > > > will head. > > > > > > In section 4.3 of RFC2543, there writes "Typically, the UAC > > sets > > > the Request-URI and TO to the same SIP URL, pesumed to remain > > > unchanged over long time periods", so the latter case is right. > But > > it > > > is difficult to explain the following word in this section that is > > > > "The host part of the Request-URI typically agrees with one of the > > > > host name of the receiving server. If it does not, the sever > SHOULD > > > proxy the request to the address indicated or return 404 response > if > > > > > it is unwilling to do so". I don't know what is meaning of the > > > "receiving server"? > > > > Its the server that receives the request. > > > > Perhaps an example will illustrate. Lets say I am making a call to > > joe@example.com. I would send an INVITE that looks like: > > > > INVITE sip:joe@example.com SIP/2.0 > > To: sip:joe@example.com > > > > Now, in one case, I will take example.com, look it up in DNS, and > send > > > > it to the IP address of a server I discover through this process. > The > > example.com server receives the request (it is the receiving server > > here). Now, the host part of the request-URI (example.com) matches > to > > domain of that server (also example.com), so it knows how to handle > > requests for this domain. > > > > In another case, I am using a local outboud proxy at > dynamicsoft.com. > > So, instead of sending the above request there, I send it to the IP > > address of the dynamicsoft.com proxy, which my UAC is configured > with. > > > > Now, for this proxy, the domain of the request URI (example.com) > does > > not match the domain of the receiving serer (dynamicsoft.com). So, > the > > > > proxy can either forward it to example.com, or reject it with 404. > > > > -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 ------_=_NextPart_001_01C0172E.982395C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [SIP] A question about Request-URI:

Hi:
   The "Clear" means your = interpretation"If a proxy server recieves a request with the host = part NOT matching its domain, the server will just forward the request = to the host specified

in the request-uri WITHOUT modifying the = request-uri" have a contradiction with the section 4.3.Because = there is "return 404 response if it is unwilling to do so", = If your opinon is right, so RFC2543 need change somewhat.

   I have known how to select the SIP = server, thanks!
   Best regards!

Bodgey
-----Original Message-----
From: Hisham Khartabil [mailto:hisham.khartabil= @lmf.ericsson.se]
Sent: Tuesday, September 05, 2000 2:33 AM
To: Bodgey Yin Shaohua
Cc: SIP@lists.bell-labs.com
Subject: Re: [SIP] A question about = Request-URI:


I think section 1.4.2 of the bis clearly describes = the steps to be taken
(SRV, DNS, etc).

Regards,
Hisham

Bodgey Yin Shaohua wrote:

>
>
> Hi, Hisham:
>     It is a good = interpretation. If so, RFC2543 need describe it more
> clear.
>     When a Server proxy a = message WITHOUT modifying the request-uri,
> The problem how to select a best route to proxy = the message in order
> to let it go to the destination more directly = is worth considering.
> For instance, in the following example, why the = Proxy1 don't proxy the
> message to there.com directly but to Proxy2? It = need a reasoned
> interpretation.
>
>     Best regards!
>
> Bodgey
>
> -----Original Message-----
> From: Hisham Khartabil [mailto:hisham.khartabil= @lmf.ericsson.se]
> Sent: Monday, September 04, 2000 11:08 = PM
> To: Bodgey Yin Shaohua
> Cc: SIP@lists.bell-labs.com
> Subject: Re: [SIP] A question about = Request-URI:
>
> The authors of the call flows draft where under = the misconception that
>
> the request-uri has to have the proxy server = address in the host part.
>
> This was corrected in later releases.
>
> If a proxy server receives a request with the = host part matching it
> domain, you handle the request by, for example, = tooking up
> registrations
> (in the registrar) for that user-name.  If = no registrations are found,
> a
> 404 is returned, otherwise, the request is = forwarded to the address
> found in the registrar.
>
> If a proxy server recieves a request with the = host part NOT matching
> its
> domain, the server will just forward the = request to the host specified
>
> in the request-uri WITHOUT modifying the = request-uri.
>
> Regards,
> Hisham
>
> Bodgey Yin Shaohua wrote:
>
> >
> >
> > Hi,Jonathan:
> >     Thank you for your = reply.But I also have a puzzle according to
> > your answer. Let take a example of a = successful call flow. (The
> > section 3.1.2 of = draft-ietf-sip-call-flows-01a.txt)
> >
> >    User = A          Proxy = 1          Proxy = 2          User B
> >      = |            = ;    = |            = ;    = |            = ;    |
> >      = |   INVITE F1    = |            = ;    = |            = ;    |
> >      = |--------------->|        &nb= sp;       = |            = ;    |
> >      = |     407 F2     = |            = ;    = |            = ;    |
> >      = |<---------------|        &nb= sp;       = |            = ;    |
> >      = |     ACK F3     = |            = ;    = |            = ;    |
> >      = |--------------->|        &nb= sp;       = |            = ;    |
> >      = |   INVITE F4    = |            = ;    = |            = ;    |
> >      = |--------------->|   INVITE F5    = |            = ;    |
> >      = |    (100) F6    = |--------------->|   INVITE F7    |
> >      = |<---------------|    (100) F8    = |--------------->|
> >      = |            = ;    = |<---------------|        &nb= sp;       |
> >
> >  The F4 is :
> >    INVITE = sip:UserB@there.com SIP/2.0
> >    To: LittleGuy = <sip:UserB@there.com>
> >    Via: SIP/2.0/UDP = here.com:5060
> >
> >  The F5 is:
> >    INVITE = sip:UserB@there.com SIP/2.0
> >    To: LittleGuy = <sip:UserB@there.com>
> >    Via: SIP/2.0/UDP = ss1.wcom.com:5060;branch=3D2d4790.1
> >    Via: SIP/2.0/UDP = here.com:5060
> >
> >  The F7 is:
> >    INVITE = sip:UserB@there.com SIP/2.0
> >    To: LittleGuy = <sip:UserB@there.com>
> >    Via: SIP/2.0/UDP = ss2.wcom.com:5060;branch=3D721e418c4.1
> >    Via: SIP/2.0/UDP = ss1.wcom.com:5060;branch=3D2d4790.1
> >    Via: SIP/2.0/UDP = here.com:5060
> >
> >    The Proxy1 and Proxy2 = have different host from the there.com, so
> it
> > may proxy the message to there.com as = indicated in the figure. Or,
> it
> > may reject the message with 404 response, = so the Call is not
> > successful.
> >
> >    In the early version of = the Call flow, the Request-URI is the
> > Proxy's address (ss1.wcom.com for F4 and = ss2.wcom.com for F5) which
> is
> > right according to your explaining.
> >
> >    So I don't which = condition is right? If we choose a situation,
> the
> > RFC2543 may change somewhat in order to = give clear contradiction.
> >
> >    Please check it.
> >    Best regards!
> >
> > Bodgey
> >
> > > Bodgey Yin Shaohua wrote:
> > >
> > > Hi:
> > >       I = find a difference among different versons of the draft of
> > SIP
> > > Telephony Call Flow Examples:  = Before May 2000, in the Request-URI
>
> > of
> > > SIP INVITE, there is a address of the = Pxory the message will head,
>
> > but
> > > the version after this time, there is = Callee's address the message
>
> > > will head.
> > >
> > >      In = section 4.3 of RFC2543, there writes "Typically, the UAC
> > sets
> > > the Request-URI and TO to the same = SIP URL, pesumed to remain
> > > unchanged over long time = periods", so the latter case is right.
> But
> > it
> > > is difficult to explain the following = word in this section that is
>
> > > "The host part of the = Request-URI typically agrees with one of the
>
> > > host name of the receiving server. If = it does not, the sever
> SHOULD
> > > proxy the request to the address = indicated or return 404 response
> if
> >
> > > it is unwilling to do so".  = I don't know what is meaning of the
> > > "receiving server"?
> >
> > Its the server that receives the = request.
> >
> > Perhaps an example will illustrate. Lets = say I am making a call to
> > joe@example.com. I would send an INVITE = that looks like:
> >
> > INVITE sip:joe@example.com SIP/2.0
> > To: sip:joe@example.com
> >
> > Now, in one case, I will take example.com, = look it up in DNS, and
> send
> >
> > it to the IP address of a server I = discover through this process.
> The
> > example.com server receives the request = (it is the receiving server
> > here). Now, the host part of the = request-URI (example.com) matches
> to
> > domain of that server (also example.com), = so it knows how to handle
> > requests for this domain.
> >
> > In another case, I am using a local = outboud proxy at
> dynamicsoft.com.
> > So, instead of sending the above request = there, I send it to the IP
> > address of the dynamicsoft.com proxy, = which my UAC is configured
> with.
> >
> > Now, for this proxy, the domain of the = request URI (example.com)
> does
> > not match the domain of the receiving = serer (dynamicsoft.com). So,
> the
> >
> > proxy can either forward it to = example.com, or reject it with 404.
> >
> > -Jonathan R.
> >
> > --
> > Jonathan D. = Rosenberg          &nb= sp;            = 72 Eagle Rock Ave.
> > Chief Scientist    &nbs= p;           &nbs= p;            = 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: (732) 741-7244
> > http://www.dynamicsoft.com
> >
> > = _______________________________________________
> > SIP mailing list
> > SIP@lists.bell-labs.com
> > http://lists.bell-labs.com/mailman/listinfo/sip

------_=_NextPart_001_01C0172E.982395C0-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Sep 5 08:53: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 ESMTP id IAA00678 for ; Tue, 5 Sep 2000 08:53: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 7F14444366; Tue, 5 Sep 2000 07:53:29 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from kevlar.softarmor.com (dwillis1.directlink.net [63.64.250.82]) by lists.bell-labs.com (Postfix) with ESMTP id 1399E44336 for ; Tue, 5 Sep 2000 00:11:09 -0400 (EDT) Received: from cowboys (IDENT:root@localhost [127.0.0.1]) by kevlar.softarmor.com (8.9.3/8.9.3) with SMTP id LAA10239 for ; Tue, 5 Sep 2000 11:14:56 -0500 From: "Dean Willis" To: "IETF SIP" Date: Tue, 5 Sep 2000 00:09:00 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Subject: [SIP] Revised minutes of SIP WG, meeting 48 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit I have posted revised minutes at: http://www.softarmor.com/sipwg/meets/IETF48/minutes/draftminutes-2.htm There were several typos corrected (no, we can't consistently spell Jonathan R's last name) and several clarifications requested by Henning and the AAA/Diameter folks (Matt and Pat), and by the ever vigilant Tom Taylor. Thank you all for input. If there are no further amendments requested, I will close the minutes at the end of this week. Thanks, -- Dean _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Sep 5 08:54: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 ESMTP id IAA00734 for ; Tue, 5 Sep 2000 08:54: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 54B2144356; Tue, 5 Sep 2000 07:53: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 5221844336 for ; Tue, 5 Sep 2000 06:36:20 -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 e85BaHp11272 for ; Tue, 5 Sep 2000 13:36:17 +0200 (MEST) Received: from uabx04c411.uab.ericsson.se.uab.ericsson.se (uabx04c411 [134.138.229.171]) by ms.uab.ericsson.se (8.10.0/8.10.0/uab-2.26) with ESMTP id e85BaHL25846 for ; Tue, 5 Sep 2000 13:36:17 +0200 (MET DST) Received: from uab.ericsson.se by uabx04c411.uab.ericsson.se.uab.ericsson.se (8.8.7/client-1.3uab1) id NAA25474; Tue, 5 Sep 2000 13:36:15 +0200 (MET DST) Message-ID: <39B4DAAE.358F071C@uab.ericsson.se> Date: Tue, 05 Sep 2000 13:36:14 +0200 From: Bertil Engelholm Organization: Ericsson Utvecklings AB X-Mailer: Mozilla 4.7C-CCK-MCD [en] (X11; U; SunOS 5.6 sun4m) X-Accept-Language: sv,en-US MIME-Version: 1.0 To: SIP@lists.bell-labs.com Subject: Re: [SIP] transaction identification References: <8p21ed$vnd$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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit "Fairlie-Cuninghame, Robert" wrote: > > Bertil, > > There's a difference between removing marginally useless headers/features > and changing the whole protocol syntax - thereby making the protocol no > longer backwards compatible. This backwards compatible argument seems to come up again and again. Could someone please explain what defines when a change is regarded as "backward compatible" vs "non backward compatible" in the SIP case ? Is it related only to UA's or also to proxy servers ? When in time was it decided that no non backwards compatible changes are allowed any more ? Does this mean we can't add a parameter in the requestURI to fix the transaction id problem. If we add such a parameter it means that all proxies have to change to use that parameter which I would regard as a non backward compatible change. > > There are too many SIP implementations already out there to make these > changes now (even if as implementors we would like to make these > simplifications). Most SIP implementations became obsolete when Record-Route/Route was introduced not too long time ago. Are you saying that since then there has been MANY SIP implementations released ? If this is true I might understand the need for only backwards compatible changes better. At the same time I think it's a small job to remove the use of compact form (if anyone is using it) the use of comma separated lists and line folding. > > I beleive the recent discussions about simplifying the SIP syntax were > suggesting that implementations SHOULD generate messages in the canonical > form but still MUST still be able to parse anything (for backwards compat) - > as distinct from removing these annoying elements form the protocol > altogether. > Yes, my first suggestion was like that but when Henning welcomed possible simplifications in the protocol I took the chance to get rid of more things. I didn't realize that he maybe meant that it's OK to remove things ONLY if it is backwards compatible. Removing the VIA hiding is something I agree on at least when there are no possibility to hide Record-Route and since hiding the VIA cause problems for loop detection -- 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 Sep 5 08:56: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 ESMTP id IAA00780 for ; Tue, 5 Sep 2000 08:56: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 65F2444373; Tue, 5 Sep 2000 07:53:49 -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 7D80244353 for ; Tue, 5 Sep 2000 07:25: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 IAA17135; Tue, 5 Sep 2000 08:25:42 -0400 (EDT) Message-ID: <39B4E646.377AC137@cs.columbia.edu> Date: Tue, 05 Sep 2000 08:25:42 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: Neil Deason , sip@lists.bell-labs.com Subject: Re: [SIP] transaction identification References: <002e01c011c2$94a85000$4e34c3c1@ubiquity.co.uk> <39AC83A0.68A61CA@dynamicsoft.com> <39AE1096.95161017@uab.ericsson.se> <39AE38A0.526A55F8@ubiquity.net> <39AF4ADB.B8751B55@dynamicsoft.com> <39AF51F7.CDBFE713@ericsson.fi> <39AF563A.8EEB995@dynamicsoft.com> <39AF7E14.FE7886BB@ubiquity.net> <39B06683.FE987438@dynamicsoft.com> <39B34DAC.5AFF899F@ubiquity.net> <39B3DF70.46752EC9@cs.columbia.edu> <39B46B47.5582895@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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > Henning Schulzrinne wrote: > > > > Neil Deason wrote: > > > > > > > > > > > This possible fix was not introduced just for Via hiding. > > > The original discussion was about request retransmissions > > > on reverse spirals when record routing is in operation. > > > > > > A -INV-> P1 -INV-> P2 -INV-> P1 -INV-> B > > > > > > A is originating UA, B is receiving UA, P1 & P2 are proxies > > > that Record-Route. B now sends a BYE. When the P2-P1 "portion" > > > of the BYE reaches P1, how will it distinguish that request > > > from the initial B-P1 as the spec stands? So the idea was to > > > change the definition of isomorphic requests to include a > > > globally unique branch param. > > > > Added to the spec. The definition of the second branch parameter was > > always pretty vague, including "a sequence number", which presumably > > would do as long as the count is across all transactions. > > Just to be clear here; the discussion to date of having a third > component that is globally unique is going to be folded into the second > component. That component was used for the actual "branch" > identification - if a proxy forks, and the response comes, for which > forked request is the response? So, a globally unique ID will be used > here instead of a simple sequence number that resets for each > transaction. Yes, the second parameter is now defined to be a globally unique identifier. Strictly speaking, it only has to be unique within a server, but it seems that we've learned along the way that if in doubt, globally unique is safest. This is strictly a local matter, so any changes are just affecting local operation, not interoperation. -- 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 Sep 5 09:50: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 ESMTP id JAA02057 for ; Tue, 5 Sep 2000 09:50: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 89EF744345; Tue, 5 Sep 2000 08:50:36 -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 E377A44336 for ; Tue, 5 Sep 2000 08:50:32 -0400 (EDT) Received: from dynamicsoft.com (1Cust235.tnt1.freehold.nj.da.uu.net [63.17.113.235]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id JAA03576; Tue, 5 Sep 2000 09:52:18 -0400 (EDT) Message-ID: <39B4F9F0.C1EE9CA8@dynamicsoft.com> Date: Tue, 05 Sep 2000 09:49:36 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Bertil Engelholm Cc: SIP@lists.bell-labs.com Subject: Re: [SIP] transaction identification References: <8p21ed$vnd$1@lux2.datacom-lab.uab.ericsson.se> <39B4DAAE.358F071C@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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Bertil Engelholm wrote: > > "Fairlie-Cuninghame, Robert" wrote: > > > > Bertil, > > > > There's a difference between removing marginally useless headers/features > > and changing the whole protocol syntax - thereby making the protocol no > > longer backwards compatible. > > This backwards compatible argument seems to come up again and again. > Could someone please explain what defines when a change is regarded > as "backward compatible" vs "non backward compatible" in the SIP > case ? Is it related only to UA's or also to proxy servers ? Both, of course. Backwards compatible means a change or fix is "invisible" to existing SIP devices, whilst useful to ones compliant to the bis draft. > > When in time was it decided that no non backwards compatible > changes are allowed any more ? This is IETF process for evolution of an RFC. > > Does this mean we can't add a parameter in the requestURI to > fix the transaction id problem. If we add such a parameter it > means that all proxies have to change to use that parameter > which I would regard as a non backward compatible change. If it breaks correct operation by existing proxies, yes, it cannot be done. > > > > > There are too many SIP implementations already out there to make these > > changes now (even if as implementors we would like to make these > > simplifications). > > Most SIP implementations became obsolete when Record-Route/Route > was introduced not too long time ago. Huh? Not sure which specification you are referring to, but the one I look at, rfc2543, has both Route and Record-Route. > Are you saying that since > then there has been MANY SIP implementations released ? There are many implementations of rfc2543. Over 50 implementations came to the last bakeoff. > If this is true I might understand the need for only backwards > compatible changes better. At the same time I think it's a small > job to remove the use of compact form (if anyone is using it) the > use of comma separated lists and line folding. These are senseless things to remove. Handling short form is trivial. Removing it will break backwards compatibility (requests with short form will be rejected as errored). Things like Via hiding can be removed since the Hide header will just be ignored, and the feature not provided, just as if it were never in the spec in the first place. -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 Sep 5 10:16: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 ESMTP id KAA03014 for ; Tue, 5 Sep 2000 10:16: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 46BD844362; Tue, 5 Sep 2000 09:16:34 -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 36B4244355 for ; Tue, 5 Sep 2000 09:16:31 -0400 (EDT) Received: from dynamicsoft.com (1Cust235.tnt1.freehold.nj.da.uu.net [63.17.113.235]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id KAA03885; Tue, 5 Sep 2000 10:18:14 -0400 (EDT) Message-ID: <39B4FFF9.2EC63E06@dynamicsoft.com> Date: Tue, 05 Sep 2000 10:15:21 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Neil Deason Cc: Hisham Khartabil , sip@lists.bell-labs.com Subject: Re: [SIP] transaction identification References: <002e01c011c2$94a85000$4e34c3c1@ubiquity.co.uk> <39AC83A0.68A61CA@dynamicsoft.com> <39AE1096.95161017@uab.ericsson.se> <39AE38A0.526A55F8@ubiquity.net> <39AF4ADB.B8751B55@dynamicsoft.com> <39AF51F7.CDBFE713@ericsson.fi> <39AF563A.8EEB995@dynamicsoft.com> <39AF7E14.FE7886BB@ubiquity.net> <39B06683.FE987438@dynamicsoft.com> <39B34DAC.5AFF899F@ubiquity.net> <39B3689C.25FE6724@ericsson.fi> <39B36F63.102F31C2@ubiquity.net> <39B46C14.5D921D73@dynamicsoft.com> <39B4B4E1.1D25AE90@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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Neil Deason wrote: > > > > Not backwards compatible. Only maddr parameters are copied > > > from the Record-Route into the Route. > > > > maddr is a URI parameter. All URI parameters should be copied, not just > > those. > > What you copy from Record-Route into Route depends on whether > the UA finds the Record-Route in a request or a response. > If it is in a response then it copies the Record-Route into > Route header fields. If it finds it in a request it only copies > the maddr param and any port [bis-01]. The remainder of the > Route name-addr value being taken from the originating > name-addr value, i.e. the Contact or From header. Well, the name-addr is part of the URI. The question is: what about Record-Route parameters? Seems like these should be copied. The spec should be clarified in that regard. > > > As for record-route parameters, rfc2543 says: > > > > > The calling user agent client copies the Record-Route header into a > > > Route header field of subsequent requests within the same call leg, > > > reversing the order of requests, so that the first entry is closest > > > to the user agent client. > > > > to me, this would indicate that this includes record-route header > > parameters as well. > > bis-01 says: > If a UAC finds a Record-Route header in a response, it copies > it into > Route header fields of all subsequent requests within the same > call > leg, reversing the order of fields, so that the first entry is > the > server closest to the UAC. > ... > If a UA finds a Record-Route header in a request received as a > UAS, > it copies the Record-Route maddr parameters and any port > value, > maintaining their ordering, to the Route header field of > future > requests issued as a UAC. > > > That aside, this isn't backwards compatible because the UAs don't copy > > Via parameters into the route headers. > > The suggestion was that a Via branch hash also be stored > as a generic param in the Record-Route. Unfortunately generic > params do not make it from the Record-Route into the Route. > (Remember the discussion about state pushing through Route) I agree that this idea of mingling Via and Record-Route is not a good path to follow. Seems like we have arrived already at the ideal solution - usage of the sequence number component of the branch ID. That aside, as a separate note, its worth noting the following: Neil writes: > Generic params added to a Record-Route by the Proxy are > not subsequently returned in the Route. We have been there > before see the slide 'State pushing through Route' > in Jonathan's open issues presentation from the 48th > IETF meeting. This is true; a proxy won't get back any Record-Route parameters it inserts. But, URI parameters will get returned through the request URI. Implementations of a UAC should be sure to copy the entire URI from the Record-Routes in the response, into Route in subsequent requests. Similarly, All URI params in the Contact header in the request (excepting maddr and port of course), should be copied into Routes used by the UAS. -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 Sep 5 10:36: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 ESMTP id KAA03584 for ; Tue, 5 Sep 2000 10:36: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 0551D44366; Tue, 5 Sep 2000 09:36:51 -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 EE9BC44336 for ; Tue, 5 Sep 2000 09:36:48 -0400 (EDT) Received: from dynamicsoft.com (1Cust235.tnt1.freehold.nj.da.uu.net [63.17.113.235]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id KAA04132; Tue, 5 Sep 2000 10:34:32 -0400 (EDT) Message-ID: <39B503D5.E34EDF0E@dynamicsoft.com> Date: Tue, 05 Sep 2000 10:31:49 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Bodgey Yin Shaohua Cc: Hisham Khartabil , SIP@lists.bell-labs.com Subject: Re: [SIP] A question about Request-URI: References: <30B58D519274D41187630050BAD918AF073AD4@mail.in.huawei.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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit "Best Route" is really a matter of local policy. In the example call flow you gave, clearly proxy 1 did not forward to proxy 2 based on a lookup of there.com in DNS. Instead, it chose to send to yet another local outbound proxy. There is nothing wrong with doing so. It could be that proxy 1 is a departmental proxy that does some stuff related to the department, and its configured to send all outbound requests to proxy 2, the company wide proxy that controls the firewall. From there, proxy 2 will use DNS to route the request. I will agree that the spec needs additional clarification about the flexibility of routing policies. -Jonathan R. > Bodgey Yin Shaohua wrote: > > Hi, Hisham: > It is a good interpretation. If so, RFC2543 need describe it more > clear. > When a Server proxy a message WITHOUT modifying the request-uri, > The problem how to select a best route to proxy the message in order > to let it go to the destination more directly is worth considering. > For instance, in the following example, why the Proxy1 don't proxy the > message to there.com directly but to Proxy2? It need a reasoned > interpretation. > > Best regards! > > Bodgey > > -----Original Message----- > From: Hisham Khartabil [mailto:hisham.khartabil@lmf.ericsson.se] > Sent: Monday, September 04, 2000 11:08 PM > To: Bodgey Yin Shaohua > Cc: SIP@lists.bell-labs.com > Subject: Re: [SIP] A question about Request-URI: > > The authors of the call flows draft where under the misconception that > > the request-uri has to have the proxy server address in the host part. > > This was corrected in later releases. > > If a proxy server receives a request with the host part matching it > domain, you handle the request by, for example, tooking up > registrations > (in the registrar) for that user-name. If no registrations are found, > a > 404 is returned, otherwise, the request is forwarded to the address > found in the registrar. > > If a proxy server recieves a request with the host part NOT matching > its > domain, the server will just forward the request to the host specified > > in the request-uri WITHOUT modifying the request-uri. > > Regards, > Hisham > > Bodgey Yin Shaohua wrote: > > > > > > > Hi,Jonathan: > > Thank you for your reply.But I also have a puzzle according to > > your answer. Let take a example of a successful call flow. (The > > section 3.1.2 of draft-ietf-sip-call-flows-01a.txt) > > > > User A Proxy 1 Proxy 2 User B > > | | | | > > | INVITE F1 | | | > > |--------------->| | | > > | 407 F2 | | | > > |<---------------| | | > > | ACK F3 | | | > > |--------------->| | | > > | INVITE F4 | | | > > |--------------->| INVITE F5 | | > > | (100) F6 |--------------->| INVITE F7 | > > |<---------------| (100) F8 |--------------->| > > | |<---------------| | > > > > The F4 is : > > INVITE sip:UserB@there.com SIP/2.0 > > To: LittleGuy > > Via: SIP/2.0/UDP here.com:5060 > > > > The F5 is: > > INVITE sip:UserB@there.com SIP/2.0 > > To: LittleGuy > > Via: SIP/2.0/UDP ss1.wcom.com:5060;branch=2d4790.1 > > Via: SIP/2.0/UDP here.com:5060 > > > > The F7 is: > > INVITE sip:UserB@there.com SIP/2.0 > > To: LittleGuy > > Via: SIP/2.0/UDP ss2.wcom.com:5060;branch=721e418c4.1 > > Via: SIP/2.0/UDP ss1.wcom.com:5060;branch=2d4790.1 > > Via: SIP/2.0/UDP here.com:5060 > > > > The Proxy1 and Proxy2 have different host from the there.com, so > it > > may proxy the message to there.com as indicated in the figure. Or, > it > > may reject the message with 404 response, so the Call is not > > successful. > > > > In the early version of the Call flow, the Request-URI is the > > Proxy's address (ss1.wcom.com for F4 and ss2.wcom.com for F5) which > is > > right according to your explaining. > > > > So I don't which condition is right? If we choose a situation, > the > > RFC2543 may change somewhat in order to give clear contradiction. > > > > Please check it. > > Best regards! > > > > Bodgey > > > > > Bodgey Yin Shaohua wrote: > > > > > > Hi: > > > I find a difference among different versons of the draft of > > SIP > > > Telephony Call Flow Examples: Before May 2000, in the Request-URI > > > of > > > SIP INVITE, there is a address of the Pxory the message will head, > > > but > > > the version after this time, there is Callee's address the message > > > > will head. > > > > > > In section 4.3 of RFC2543, there writes "Typically, the UAC > > sets > > > the Request-URI and TO to the same SIP URL, pesumed to remain > > > unchanged over long time periods", so the latter case is right. > But > > it > > > is difficult to explain the following word in this section that is > > > > "The host part of the Request-URI typically agrees with one of the > > > > host name of the receiving server. If it does not, the sever > SHOULD > > > proxy the request to the address indicated or return 404 response > if > > > > > it is unwilling to do so". I don't know what is meaning of the > > > "receiving server"? > > > > Its the server that receives the request. > > > > Perhaps an example will illustrate. Lets say I am making a call to > > joe@example.com. I would send an INVITE that looks like: > > > > INVITE sip:joe@example.com SIP/2.0 > > To: sip:joe@example.com > > > > Now, in one case, I will take example.com, look it up in DNS, and > send > > > > it to the IP address of a server I discover through this process. > The > > example.com server receives the request (it is the receiving server > > here). Now, the host part of the request-URI (example.com) matches > to > > domain of that server (also example.com), so it knows how to handle > > requests for this domain. > > > > In another case, I am using a local outboud proxy at > dynamicsoft.com. > > So, instead of sending the above request there, I send it to the IP > > address of the dynamicsoft.com proxy, which my UAC is configured > with. > > > > Now, for this proxy, the domain of the request URI (example.com) > does > > not match the domain of the receiving serer (dynamicsoft.com). So, > the > > > > proxy can either forward it to example.com, or reject it with 404. > > > > -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 -- 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 Sep 5 11:24: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 ESMTP id LAA04842 for ; Tue, 5 Sep 2000 11:24: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 C109E44375; Tue, 5 Sep 2000 10:23:39 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from pc2call.com (unknown [212.187.178.58]) by lists.bell-labs.com (Postfix) with ESMTP id 8385A44372 for ; Tue, 5 Sep 2000 10:23:33 -0400 (EDT) Received: from mail.pc2call.com - 127.0.0.1 by pc2call.com with Microsoft SMTPSVC(5.5.1774.114.11); Tue, 5 Sep 2000 16:21:40 +0100 Received: from 212.187.178.62 by mail.pc2call.com ([212.187.178.58] running VPOP3) with ESMTP; Tue, 5 Sep 2000 16:21:40 +0100 Message-ID: <39B50F81.66B9C6DD@switchlab.net> Date: Tue, 05 Sep 2000 16:21:37 +0100 From: Benny Prijono X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jo Hornsby Cc: Jonathan Rosenberg , sip@lists.bell-labs.com Subject: Re: [SIP] Tag in provisional response References: <006801c01729$3f1347a0$4e34c3c1@ubiquity.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Server: VPOP3 V1.4.0b - Registered to: Switchlab Ltd Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Jo Hornsby wrote: > > > There's another scenario actually, where I think the presence of tag > > is important. Consider a client receives two provisional responses > > (from two servers), and both of them have SDP body. Both SDPs have > > different codecs. Without a tag, the client will happily (or > > unhappily) change its codec each time it receives SDP from each > > server, because it assumes that it has received SDP from one server > > only, and that server is changing its codecs. > > > > With a tag in the provisional response, the client will know that it > > has received SDP from two different servers, thus it may disable > > processing of SDP (and RTP) from one server if it wish. Or it can > > prepare two codecs and a mixing device if it can. > > This probably isn't a massive problem, since if the SDP is > important, the Server involved will probably be using Reliable > Provisional Responses; the Reliable Provisional Response Draft > mandates the use of a tag. > Thanks for pointing this out. So now it's clear to me that Reliable Provisional Response is the only solution for the client to know which provisional responses came from which server. cheers, Bennylp _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Sep 5 11:32: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 ESMTP id LAA05255 for ; Tue, 5 Sep 2000 11:32: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 1E1144437D; Tue, 5 Sep 2000 10:28:21 -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 C7E6B4433F for ; Tue, 5 Sep 2000 10:00: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 KAA25237; Tue, 5 Sep 2000 10:59:52 -0400 (EDT) Message-ID: <39B50A68.DC5192A1@cs.columbia.edu> Date: Tue, 05 Sep 2000 10:59:52 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: Bodgey Yin Shaohua , Hisham Khartabil , SIP@lists.bell-labs.com Subject: Re: [SIP] A question about Request-URI: References: <30B58D519274D41187630050BAD918AF073AD4@mail.in.huawei.com> <39B503D5.E34EDF0E@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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Attempt at a paragraph for the introduction: SIP requests are forwarded by proxies. User agents send requests either directly to the address indicated in the request URI or to a designated proxy (``outbound proxy''). Each proxy can forward the request based on any combination of local policy decisions and information in the request. It {\MAY} rewrite the the request URI. A proxy {\MAY} also forward the request to another designated proxy regardless of the request URI. For example, a departmental proxy could forward all authorized requests to a corporate-wide proxy which then forwards it to the proxy operated by the Internet service provider, which finally routes the request based on the request URI. ---- The introduction already has the more formal: When a client wishes to send a request, the client either sends it to a locally configured SIP proxy server (as in HTTP), independent of the \header{Request-URI}, or sends it to the IP address and port corresponding to the \header{Request-URI}. -- 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 Sep 5 11:42: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 ESMTP id LAA05776 for ; Tue, 5 Sep 2000 11:42: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 625D944381; Tue, 5 Sep 2000 10:41:39 -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 36F844437F for ; Tue, 5 Sep 2000 10:41:35 -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 IAA29640; Tue, 5 Sep 2000 08:41:53 -0700 (PDT) Received: from rmahy-home-nt (rmahy-dsl1.cisco.com [10.19.53.122]) by imop.cisco.com (Mirapoint) with ESMTP id AAC39981; Tue, 5 Sep 2000 08:41:31 -0700 (PDT) Message-Id: <4.2.0.58.20000905075624.01896f00@lint.cisco.com> X-Sender: rmahy@imop.cisco.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Tue, 05 Sep 2000 08:40:43 -0700 To: Jonathan Rosenberg From: Rohan Mahy Subject: Re: [SIP] Possible REFER problem? Cc: Eric Tremblay , "Robert Sparks (E-mail)" , sip@lists.bell-labs.com In-Reply-To: <39B46168.83C15332@dynamicsoft.com> References: 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com At 07:58 PM 9/4/00 , Jonathan Rosenberg wrote: >Eric Tremblay wrote: > > > > I think that using the contact URL in the Refer-To is not the best thing to > > do because this could bypass some of the system policies that requires all > > calls to go trough a proxy (for tracing, billing or whatever services). > > Note that this is fixed by having TT return a 305 response to the INVITE > > received from Transferee, in which case Transferee should resend the INVITE > > to a proxy. > >Correct. It should not use the Contact URL. What is the problem with issuing disambiguous requests? We can still send them through a proxy. A called B B put A on hold B called C B completes the transfer by sending this REFER REFER sip:userA@171.69.34.14 SIP/2.0 Via: SIP/2.0/UDP userB-deskphone.widgets.com:5060 To: From: Call-Id: 2378007@171.69.34.14 (same ID used for A's INVITE to B) Refer-To: &Call-Id=137034@userB-deskphone.widgets.com> Referred-By: &Call-Id=137034@userB-deskphone.widgets.com> A generates this INVITE from the REFER INVITE sip:userc@yosemite-confroom.widgets.com SIP/2.0 Via: SIP/2.0/UDP 171.69.34.14:5060 To: From: Call-ID: 137034@userB-deskphone.widgets.com Referred-By: &Call-Id=137034@userB-deskphone.widgets.com> Contact: There is no reason that these two requests can't make it through the desired chain of proxies. The administrators of loopback.edu and widgets.com will probably both setup policies/firewalls/whatever to insure that, whether the requests are first-time INVITEs, reINVITEs, reffered INVITEs, or other methods. > > On the other hand, when using the original URL in the Refer-To, I think it > > is possible that the call from Transferee to TT will be routed to a totaly > > different destination, probably because the proxy has forked and someone > > else has answered before TT could. > >No. It would not be routed to a "totally" different location. Forking in >SIP is not meant to be a randomization process; its meant to be a means >of finding the user where they are currently available. In a reasonable >SIP system, if they are available at some destination for a first call, >a second call should be able to "ring" that same phone as well. I disagree. CPL or other routing logic may very reasonably direct caller A to Voicemail, while it directs caller B directly to a cell phone or conference room. Just because I REGISTER from a conference room, doesn't mean I want ALL my calls to come there. > > 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? thanks, -rohan > > First, is this really a problem or I'm forgetting something? > >I do not believe it is a real 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: (732) 741-7244 >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 Sep 5 11:54: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 ESMTP id LAA06076 for ; Tue, 5 Sep 2000 11:54: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 E2F664438C; Tue, 5 Sep 2000 10:52:55 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from smtp.netservers.net (smtp2.netservers.net [64.45.27.102]) by lists.bell-labs.com (Postfix) with SMTP id BDBE444365 for ; Tue, 5 Sep 2000 10:52:48 -0400 (EDT) Received: (qmail 30279 invoked from network); 5 Sep 2000 15:51:35 -0000 Received: from unknown (HELO voip) (216.101.190.172) by smtp with SMTP; 5 Sep 2000 15:51:35 -0000 From: "IPTelephonyJobs.com" To: "SIPbell-labs" Date: Tue, 5 Sep 2000 08:46:09 -0700 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0002_01C01715.BCC71690" 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 Subject: [SIP] ***New Site : IPTelephonyJobs.com*** Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com This is a multi-part message in MIME format. ------=_NextPart_000_0002_01C01715.BCC71690 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hello, We have launched IPTelephonyJobs.com. The site is dedicated to IP Telephony professionals. The following areas are specifically targeted among others: VoIP (h.323, mgcp, sip, megaco, call agents...) PSTN(ss7, isdn, ain/in,..) Wireless(gprs, cdma, gsm,...) IP Routing/Switching + others Services offered to Job Seekers: - Profile only entries lets you keep your personal information private. - Profile + Resume entries lets the employer have a better understanding of your background. - Control access to your resume on demand. So just drop by our site and fill in your profile. http://www.iptelephonyjobs.com jobs@iptelephonyjobs.com ------=_NextPart_000_0002_01C01715.BCC71690 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello,
 
   We = have launched=20 IPTelephonyJobs.com. The site is
dedicated to IP Telephony=20 professionals. The following
areas are specifically targeted = among=20 others:
 
     VoIP=20 (h.323, mgcp, sip, megaco, call = agents...)
    =20 PSTN(ss7, isdn, ain/in,..)
     = Wireless(gprs, cdma,=20 gsm,...)
     IP=20 Routing/Switching
     + others
 
Services offered to = Job=20 Seekers:
 
 - Profile = only entries lets=20 you keep your personal information private.
 
 - Profile + = Resume entries=20 lets the employer have a better understanding of your=20 background. 
 
 - Control = access to your=20 resume on demand.
 
So just drop by our = site and fill=20 in your profile.
 
http://www.iptelephonyjobs.com
 

jobs@iptelephonyjobs.com
------=_NextPart_000_0002_01C01715.BCC71690-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Sep 5 11:55: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 ESMTP id LAA06105 for ; Tue, 5 Sep 2000 11:55: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 DBD7E4436F; Tue, 5 Sep 2000 10:54:28 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id 96B874436C for ; Tue, 5 Sep 2000 10:54:24 -0400 (EDT) Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id QAA08240; Tue, 5 Sep 2000 16:52:32 +0100 (BST) Message-ID: <39B516BF.64B3D255@ubiquity.net> Date: Tue, 05 Sep 2000 16:52:31 +0100 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] transaction identification References: <002e01c011c2$94a85000$4e34c3c1@ubiquity.co.uk> <39AC83A0.68A61CA@dynamicsoft.com> <39AE1096.95161017@uab.ericsson.se> <39AE38A0.526A55F8@ubiquity.net> <39AF4ADB.B8751B55@dynamicsoft.com> <39AF51F7.CDBFE713@ericsson.fi> <39AF563A.8EEB995@dynamicsoft.com> <39AF7E14.FE7886BB@ubiquity.net> <39B06683.FE987438@dynamicsoft.com> <39B34DAC.5AFF899F@ubiquity.net> <39B3689C.25FE6724@ericsson.fi> <39B36F63.102F31C2@ubiquity.net> <39B46C14.5D921D73@dynamicsoft.com> <39B4B4E1.1D25AE90@ubiquity.net> <39B4FFF9.2EC63E06@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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > Neil Deason wrote: > > > > > > Not backwards compatible. Only maddr parameters are copied > > > > from the Record-Route into the Route. > > > > > > maddr is a URI parameter. All URI parameters should be copied, not just > > > those. > > > > What you copy from Record-Route into Route depends on whether > > the UA finds the Record-Route in a request or a response. > > If it is in a response then it copies the Record-Route into > > Route header fields. If it finds it in a request it only copies > > the maddr param and any port [bis-01]. The remainder of the > > Route name-addr value being taken from the originating > > name-addr value, i.e. the Contact or From header. > > Well, the name-addr is part of the URI. The question is: what about > Record-Route parameters? Seems like these should be copied. The spec > should be clarified in that regard. I am not sure I follow you. Are you proposing that generic Record-Route params are copied into Route? This wouldn't help as any salient parameters would be lost when the preceding Server pops the Route into the Request URI. The spec is already clear about what is copied from where in constructing Route when it comes to URI params. But this has it's own problems if you are banking on getting any params back from there. Which URI would you expect to get it back from as it differs depending whether the caller or callee sends the request. [...] > Neil writes: > > Generic params added to a Record-Route by the Proxy are > > not subsequently returned in the Route. We have been there > > before see the slide 'State pushing through Route' > > in Jonathan's open issues presentation from the 48th > > IETF meeting. > > This is true; a proxy won't get back any Record-Route parameters it > inserts. But, URI parameters will get returned through the request URI. > Implementations of a UAC should be sure to copy the entire URI from the > Record-Routes in the response, into Route in subsequent requests. > Similarly, All URI params in the Contact header in the request > (excepting maddr and port of course), should be copied into Routes used > by the UAS. But from where exactly will a Proxy will get a URI params back? Are you saying it should insert any param it wants back into the URI in the Contact, as well as the Record-Route, in case it comes back from a UAS. I would argue that a Proxy should leave the URIs well alone. For example in state pushing case the idea of a new header would be preferable providing sufficient justification for it's introduction is made. 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 Sep 5 12:40: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 ESMTP id MAA08175 for ; Tue, 5 Sep 2000 12:40: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 41D044436C; Tue, 5 Sep 2000 11:39:59 -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 1B1504435E for ; Tue, 5 Sep 2000 11:39:55 -0400 (EDT) Received: from zrtpd004.us.nortel.com (actually zrtpd004) by ertpg14e1.nortelnetworks.com; Tue, 5 Sep 2000 12:39:14 -0400 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Tue, 5 Sep 2000 12:39:14 -0400 Message-ID: <28560036253BD41191A10000F8BCBD11480D06@zcard00g.ca.nortel.com> From: "Tom-PT Taylor" To: "'Eric Tremblay'" Cc: sip@lists.bell-labs.com, "Robert Sparks (E-mail)" Subject: RE: [SIP] Possible REFER problem? Date: Tue, 5 Sep 2000 12:39:04 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C01757.CD67A810" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com 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_01C01757.CD67A810 Content-Type: text/plain; charset="iso-8859-1" I think the problem you identify is more general than call transfer. It applies whenever it is essential to reach the same UA as a previous call or call leg. The Contact: header is probably the necessary solution -- mimicing an existing call-leg is likely to have undesirable side-effects. > -----Original Message----- > From: Eric Tremblay [mailto:etremblay@mediatrix.com] > Sent: Monday, September 04, 2000 8:24 PM > To: Robert Sparks (E-mail) > Cc: sip@lists.bell-labs.com > Subject: [SIP] Possible REFER problem? > > > Hi, > > I think I see a possible problem with the REFER request in > the context of a > call transfer with consultation: > > Suppose that Transferor and Transferee are connected. Transferor puts > Transferee on hold and calls Transfer Target (TT). After the > brief call > between Transferor and TT, Transferor sends a REFER request > to Transferee: > > Transferor has 2 choices for the URL to put into the Refer-To > header of the > REFER request. It can either use the contact it has received > in the 200 > response of the call with TT or it can use the original URL > it has used to > establish the call to TT (which usually points to a proxy or redirect > server). > > I think that using the contact URL in the Refer-To is not the > best thing to > do because this could bypass some of the system policies that > requires all > calls to go trough a proxy (for tracing, billing or whatever > services). > Note that this is fixed by having TT return a 305 response to > the INVITE > received from Transferee, in which case Transferee should > resend the INVITE > to a proxy. > > On the other hand, when using the original URL in the > Refer-To, I think it > is possible that the call from Transferee to TT will be > routed to a totaly > different destination, probably because the proxy has forked > and someone > else has answered before TT could. > > > I think the problem is as follows: > > How can we make sure that the INVITE from Transferee to TT > will be answered > by the same UA as the INVITE from Transferor to TT? I think > that we want to > allow some mobility to TT, but I also think that we would > like to reach the > exact same UA as the call between Transferor and TT. > > 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. > > First, is this really a problem or I'm forgetting something? > > 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 > ------_=_NextPart_001_01C01757.CD67A810 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [SIP] Possible REFER problem?

I think the problem you identify is more general than = call transfer.  It applies whenever it is essential to reach the = same UA as a previous call or call leg.  The Contact: header is = probably the necessary solution -- mimicing an existing call-leg is = likely to have undesirable side-effects.

> -----Original Message-----
> From: Eric Tremblay [mailto:etremblay@mediatrix.com]
> Sent: Monday, September 04, 2000 8:24 PM
> To: Robert Sparks (E-mail)
> Cc: sip@lists.bell-labs.com
> Subject: [SIP] Possible REFER problem?
>
>
> Hi,
>
> I think I see a possible problem with the REFER = request in
> the context of a
> call transfer with consultation:
>
> Suppose that Transferor and Transferee are = connected.  Transferor puts
> Transferee on hold and calls Transfer Target = (TT).  After the
> brief call
> between Transferor and TT, Transferor sends a = REFER request
> to Transferee:
>
> Transferor has 2 choices for the URL to put = into the Refer-To
> header of the
> REFER request.  It can either use the = contact it has received
> in the 200
> response of the call with TT or it can use the = original URL
> it has used to
> establish the call to TT (which usually points = to a proxy or redirect
> server).
>
> I think that using the contact URL in the = Refer-To is not the
> best thing to
> do because this could bypass some of the system = policies that
> requires all
> calls to go trough a proxy (for tracing, = billing or whatever
> services).
> Note that this is fixed by having TT return a = 305 response to
> the INVITE
> received from Transferee, in which case = Transferee should
> resend the INVITE
> to a proxy.
>
> On the other hand, when using the original URL = in the
> Refer-To, I think it
> is possible that the call from Transferee to TT = will be
> routed to a totaly
> different destination, probably because the = proxy has forked
> and someone
> else has answered before TT could.
>
>
> I think the problem is as follows:
>
> How can we make sure that the INVITE from = Transferee to TT
> will be answered
> by the same UA as the INVITE from Transferor to = TT?  I think
> that we want to
> allow some mobility to TT, but I also think = that we would
> like to reach the
> exact same UA as the call between Transferor = and TT.
>
> 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.
>
> First, is this really a problem or I'm = forgetting something?
>
> 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
>

------_=_NextPart_001_01C01757.CD67A810-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Sep 5 12:47: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 ESMTP id MAA08407 for ; Tue, 5 Sep 2000 12:47: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 40E7F44375; Tue, 5 Sep 2000 11:47:00 -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 E7AF944365 for ; Tue, 5 Sep 2000 11:46:56 -0400 (EDT) Received: from driftwood.cisco.com (driftwood.cisco.com [171.71.157.40]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id JAA15945; Tue, 5 Sep 2000 09:47:16 -0700 (PDT) Received: from cisco.com ([171.71.159.231]) by driftwood.cisco.com (Mirapoint) with ESMTP id ACF01242; Tue, 5 Sep 2000 11:43:44 -0500 (CDT) Message-ID: <39B523C1.3CD12149@cisco.com> Date: Tue, 05 Sep 2000 11:48:01 -0500 From: Hong Chen Organization: Cisco Systems X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: Anders Kristensen , sip@lists.bell-labs.com Subject: Re: [SIP] SIP feature services References: <39AEACDE.F5686B52@cisco.com> <39AF5E23.A98F4EC9@dynamicsoft.com> <39AFD999.AAE9F83@cisco.com> <39AFF3AC.B71D4C5@dynamicsoft.com> <39AFFB3A.7FA1C772@cisco.com> <39B1D6C1.2CBEA6D4@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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > Hong Chen wrote: > > > > > Request URIs won't (usually) contain info that identifies services to be > > > invoked. Maybe you subscribe to feature-i at some proxy -- it is then up > > > to that proxy to figure out to apply feature-i to your calls. > > > > > > > Yes, some services can be subscribed by users and can be trigged inside SIP > > proxy. > > But the issues are: > > - Do we need to define the trig points (for both originating and > > terminating trigs) and their conditions in Proxy? > > A trigger point is simply some kind of system event that is useful for > the purposes of doing something service related. SIP as a protocol > defines various state machines and messages, any of which might serve as > a useful trigger for doing something. I see no need for any additional > standardization. I agree that additional standardization may not be necessary, but a standard call model for sip proxy may help for the feature developments and interpretability. > > > > This could be a design and implementation issue. > > - Further more, it may not be possible to define and implement trigs for > some > > feature services. > > How can we handle these services by SIP? > > I cannot answer that without some examples or a more precise definition. > EX.. of features which need network controls and hard to define trigs in sip proxy. (1) Call Park (Park a call and then pick the call later somewhere else). (2) Call Pick Up (Answer a call which is ringing somewhere else in a call pick up group). (3) Adhoc conference using centralized conference bridge. and more. Thanks, > > > - How can we use SIP to implement user based and/or call based feature > > services? > > Has that not been the discussion of this thread to date? As Anders has > pointed out, the services are encapsulated within the logic of proxies > and other SIP devices along the session establishment path. > > -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 Sep 5 13:16: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 ESMTP id NAA09183 for ; Tue, 5 Sep 2000 13:16: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 5087C44365; Tue, 5 Sep 2000 12:16:10 -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 1EE594435E for ; Tue, 5 Sep 2000 12:16:07 -0400 (EDT) Received: from driftwood.cisco.com (driftwood.cisco.com [171.71.157.40]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id KAA27210; Tue, 5 Sep 2000 10:16:24 -0700 (PDT) Received: from cisco.com ([171.71.159.231]) by driftwood.cisco.com (Mirapoint) with ESMTP id ACF01417; Tue, 5 Sep 2000 12:12:53 -0500 (CDT) Message-ID: <39B52A96.6A9802CD@cisco.com> Date: Tue, 05 Sep 2000 12:17:10 -0500 From: Hong Chen Organization: Cisco Systems X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: farhan Cc: sip Subject: Re: [SIP] SIP] SIP feature services References: <000301c014ba$444c5660$8d14c5cb@bigboy> Content-Type: multipart/alternative; boundary="------------4D7F7408F6CC8D565ABFE98F" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com --------------4D7F7408F6CC8D565ABFE98F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit farhan wrote: > i guess this is a reprise of what i was trying to figure out somewhile ago > on this list ... > > if an application server is capable of offering a service, it is agreed that > the proxies need have no understanding of the service beyong plain message > forwarding. accepted. True. But the forwarding trig condition and forward destination need to be defined somewhere and sometime in the call. > > > should a client UA be aware and have specially programmed features to make > use of the service being offered by a server? the answer SHOULD be No. > Ideally a service should be accesible from any SIP UA that has a few basic > capabilities built-in. With intelligent SIP phone, feature services should be distributed to both edge intelligent devices and core AS. The issue is how to invoke some core AS for some feature services and also it is hard to define the trigs for these services. > > > take your POTS phone for instance. the phone instrument is not aware of the > fact that I am dialing the changed number service, listening to the > instructions, punching in the old number and hearing the changed number > being read out. this is all being done without the phone instrument being > aware of the application level interactivity. > The key point here is feature service invocation, not the feature service interaction. Yes, "you are dialing changed number service" which invokes the change number service by dialing a specific number!!! > > i would expect the same sort of genralised interactivity to be possible > within the SIP framwork. i will therfore argue for a method that prompts and > accepts text input from the user (through the user agent) and another method > that will diplay simple text messages. This is what MESSAGE does already > and we may possibly need something like a PROMPT method (displaying a prompt > and getting a user response). A poor man's equivalent of sip forms (aka HTML > forms). > > Just like there are a lot of people building great applications over SMS > service, I expect that we will also build some great apps riding over > MESSAGE/PROMPT (or whatever the scheme is). > > As Dr. Rosenberg pointed out on this list a couple of days ago, MESSAGE is > not restricted to just plain text. I can send URLs that point to HTML forms, > media streams (even another sip url!!!, hehe okay okay we are not > redirecting anything here...) and the works. > > the interactivity paradigm using messages is dialog based (I dont mean the > dialog windows, but textual dialogs). People who have played MUD in their > younger days (or dotage) will remember what it was like. > > - farhan > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip --------------4D7F7408F6CC8D565ABFE98F Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit  

farhan wrote:

i guess this is a reprise of what i was trying to figure out somewhile ago
on this list ...

if an application server is capable of offering a service, it is agreed that
the proxies need have no understanding of the service beyong plain message
forwarding. accepted.

True. But the forwarding trig condition and forward destination need to be defined somewhere and sometime in the call.
 
 

should a client UA be aware and have specially programmed features to make
use of the service being offered by a server? the answer SHOULD be No.
Ideally a service should be accesible from any SIP UA that has a few basic
capabilities built-in.

With intelligent SIP phone, feature services should be distributed to both edge intelligent devices and core AS.
The issue is how to invoke some core AS for some feature services and also it is hard to define the trigs for these services.
 

take your POTS phone for instance. the phone instrument is not aware of the
fact that  I am dialing the changed number service, listening to the
instructions, punching in the old number and hearing the changed number
being read out. this is all being done without the phone instrument being
aware of the application level interactivity.
 

The key point here is feature service invocation, not the feature service interaction.
Yes, "you are dialing changed number service" which invokes the change number
service by dialing a specific number!!!
 
i would expect the same sort of genralised interactivity to be possible
within the SIP framwork. i will therfore argue for a method that prompts and
accepts text input from the user (through the user agent) and another method
that will diplay simple text messages. This is  what MESSAGE does already
and we may possibly need something like a PROMPT method (displaying a prompt
and getting a user response). A poor man's equivalent of sip forms (aka HTML
forms).

Just like there are a lot of people building great applications over SMS
service, I expect that we will also build some great apps riding over
MESSAGE/PROMPT (or whatever the scheme is).

As Dr. Rosenberg pointed out on this list a couple of days ago, MESSAGE is
not restricted to just plain text. I can send URLs that point to HTML forms,
media streams (even another sip url!!!, hehe okay okay we are not
redirecting anything here...) and the works.

the interactivity paradigm using messages is dialog based (I dont mean the
dialog windows, but textual dialogs). People who have played MUD in their
younger days (or dotage) will remember what it was like.

- farhan

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

--------------4D7F7408F6CC8D565ABFE98F-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Sep 5 13:32: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 ESMTP id NAA09491 for ; Tue, 5 Sep 2000 13:32: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 2EEAC44382; Tue, 5 Sep 2000 12:31:38 -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 E789F4435F for ; Tue, 5 Sep 2000 12:31:34 -0400 (EDT) Received: from driftwood.cisco.com (driftwood.cisco.com [171.71.157.40]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id KAA10699; Tue, 5 Sep 2000 10:31:51 -0700 (PDT) Received: from cisco.com ([171.71.159.231]) by driftwood.cisco.com (Mirapoint) with ESMTP id ACF01494; Tue, 5 Sep 2000 12:28:22 -0500 (CDT) Message-ID: <39B52E37.703E89B@cisco.com> Date: Tue, 05 Sep 2000 12:32:39 -0500 From: Hong Chen Organization: Cisco Systems X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Henning Schulzrinne Cc: Jonathan Rosenberg , Anders Kristensen , sip@lists.bell-labs.com Subject: Re: [SIP] SIP feature services References: <39AEACDE.F5686B52@cisco.com> <39AF5E23.A98F4EC9@dynamicsoft.com> <39AFD999.AAE9F83@cisco.com> <39AFF3AC.B71D4C5@dynamicsoft.com> <39AFFB3A.7FA1C772@cisco.com> <39B1D6C1.2CBEA6D4@dynamicsoft.com> <39B523C1.3CD12149@cisco.com> <39B52581.1201477A@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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > Hong Chen wrote: > > > > Jonathan Rosenberg wrote: > > > I agree that additional standardization may not be necessary, but a standard call > > model > > for sip proxy may help for the feature developments and interpretability. > > Attempts at a call model have been made by various people. See the draft > archives. Whether they are useful is another question. > > > > > EX.. of features which need network controls and hard to define trigs in sip proxy. > > (1) Call Park (Park a call and then pick the call later somewhere else). > > (2) Call Pick Up (Answer a call which is ringing somewhere else in a call pick up > > group). > > (3) Adhoc conference using centralized conference bridge. > > and more. > > These services were discussed extensively on this list a number of weeks > ago (see the list archives), with different solutions proposed, since it > doesn't make sense to translate the behavior exactly from PSTN to IP. > Conferencing is also addressed in the SIP FAQ and requires no SIP proxy. > (1) It may not make sense to translate the behavior exactly from PSTN to IP, but people are still looking for those traditional services. (2) The key point here is: There may be hundred suggested different ways for some service by SIP signaling. The question is which is the best systematic mechanism we should follow and we can also easily use this same systematic mechanism for any new feature service later. > > -- > 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 Sep 5 14: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 ESMTP id OAA10224 for ; Tue, 5 Sep 2000 14:03: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 968AB4435F; Tue, 5 Sep 2000 13:03:37 -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 CA84444352 for ; Tue, 5 Sep 2000 11:55:48 -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 MAA02390; Tue, 5 Sep 2000 12:55:29 -0400 (EDT) Message-ID: <39B52581.1201477A@cs.columbia.edu> Date: Tue, 05 Sep 2000 12:55:29 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Hong Chen Cc: Jonathan Rosenberg , Anders Kristensen , sip@lists.bell-labs.com Subject: Re: [SIP] SIP feature services References: <39AEACDE.F5686B52@cisco.com> <39AF5E23.A98F4EC9@dynamicsoft.com> <39AFD999.AAE9F83@cisco.com> <39AFF3AC.B71D4C5@dynamicsoft.com> <39AFFB3A.7FA1C772@cisco.com> <39B1D6C1.2CBEA6D4@dynamicsoft.com> <39B523C1.3CD12149@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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Hong Chen wrote: > > Jonathan Rosenberg wrote: > I agree that additional standardization may not be necessary, but a standard call > model > for sip proxy may help for the feature developments and interpretability. Attempts at a call model have been made by various people. See the draft archives. Whether they are useful is another question. > > EX.. of features which need network controls and hard to define trigs in sip proxy. > (1) Call Park (Park a call and then pick the call later somewhere else). > (2) Call Pick Up (Answer a call which is ringing somewhere else in a call pick up > group). > (3) Adhoc conference using centralized conference bridge. > and more. These services were discussed extensively on this list a number of weeks ago (see the list archives), with different solutions proposed, since it doesn't make sense to translate the behavior exactly from PSTN to IP. Conferencing is also addressed in the SIP FAQ and requires no SIP 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 Tue Sep 5 14:24: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 ESMTP id OAA10678 for ; Tue, 5 Sep 2000 14:24: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 EDBF144383; Tue, 5 Sep 2000 13:23:54 -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 194264435E for ; Tue, 5 Sep 2000 13:23:51 -0400 (EDT) Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprch1.nortel.com; Tue, 5 Sep 2000 12:44:41 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Tue, 5 Sep 2000 12:42:18 -0500 Message-ID: <28560036253BD41191A10000F8BCBD11480D07@zcard00g.ca.nortel.com> From: "Tom-PT Taylor" To: "'Hong Chen'" , Henning Schulzrinne Cc: Jonathan Rosenberg , Anders Kristensen , sip@lists.bell-labs.com Subject: RE: [SIP] SIP feature services Date: Tue, 5 Sep 2000 12:42:15 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C01760.A1128A60" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com 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_01C01760.A1128A60 Content-Type: text/plain; charset="iso-8859-1" The answer to all this that I'm seeing in my admittedly limited experience is that individual networks define how they want services to operate and expect vendors to support the resulting information flows. > -----Original Message----- > From: Hong Chen [mailto:hjlechen@cisco.com] > Sent: Tuesday, September 05, 2000 1:33 PM > To: Henning Schulzrinne > Cc: Jonathan Rosenberg; Anders Kristensen; sip@lists.bell-labs.com > Subject: Re: [SIP] SIP feature services > > > > > Henning Schulzrinne wrote: > > > Hong Chen wrote: > > > > > > Jonathan Rosenberg wrote: > > > > > I agree that additional standardization may not be > necessary, but a standard call > > > model > > > for sip proxy may help for the feature developments and > interpretability. > > > > Attempts at a call model have been made by various people. > See the draft > > archives. Whether they are useful is another question. > > > > > > > > EX.. of features which need network controls and hard to > define trigs in sip proxy. > > > (1) Call Park (Park a call and then pick the call later > somewhere else). > > > (2) Call Pick Up (Answer a call which is ringing > somewhere else in a call pick up > > > group). > > > (3) Adhoc conference using centralized conference bridge. > > > and more. > > > > These services were discussed extensively on this list a > number of weeks > > ago (see the list archives), with different solutions > proposed, since it > > doesn't make sense to translate the behavior exactly from > PSTN to IP. > > Conferencing is also addressed in the SIP FAQ and requires > no SIP proxy. > > > > (1) It may not make sense to translate the behavior exactly > from PSTN to IP, but people > are still looking for > those traditional services. > > (2) The key point here is: > There may be hundred suggested different ways for > some service by SIP signaling. > The question is which is the best systematic > mechanism we should follow and we > can also easily > use this same systematic mechanism for any new > feature service later. > > > > > > > -- > > 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_01C01760.A1128A60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [SIP] SIP feature services

The answer to all this that I'm seeing in my = admittedly limited experience is that individual networks define how = they want services to operate and expect vendors to support the = resulting information flows.

> -----Original Message-----
> From: Hong Chen [mailto:hjlechen@cisco.com]=
> Sent: Tuesday, September 05, 2000 1:33 = PM
> To: Henning Schulzrinne
> Cc: Jonathan Rosenberg; Anders Kristensen; = sip@lists.bell-labs.com
> Subject: Re: [SIP] SIP feature services
>
>
>
>
> Henning Schulzrinne wrote:
>
> > Hong Chen wrote:
> > >
> > > Jonathan Rosenberg wrote:
> >
> > > I agree that additional = standardization may not be
> necessary, but  a standard call
> > > model
> > > for sip proxy may help for the = feature developments and
> interpretability.
> >
> > Attempts at a call model have been made by = various people.
> See the draft
> > archives. Whether they are useful is = another question.
> >
> > >
> > > EX.. of features which need network = controls and hard to
> define trigs in sip proxy.
> > > (1) Call Park (Park a call and then = pick the call later
> somewhere else).
> > > (2) Call Pick Up (Answer a call which = is ringing
> somewhere else in a call pick up
> > > group).
> > > (3) Adhoc conference using = centralized conference bridge.
> > >  and more.
> >
> > These services were discussed extensively = on this list a
> number of weeks
> > ago (see the list archives), with = different solutions
> proposed, since it
> > doesn't make sense to translate the = behavior exactly from
> PSTN to IP.
> > Conferencing is also addressed in the SIP = FAQ and requires
> no SIP proxy.
> >
>
> (1) It may not make sense to translate the = behavior exactly
> from PSTN to IP, but people
> are still looking for
> those traditional services.
>
> (2) The key point here is:
>         = There may be hundred suggested different ways for
> some service by SIP signaling.
>         = The question is which is the best systematic
> mechanism we should follow and we
> can also easily
>         = use this same systematic mechanism for any new
> feature service later.
>
>
>
> >
> > --
> > 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_01C01760.A1128A60-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Sep 5 14:44: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 ESMTP id OAA11064 for ; Tue, 5 Sep 2000 14:44: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 AFD214436F; Tue, 5 Sep 2000 13:43:29 -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 372B54435F for ; Tue, 5 Sep 2000 13:43:26 -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 e85IhL405658 for ; Tue, 5 Sep 2000 21:43:21 +0300 (EET DST) Received: by daebh01nok with Internet Mail Service (5.5.2448.0) id ; Tue, 5 Sep 2000 13:40:19 -0500 Message-ID: From: Cliff.Harris@nokia.com To: sip@lists.bell-labs.com Subject: RE: [SIP] Possible REFER problem? Date: Tue, 5 Sep 2000 13:37:18 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Jonathan Rosenberg wrote > No. It would not be routed to a "totally" different location. > Forking in > SIP is not meant to be a randomization process; its meant to > be a means > of finding the user where they are currently available. In a > reasonable > SIP system, if they are available at some destination for a > first call, > a second call should be able to "ring" that same phone as well. > 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). _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Sep 5 14:57: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 ESMTP id OAA11269 for ; Tue, 5 Sep 2000 14:57: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 A8D3544379; Tue, 5 Sep 2000 13:57:21 -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 800D74435E for ; Tue, 5 Sep 2000 13:57:18 -0400 (EDT) Received: from dynamicsoft.com (1Cust235.tnt1.freehold.nj.da.uu.net [63.17.113.235]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id OAA07067; Tue, 5 Sep 2000 14:59:02 -0400 (EDT) Message-ID: <39B541CF.22DC6383@dynamicsoft.com> Date: Tue, 05 Sep 2000 14:56:15 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Cliff.Harris@nokia.com Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Possible REFER problem? 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Cliff.Harris@nokia.com wrote: > > Jonathan Rosenberg wrote > > No. It would not be routed to a "totally" different location. > > Forking in > > SIP is not meant to be a randomization process; its meant to > > be a means > > of finding the user where they are currently available. In a > > reasonable > > SIP system, if they are available at some destination for a > > first call, > > a second call should be able to "ring" that same phone as well. > > > > 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. -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 Sep 5 15:05: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 ESMTP id PAA11418 for ; Tue, 5 Sep 2000 15:05: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 9988344390; Tue, 5 Sep 2000 14:04:44 -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 0752744388 for ; Tue, 5 Sep 2000 14:04:41 -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 e85J4Z416300; Tue, 5 Sep 2000 22:04:36 +0300 (EET DST) Received: by daebh01nok with Internet Mail Service (5.5.2448.0) id ; Tue, 5 Sep 2000 14:01:33 -0500 Message-ID: From: Cliff.Harris@nokia.com To: jdrosen@dynamicsoft.com Cc: sip@lists.bell-labs.com Subject: RE: [SIP] Possible REFER problem? Date: Tue, 5 Sep 2000 13:58:29 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Jonathan Rosenberg wrote > Cliff.Harris@nokia.com wrote: > > > > Jonathan Rosenberg wrote > > > No. It would not be routed to a "totally" different location. > > > Forking in > > > SIP is not meant to be a randomization process; its meant to > > > be a means > > > of finding the user where they are currently available. In a > > > reasonable > > > SIP system, if they are available at some destination for a > > > first call, > > > a second call should be able to "ring" that same phone as well. > > > > > > > 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". _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Sep 5 15: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 ESMTP id PAA11621 for ; Tue, 5 Sep 2000 15:13: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 23BBD44375; Tue, 5 Sep 2000 14:11:49 -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 952834435F for ; Tue, 5 Sep 2000 14:11:46 -0400 (EDT) Received: from zrtpd004.us.nortel.com (actually zrtpd004) by ertpg14e1.nortelnetworks.com; Tue, 5 Sep 2000 15:11:13 -0400 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Tue, 5 Sep 2000 15:11:12 -0400 Message-ID: <28560036253BD41191A10000F8BCBD11480D0F@zcard00g.ca.nortel.com> From: "Tom-PT Taylor" To: "'Cliff.Harris@nokia.com'" , jdrosen@dynamicsoft.com Cc: sip@lists.bell-labs.com Subject: RE: [SIP] Possible REFER problem? Date: Tue, 5 Sep 2000 15:11:03 -0400 X-Mailer: Internet Mail Service (5.5.2652.35) Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com I see use of Contact: to select the exact destination as the equivalent of "Call operator 58" back when operators routed most calls. > -----Original Message----- > From: Cliff.Harris@nokia.com [mailto:Cliff.Harris@nokia.com] > Sent: Tuesday, September 05, 2000 2:58 PM > To: jdrosen@dynamicsoft.com > Cc: sip@lists.bell-labs.com > Subject: RE: [SIP] Possible REFER problem? > > > Jonathan Rosenberg wrote > > Cliff.Harris@nokia.com wrote: > > > > > > Jonathan Rosenberg wrote > > > > No. It would not be routed to a "totally" different location. > > > > Forking in > > > > SIP is not meant to be a randomization process; its meant to > > > > be a means > > > > of finding the user where they are currently available. In a > > > > reasonable > > > > SIP system, if they are available at some destination for a > > > > first call, > > > > a second call should be able to "ring" that same phone as well. > > > > > > > > > > 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". > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > 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 Sep 5 15:31: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 ESMTP id PAA12422 for ; Tue, 5 Sep 2000 15:31: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 04B5F4435F; Tue, 5 Sep 2000 14:31:39 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from microappliances.com (unknown [216.103.255.138]) by lists.bell-labs.com (Postfix) with SMTP id 6693A4435E for ; Tue, 5 Sep 2000 14:31:35 -0400 (EDT) Received: (qmail 93310 invoked by uid 100); 5 Sep 2000 19:31:23 -0000 Date: 5 Sep 2000 19:31:23 -0000 Message-ID: <20000905193123.93309.qmail@microappliances.com> From: shh@microappliances.com To: Cliff.Harris@nokia.com Reply-To: shh@microappliances.com Cc: sip@lists.bell-labs.com References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit Subject: RE: [SIP] Possible REFER problem? Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 8bit Quoting Cliff.Harris@nokia.com: > > Jonathan Rosenberg wrote > > No. It would not be routed to a \"totally\" different location. > > Forking in > > SIP is not meant to be a randomization process; its meant to > > be a means > > of finding the user where they are currently available. In a > > reasonable > > SIP system, if they are available at some destination for a > > first call, > > a second call should be able to \"ring\" that same phone as well. > > > > 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). > One can do this using registrations and playing around with \'q\' parameters. You can make all 5 phones ring at the same time or make them ring in groups. However making them ring in a round robin may require some other trick. Shiv > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > 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 Sep 5 16:03: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 ESMTP id QAA12815 for ; Tue, 5 Sep 2000 16:03: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 843534437D; Tue, 5 Sep 2000 15:02:38 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from microappliances.com (unknown [216.103.255.138]) by lists.bell-labs.com (Postfix) with SMTP id 4AB764435E for ; Tue, 5 Sep 2000 15:02:34 -0400 (EDT) Received: (qmail 95985 invoked by uid 100); 5 Sep 2000 20:02:21 -0000 Date: 5 Sep 2000 20:02:21 -0000 Message-ID: <20000905200221.95984.qmail@microappliances.com> From: shh@microappliances.com To: Henning Schulzrinne Reply-To: shh@microappliances.com Cc: Neil Deason , sip@lists.bell-labs.com References: <002e01c011c2$94a85000$4e34c3c1@ubiquity.co.uk> <39AC83A0.68A61CA@dynamicsoft.com> <39AE1096.95161017@uab.ericsson.se> <39AE38A0.526A55F8@ubiquity.net> <39AF4ADB.B8751B55@dynamicsoft.com> <39AF51F7.CDBFE713@ericsson.fi> <39AF563A.8EEB995@dynamicsoft.com> <39AF7E14.FE7886BB@ubiquity.net> <39B06683.FE987438@dynamicsoft.com> <39B34DAC.5AFF899F@ubiquity.net> <39B3DF70.46752EC9@cs.columbia.edu> In-Reply-To: <39B3DF70.46752EC9@cs.columbia.edu> MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit Subject: Re: [SIP] transaction identification Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 8bit Quoting Henning Schulzrinne : > > Unless there\'s loud protest, it will vanish soon, so speak up if you\'re > fond of Via hiding. > I should start by saying I am not fond of Via hiding. It will make me happy if is goes away. However, I see an overall problem in SIP+SDP as being leaking internal network topololgy information. Firewalls go out of the way to hide this kind of information, which SIP is giving away. I think a narrow scope of attempting to hide only the topology should suffice. Hiding every hop is probably not necessary. Problem areas should include \'Contact:\' and SDP. Shiv _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Sep 5 16:16: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 ESMTP id QAA13003 for ; Tue, 5 Sep 2000 16: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 C94B244389; Tue, 5 Sep 2000 15:15:35 -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 B52BA44384 for ; Tue, 5 Sep 2000 15:15:29 -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 NAA14711; Tue, 5 Sep 2000 13:15:49 -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 AAC45044; Tue, 5 Sep 2000 13:15:27 -0700 (PDT) Message-Id: <4.2.0.58.20000905130601.00c29df0@imop.cisco.com> X-Sender: rmahy@imop.cisco.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Tue, 05 Sep 2000 13:12:25 -0700 To: shh@microappliances.com From: Rohan Mahy Subject: RE: [SIP] Possible REFER problem? Cc: Cliff.Harris@nokia.com, sip@lists.bell-labs.com In-Reply-To: <20000905193123.93309.qmail@microappliances.com> References: 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Hi, I think you are missing the point. Sure you can play around with q values to affect how the call is initially routed. Cliff wants the *initial* INVITE to ring all 5 phones at once, and the REFER-triggered INVITE to arrive at just the Contact that will accept the "transfer." Seems natural to use the Contact as the Request-URI. thanks, -rohan At 12:31 PM 9/5/00 , shh@microappliances.com wrote: >Quoting Cliff.Harris@nokia.com: > > > > > Jonathan Rosenberg wrote > > > No. It would not be routed to a \"totally\" different location. > > > Forking in > > > SIP is not meant to be a randomization process; its meant to > > > be a means > > > of finding the user where they are currently available. In a > > > reasonable > > > SIP system, if they are available at some destination for a > > > first call, > > > a second call should be able to \"ring\" that same phone as well. > > > > > > > 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). > > > >One can do this using registrations and playing around with \'q\' >parameters. You can make all 5 phones ring at the same time >or make them ring in groups. However making them ring in a round >robin may require some other trick. > >Shiv > > > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > 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 Sep 5 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 ESMTP id QAA13170 for ; Tue, 5 Sep 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 6F0C844381; Tue, 5 Sep 2000 15:27:36 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from microappliances.com (unknown [216.103.255.138]) by lists.bell-labs.com (Postfix) with SMTP id DEAEA4435F for ; Tue, 5 Sep 2000 15:27:31 -0400 (EDT) Received: (qmail 98325 invoked by uid 100); 5 Sep 2000 20:27:19 -0000 Date: 5 Sep 2000 20:27:19 -0000 Message-ID: <20000905202719.98324.qmail@microappliances.com> From: shh@microappliances.com To: Rohan Mahy Reply-To: shh@microappliances.com Cc: shh@microappliances.com, Cliff.Harris@nokia.com, sip@lists.bell-labs.com References: <4.2.0.58.20000905130601.00c29df0@imop.cisco.com> In-Reply-To: <4.2.0.58.20000905130601.00c29df0@imop.cisco.com> MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit Subject: RE: [SIP] Possible REFER problem? Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 8bit Oops. Right. I did the see the entire context of the thread. Shiv Quoting Rohan Mahy : > Hi, > > I think you are missing the point. Sure you can play around with q values > to affect how the call is initially routed. Cliff wants the *initial* > INVITE to ring all 5 phones at once, and the REFER-triggered INVITE to > arrive at just the Contact that will accept the \"transfer.\" > > Seems natural to use the Contact as the Request-URI. > > thanks, > -rohan > > At 12:31 PM 9/5/00 , shh@microappliances.com wrote: > > > >Quoting Cliff.Harris@nokia.com: > > > > > > > > Jonathan Rosenberg wrote > > > > No. It would not be routed to a \\\"totally\\\" different location. > > > > Forking in > > > > SIP is not meant to be a randomization process; its meant to > > > > be a means > > > > of finding the user where they are currently available. In a > > > > reasonable > > > > SIP system, if they are available at some destination for a > > > > first call, > > > > a second call should be able to \\\"ring\\\" that same phone as well. > > > > > > > > > > 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). > > > > > > >One can do this using registrations and playing around with \\\'q\\\' > >parameters. You can make all 5 phones ring at the same time > >or make them ring in groups. However making them ring in a round > >robin may require some other trick. > > > >Shiv > > > > > > > > > > _______________________________________________ > > > SIP mailing list > > > SIP@lists.bell-labs.com > > > 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 Sep 6 02:53: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 ESMTP id CAA04801 for ; Wed, 6 Sep 2000 02:53: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 CD3EC4435F; Wed, 6 Sep 2000 01:53:53 -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 6A6EA4433F for ; Wed, 6 Sep 2000 01:53:50 -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 GAA28413 for ; Wed, 6 Sep 2000 06:53:47 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 AAA26536 for ; Wed, 6 Sep 2000 00:53:27 -0600 (MDT) Received: by n0195idc1.oss.level3.com with Internet Mail Service (5.5.2650.21) id ; Wed, 6 Sep 2000 00:55:15 -0600 Message-ID: <87A245E94948D3118DE30008C716B01301523B24@c0005v1idc1.oss.level3.com> To: sip@lists.bell-labs.com Date: Wed, 6 Sep 2000 00:53:25 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] tel URL v. SIP URL Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com I note that in 2543bis the 'np-queried' parameter has been removed from the SIP URL, since a mechanism is now available in the tel URL to support local number portability (draft-yu-tel-url-00.txt?). Is this an indication that, in the long term, the SIP URL is not a preferred manner to carry telephone numbers, especially LRNs? Previously, I had thought the only germane distinction between the two was the absence of a host portion (and hence rules that do not allow the inclusion of the tel URL in headers that are used in hop-by-hop routing like Contact); the tacit host component of the tel URL in a Request-URI would be the UA at which the network (proxies using local routing tables or ENUM or what have you) feels this call should terminate. If only the tel URL can carry number portability information, though, then presumably all np-queried calls will have to be transmitted in tel URL format. It seems to me that there might be services that would like to rely on host-based routing even after np-queries have taken place - calls that began with SIP URLs, which are subsequently dipped by, say, a native SIP LNP application, might be forced to shed host information that was important to the desired routing of the call. Is the general sentiment that the SIP URL should not have to support number portability? Jon Peterson Level(3) Communications _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Sep 6 07: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 ESMTP id HAA07650 for ; Wed, 6 Sep 2000 07:13: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 C3D9B4439D; Wed, 6 Sep 2000 06:13:09 -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 674994435E for ; Tue, 5 Sep 2000 16:26:53 -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 OAA11320 for ; Tue, 5 Sep 2000 14:29:04 -0700 Message-ID: <39B565A0.1124BDC3@mobilerain.com> Date: Tue, 05 Sep 2000 14:29:04 -0700 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: sip@lists.bell-labs.com Subject: [SIP] IM Questions Content-Type: multipart/mixed; boundary="------------9DD26FA71902B41A8A251AD5" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com This is a multi-part message in MIME format. --------------9DD26FA71902B41A8A251AD5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Greetings: I have been reading the draft [draft-rosenberg-impp-im-00.txt] and have the following questions: a. In section 4.1 Message flow, the message F4 has two "Via" headers. Is this an error since the proxy should have popped the topmost "Via"? b. The draft does not outline support for multiple users (2+). How will the communication happen? What will be the message flow? c. How are dynamic users added to a buddy list? Can a REGISTER message be generated to perform the dynamic addition? Any information on the above is appreciated. Regards, Bobby Sardana. MobileRain Technologies, Inc. bobby.sardana@mobilerain.com --------------9DD26FA71902B41A8A251AD5 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 --------------9DD26FA71902B41A8A251AD5-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Sep 6 07: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 ESMTP id HAA07698 for ; Wed, 6 Sep 2000 07:16: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 D4A49443A3; Wed, 6 Sep 2000 06:13:28 -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 D25264433F for ; Tue, 5 Sep 2000 22:30:29 -0400 (EDT) Received: from intervoice-brite.com ([172.16.16.64]) by ivigate.intervoice.com (Build 98 8.9.3/NT-8.9.3) with SMTP id WAA24328 for ; Tue, 05 Sep 2000 22:33:09 -0500 Received: from INTERVOICE-Message_Server by intervoice-brite.com with Novell_GroupWise; Tue, 05 Sep 2000 22:30:33 -0500 Message-Id: X-Mailer: Novell GroupWise 5.2 Date: Tue, 05 Sep 2000 22:30:14 -0500 From: "Skip Cave" To: sip@lists.bell-labs.com Subject: [SIP] Two Keystroke Encodings Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com My last post on this subject did not get any discussion. This usually means that everyone agrees, or no one understood it. Since what I was preposing was fairly radical, I assume the no-response was because of my poor description of the issue, and resulting incomprehension. I will try again, and this time I won't mix together so many issues in one post. Henning and Jonathan have shown generally how RTP can be used as a mechanism to carry keystrokes. They have shown how the delivery can be made reliable. This clears several significant hurdles in the path towards using RTP as a practical keystroke transport method. There are only a few remaining issues. The following discussion addresses the next critical issue. Colin Perkins writes: > I suggest you read RFC 2793 which describes how to use > RFC 2198 redundancy as a `reliable' transport for non-audio keystrokes. >http://lists.bell-labs.com/pipermail/sip/2000q3/002113.html RFC 2793 - "RTP Payload for Text Conversation" is an RFC which I had somehow overlooked (thank you, Colin) which proposes a method to use RTP to transport T.140 "text conversation" sessions. So, the IETF now has two different protocols to transmit exactly the same data - keystrokes - over RTP: RFC 2833, and RFC 2793. The primary difference between the two protocols is simply the encoding of the keystrokes. RFC 2833 uses the following encoding for keys: Event encoding (decimal) _________________________ 0--9 0--9 * 10 # 11 A--D 12--15 RFC 2833 doesn't define encodings for any other keys. It seems to assume that all devices will only have a maximum of 16 keys. RFC 2793 proposes ISO/IEC 10646-1, level 3 (Unicode) encoding to define a much larger set of keys, but the 16 keys defined in RFC 2833 are also included in the RFC 2973 encoding: 0x0030 DIGIT ZERO 0x0031 DIGIT ONE 0x0032 DIGIT TWO 0x0033 DIGIT THREE 0x0034 DIGIT FOUR 0x0035 DIGIT FIVE 0x0036 DIGIT SIX 0x0037 DIGIT SEVEN 0x0038 DIGIT EIGHT 0x0039 DIGIT NINE ....... 0x0041 LATIN CAPITAL LETTER A 0x0042 LATIN CAPITAL LETTER B 0x0043 LATIN CAPITAL LETTER C 0x0044 LATIN CAPITAL LETTER D ......... 0x002A ASTERISK 0x0023 NUMBER SIGN ....... As you can see, the two protocols have two vastly different ways to encode exactly the same thing - numeric & alphabetic keys on a terminal device. Some other issues with the two protocols: RFC 2833 allows the transmission of keystrokes from a terminal over RTP. However, RFC 2833 also defines a large set of other events besides keystrokes that can be carried in the same RTP stream format: o DTMF tones (Section 3.10); o fax-related tones (Section 3.11); o standard subscriber line tones (Section 3.12); o country-specific subscriber line tones (Section 3.13) and; o trunk events (Section 3.14). While this multiple-event-type property may be useful in some PSTN transport applications, it is definitely not appropriate as a general keystroke communications mechanism. Many applications will not want anything but keystrokes to come over the RTP session - no audio, no fax tones. RFC 2793 also allows the transmission of keystrokes from a terminal over RTP. This RFC uses ISO/IEC 10646-1, level 3 to define a much larger set of possible keys, but the keys on a 12-button terminal device are all included in the larger set. This RFC does not include any other event types except keystrokes, but RFC 2793 does not include a method to carry keystroke duration as a function of the protocol. So to summarize: RFC 2833 1) doesn't cover all of the possible keys available in a terminal device 2) carries extra stuff besides keystrokes in the protocol RFC 2793 1) Doesn't carry keystroke duration information. Meanwhile, both protocols use the same redundancy mechanism (RFC 2198) for more reliable delivery of keystrokes. My issue: As a general rule, a device establishing a SIP session with another device should not have to discover what type of device it is sessioning with before knowing whether to send keystrokes using RFC 2833 or RFC 2793 over the RTP session. There should be only one protocol and one encoding for keystrokes in SIP and RTP, regardless of the device that has the keys on it. My solution: Combine the best of RFC 2833 and RFC 2793 for a universal keystroke protocol. 1) Use RFC 2793's encoding scheme for all keys along with T.140 protocol stucture 2) Use RFC 2833's duration scheme for keystroke durations 3) Use RFC 2198 for reliability 4) Remove the DTMF keystroke events from from Section 3 of RFC 2833 and keep that protocol format specifically for telephony events (fax tones, subscriber line tones, etc.). 5) Add a new payload format in RFC 2833 that is specifically for keystrokes using the 2833-2973 hybrid protocol. In this way, you could INVITE only the 2833-2973 hybrid protocol if you wanted just keystrokes, or you could INVITE the RTP audio also, or just the telephony events, or any combination using SDP media control mechanisms (m=3D) In my company's applications we plan to establish SIP sessions with PSTN/SIP Gateways, Softswitches, SIP phones, SIP mobile devices, and SIP PCs. The key input from all of these different sources should use the same protocol. The key input that we send to all of these devices should use the same protocol. We don't want to have to use different protocols to send keystrokes to a SIP gateway, a SIP wireless device, a Softswitch, or a PC. We don't want to have to know ahead of time what type of device we are calling to determine what kind of session to INVITE to get keystrokes. The keystroke protocol for all devices that have keys should be the same. If PSTN transport application developers vendors want to stick fax tones and call progress in with the compressed audio in a gateway-to-gateway RTP session, that's fine. Just don't make everybody have to support those events when all you want are keystrokes. Skip Cave _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Sep 6 07:18: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 ESMTP id HAA07739 for ; Wed, 6 Sep 2000 07:18: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 34ABB443AA; Wed, 6 Sep 2000 06:13:54 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from hotmail.com (f23.law7.hotmail.com [216.33.237.23]) by lists.bell-labs.com (Postfix) with ESMTP id 90C224433F for ; Tue, 5 Sep 2000 23:40:17 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 5 Sep 2000 21:40:13 -0700 Received: from 203.197.21.171 by lw7fd.law7.hotmail.msn.com with HTTP; Wed, 06 Sep 2000 04:40:12 GMT X-Originating-IP: [203.197.21.171] From: "Computer Corporation" To: SIP@lists.bell-labs.com Date: Wed, 06 Sep 2000 10:10:12 IST Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 06 Sep 2000 04:40:13.0029 (UTC) FILETIME=[8BA1A150:01C017BC] Subject: [SIP] Commentaries, FAQ on rfc2543 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com i believe that there is a need for commentaries on many issues that are implicit in the rfc2543. it is personally been a hugely educative experience for me to me in touch with the greats of sip on this list. i am however, acutely aware of how newbies like I and others do infringe upon this list by asking the same questions repeatedly and getting the same answers from the pundits. although FAQs would be a good idea, I would also think that a document that is not wholly accurate (unlike an RFC) but easy, points out the implementational gotchas and explains the rationale will be a big help. Maybe one of us can start compiling a FAQ to begin with and then we can go onto a "sip implementor's guide". i guess the onus of such a thing would fall on someone studying/researching at columbia. i volunteer to do this if it will be of any worth and there isn't anyone else available (although I doubt my scholarship of sip and hence the ability to undertake this work). - farhan _________________________________________________________________________ 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 Sep 6 07:54: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 ESMTP id HAA08821 for ; Wed, 6 Sep 2000 07:54: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 94A964439C; Wed, 6 Sep 2000 06:54:22 -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 16E9844388 for ; Wed, 6 Sep 2000 06:48:16 -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 e86BmDp21087 for ; Wed, 6 Sep 2000 13:48:13 +0200 (MEST) Received: from uabx04c411.uab.ericsson.se.uab.ericsson.se (uabx04c411 [134.138.229.171]) by ms.uab.ericsson.se (8.10.0/8.10.0/uab-2.26) with ESMTP id e86BmDL24080 for ; Wed, 6 Sep 2000 13:48:13 +0200 (MET DST) Received: from uab.ericsson.se by uabx04c411.uab.ericsson.se.uab.ericsson.se (8.8.7/client-1.3uab1) id NAA27069; Wed, 6 Sep 2000 13:48:11 +0200 (MET DST) Message-ID: <39B62EFA.E21C3D19@uab.ericsson.se> Date: Wed, 06 Sep 2000 13:48:10 +0200 From: Bertil Engelholm Organization: Ericsson Utvecklings AB X-Mailer: Mozilla 4.74C-CCK-MCD [en] (X11; U; SunOS 5.6 sun4m) X-Accept-Language: sv,en-US MIME-Version: 1.0 To: SIP@lists.bell-labs.com Subject: Re: [SIP] transaction identification References: <8p21ed$vnd$1@lux2.datacom-lab.uab.ericsson.se> <39B4DAAE.358F071C@uab.ericsson.se> <8p3964$1hg$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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit OK, I have now read through IETF documents regarding RFC's and better understand the development of an RFC. I still beleave SIP would be a much better protocol if certain things was remove and/or changed. Since the SIP WG have the motto : "Simplicity is key" I thought that everyone actually was interested in simplifying SIP. Maybe the motto today should be : "Backwards Compatibility is key" 8-). May I suggest that you look over the text in the status chapter of the RFC and maybe there better explain what status the RFC is really in. In that way you might avoid future discussions like the one I started. /Bertil Jonathan Rosenberg wrote: > > Bertil Engelholm wrote: > > > > "Fairlie-Cuninghame, Robert" wrote: > > > > > > Bertil, > > > > > > There's a difference between removing marginally useless headers/features > > > and changing the whole protocol syntax - thereby making the protocol no > > > longer backwards compatible. > > > > This backwards compatible argument seems to come up again and again. > > Could someone please explain what defines when a change is regarded > > as "backward compatible" vs "non backward compatible" in the SIP > > case ? Is it related only to UA's or also to proxy servers ? > > Both, of course. Backwards compatible means a change or fix is > "invisible" to existing SIP devices, whilst useful to ones compliant to > the bis draft. > > > > > When in time was it decided that no non backwards compatible > > changes are allowed any more ? > > This is IETF process for evolution of an RFC. > > > > > Does this mean we can't add a parameter in the requestURI to > > fix the transaction id problem. If we add such a parameter it > > means that all proxies have to change to use that parameter > > which I would regard as a non backward compatible change. > > If it breaks correct operation by existing proxies, yes, it cannot be > done. > > > > > > > > > There are too many SIP implementations already out there to make these > > > changes now (even if as implementors we would like to make these > > > simplifications). > > > > Most SIP implementations became obsolete when Record-Route/Route > > was introduced not too long time ago. > > Huh? Not sure which specification you are referring to, but the one I > look at, rfc2543, has both Route and Record-Route. > > > Are you saying that since > > then there has been MANY SIP implementations released ? > > There are many implementations of rfc2543. Over 50 implementations came > to the last bakeoff. > > > If this is true I might understand the need for only backwards > > compatible changes better. At the same time I think it's a small > > job to remove the use of compact form (if anyone is using it) the > > use of comma separated lists and line folding. > > These are senseless things to remove. Handling short form is trivial. > Removing it will break backwards compatibility (requests with short form > will be rejected as errored). Things like Via hiding can be removed > since the Hide header will just be ignored, and the feature not > provided, just as if it were never in the spec in the first place. > > -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 -- 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 Wed Sep 6 09:21: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 ESMTP id JAA11431 for ; Wed, 6 Sep 2000 09:21: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 D9DC24439D; Wed, 6 Sep 2000 08:21:23 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from hotmail.com (f226.law7.hotmail.com [216.33.237.226]) by lists.bell-labs.com (Postfix) with ESMTP id 848F144362 for ; Wed, 6 Sep 2000 08:21:20 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 6 Sep 2000 06:21:18 -0700 Received: from 164.164.6.34 by lw7fd.law7.hotmail.msn.com with HTTP; Wed, 06 Sep 2000 13:21:18 GMT X-Originating-IP: [164.164.6.34] From: "rahul pande" To: computercorp@hotmail.com, SIP@lists.bell-labs.com Subject: Re: [SIP] Commentaries, FAQ on rfc2543 Date: Wed, 06 Sep 2000 18:51:18 IST Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 06 Sep 2000 13:21:18.0484 (UTC) FILETIME=[574B7540:01C01805] Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com hello sir, i am an MCA student doing some study in SIP and i would like to be a part of your team. I'll try to help to my capacity, please guide me what i need to do. Thanking you, rahul >From: "Computer Corporation" >To: SIP@lists.bell-labs.com >Subject: [SIP] Commentaries, FAQ on rfc2543 >Date: Wed, 06 Sep 2000 10:10:12 IST > >i believe that there is a need for commentaries on many issues that are >implicit in the rfc2543. it is personally been a hugely educative >experience >for me to me in touch with the greats of sip on this list. > >i am however, acutely aware of how newbies like I and others do infringe >upon this list by asking the same questions repeatedly and getting the same >answers from the pundits. > >although FAQs would be a good idea, I would also think that a document that >is not wholly accurate (unlike an RFC) but easy, points out the >implementational gotchas and explains the rationale will be a big help. >Maybe one of us can start compiling a FAQ to begin with and then we can go >onto a "sip implementor's guide". > >i guess the onus of such a thing would fall on someone studying/researching >at columbia. i volunteer to do this if it will be of any worth and there >isn't anyone else available (although I doubt my scholarship of sip and >hence the ability to undertake this work). > >- farhan > >_________________________________________________________________________ >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 _________________________________________________________________________ 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 Sep 6 09: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 ESMTP id JAA11581 for ; Wed, 6 Sep 2000 09: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 A2516443A9; Wed, 6 Sep 2000 08:25:57 -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 92BE644362 for ; Wed, 6 Sep 2000 08:19:44 -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 JAA14973; Wed, 6 Sep 2000 09:19:38 -0400 (EDT) Message-ID: <39B6446A.1D0E47B3@cs.columbia.edu> Date: Wed, 06 Sep 2000 09:19:38 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Computer Corporation Cc: SIP@lists.bell-labs.com Subject: Re: [SIP] Commentaries, FAQ on 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Computer Corporation wrote: > > i believe that there is a need for commentaries on many issues that are > implicit in the rfc2543. it is personally been a hugely educative experience > for me to me in touch with the greats of sip on this list. > > i am however, acutely aware of how newbies like I and others do infringe > upon this list by asking the same questions repeatedly and getting the same > answers from the pundits. > > although FAQs would be a good idea, I would also think that a document that > is not wholly accurate (unlike an RFC) but easy, points out the > implementational gotchas and explains the rationale will be a big help. > Maybe one of us can start compiling a FAQ to begin with and then we can go > onto a "sip implementor's guide". > > i guess the onus of such a thing would fall on someone studying/researching > at columbia. i volunteer to do this if it will be of any worth and there > isn't anyone else available (although I doubt my scholarship of sip and > hence the ability to undertake this work). There are a number of journal and magazine articles related to SIP that serve exactly this purpose. See the SIP web page at http://www.cs.columbia.edu/sip (under "papers and talks") for a listing. -- 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 Sep 6 11:44: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 ESMTP id LAA15456 for ; Wed, 6 Sep 2000 11:44: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 C6B964434C; Wed, 6 Sep 2000 10:44:00 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from smtp.netservers.net (smtp1.netservers.net [64.45.27.101]) by lists.bell-labs.com (Postfix) with SMTP id 863FA4433D for ; Wed, 6 Sep 2000 10:43:57 -0400 (EDT) Received: (qmail 29146 invoked from network); 6 Sep 2000 15:50:25 -0000 Received: from unknown (HELO voip) (216.101.190.42) by smtp with SMTP; 6 Sep 2000 15:50:25 -0000 From: "IPTelephonyJobs.com" To: "SIPbell-labs" Date: Wed, 6 Sep 2000 08:44:14 -0700 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0000_01C017DE.A2BFA0E0" 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 Subject: [SIP] IPTelephonyJobs.com Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com This is a multi-part message in MIME format. ------=_NextPart_000_0000_01C017DE.A2BFA0E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit check out http://www.iptelephonyjobs.com. Site for IPTelephony Professionals. jobs@iptelephonyjobs.com ------=_NextPart_000_0000_01C017DE.A2BFA0E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
check out http://www.iptelephonyjobs.com. 

Site for IPTelephony=20 Professionals. 
 
------=_NextPart_000_0000_01C017DE.A2BFA0E0-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Sep 6 11:53:29 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15591 for ; Wed, 6 Sep 2000 11:53: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 AE0B8443A9; Wed, 6 Sep 2000 10:53:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sheffield.cnchost.com (sheffield.concentric.net [207.155.252.12]) by lists.bell-labs.com (Postfix) with ESMTP id 55834443A5 for ; Wed, 6 Sep 2000 10:53:01 -0400 (EDT) Received: from lilipc (gw-ss8networks.storm.ca [209.87.234.122]) by sheffield.cnchost.com id LAA00255; Wed, 6 Sep 2000 11:52:53 -0400 (EDT) [ConcentricHost SMTP Relay 1.8] From: "Li Li" To: , Subject: RE: [SIP] tel URL v. SIP URL Date: Wed, 6 Sep 2000 11:55:27 -0400 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.00.2314.1300 In-Reply-To: <87A245E94948D3118DE30008C716B01301523B24@c0005v1idc1.oss.level3.com> Importance: Normal Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit I'd agree that SIP URL should also support LNP (rn and npdi). makes more sense for that some calls want SIP URL for certain applications to a ported number. li li SS8 Networks Ltd. > -----Original Message----- > From: sip-admin@lists.bell-labs.com > [mailto:sip-admin@lists.bell-labs.com]On Behalf Of > Jon.Peterson@Level3.com > Sent: Wednesday, September 06, 2000 2:53 AM > To: sip@lists.bell-labs.com > Subject: [SIP] tel URL v. SIP URL > > > > I note that in 2543bis the 'np-queried' parameter has been > removed from the > SIP URL, since a mechanism is now available in the tel URL to > support local > number portability (draft-yu-tel-url-00.txt?). Is this an indication that, > in the long term, the SIP URL is not a preferred manner to carry telephone > numbers, especially LRNs? > Previously, I had thought the only germane distinction between the two was > the absence of a host portion (and hence rules that do not allow the > inclusion of the tel URL in headers that are used in hop-by-hop > routing like > Contact); the tacit host component of the tel URL in a > Request-URI would be > the UA at which the network (proxies using local routing tables or ENUM or > what have you) feels this call should terminate. > If only the tel URL can carry number portability information, though, then > presumably all np-queried calls will have to be transmitted in tel URL > format. It seems to me that there might be services that would > like to rely > on host-based routing even after np-queries have taken place - calls that > began with SIP URLs, which are subsequently dipped by, say, a > native SIP LNP > application, might be forced to shed host information that was > important to > the desired routing of the call. > Is the general sentiment that the SIP URL should not have to > support number > portability? > > Jon Peterson > Level(3) Communications > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > 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 Sep 6 12:42: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 ESMTP id MAA17206 for ; Wed, 6 Sep 2000 12:42: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 9703D443AE; Wed, 6 Sep 2000 11:41:50 -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 385184433D for ; Wed, 6 Sep 2000 11:41:44 -0400 (EDT) Received: from driftwood.cisco.com (driftwood.cisco.com [171.71.157.40]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id JAA05272; Wed, 6 Sep 2000 09:42:02 -0700 (PDT) Received: from cisco.com ([171.71.159.231]) by driftwood.cisco.com (Mirapoint) with ESMTP id ACF07423; Wed, 6 Sep 2000 11:38:28 -0500 (CDT) Message-ID: <39B67405.7355F47@cisco.com> Date: Wed, 06 Sep 2000 11:42:45 -0500 From: Hong Chen Organization: Cisco Systems X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Tom-PT Taylor Cc: Henning Schulzrinne , Jonathan Rosenberg , Anders Kristensen , sip@lists.bell-labs.com Subject: Re: [SIP] SIP feature services References: <28560036253BD41191A10000F8BCBD11480D07@zcard00g.ca.nortel.com> Content-Type: multipart/alternative; boundary="------------843D16CD722DF00EC492103E" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com --------------843D16CD722DF00EC492103E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Tom-PT Taylor wrote: > > > The answer to all this that I'm seeing in my admittedly limited > experience is that individual networks define how they want services > to operate and expect vendors to support the resulting information > flows. You might be right. But we do not want to break one of the promising SIP principals by feature services: Interoperability. > > > -----Original Message----- > > From: Hong Chen [mailto:hjlechen@cisco.com] > > Sent: Tuesday, September 05, 2000 1:33 PM > > To: Henning Schulzrinne > > Cc: Jonathan Rosenberg; Anders Kristensen; sip@lists.bell-labs.com > > Subject: Re: [SIP] SIP feature services > > > > > > > > > > Henning Schulzrinne wrote: > > > > > Hong Chen wrote: > > > > > > > > Jonathan Rosenberg wrote: > > > > > > > I agree that additional standardization may not be > > necessary, but a standard call > > > > model > > > > for sip proxy may help for the feature developments and > > interpretability. > > > > > > Attempts at a call model have been made by various people. > > See the draft > > > archives. Whether they are useful is another question. > > > > > > > > > > > EX.. of features which need network controls and hard to > > define trigs in sip proxy. > > > > (1) Call Park (Park a call and then pick the call later > > somewhere else). > > > > (2) Call Pick Up (Answer a call which is ringing > > somewhere else in a call pick up > > > > group). > > > > (3) Adhoc conference using centralized conference bridge. > > > > and more. > > > > > > These services were discussed extensively on this list a > > number of weeks > > > ago (see the list archives), with different solutions > > proposed, since it > > > doesn't make sense to translate the behavior exactly from > > PSTN to IP. > > > Conferencing is also addressed in the SIP FAQ and requires > > no SIP proxy. > > > > > > > (1) It may not make sense to translate the behavior exactly > > from PSTN to IP, but people > > are still looking for > > those traditional services. > > > > (2) The key point here is: > > There may be hundred suggested different ways for > > some service by SIP signaling. > > The question is which is the best systematic > > mechanism we should follow and we > > can also easily > > use this same systematic mechanism for any new > > feature service later. > > > > > > > > > > > > -- > > > Henning Schulzrinne http://www.cs.columbia.edu/~hgs > > > > > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > --------------843D16CD722DF00EC492103E Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit  

Tom-PT Taylor wrote:

 

The answer to all this that I'm seeing in my admittedly limited experience is that individual networks define how they want services to operate and expect vendors to support the resulting information flows.

You might be right.  But we do not want to break one of the promising SIP principals by feature services: Interoperability.
 
> -----Original Message-----
> From: Hong Chen [mailto:hjlechen@cisco.com]
> Sent: Tuesday, September 05, 2000 1:33 PM
> To: Henning Schulzrinne
> Cc: Jonathan Rosenberg; Anders Kristensen; sip@lists.bell-labs.com
> Subject: Re: [SIP] SIP feature services
>
>
>
>
> Henning Schulzrinne wrote:
>
> > Hong Chen wrote:
> > >
> > > Jonathan Rosenberg wrote:
> >
> > > I agree that additional standardization may not be
> necessary, but  a standard call
> > > model
> > > for sip proxy may help for the feature developments and
> interpretability.
> >
> > Attempts at a call model have been made by various people.
> See the draft
> > archives. Whether they are useful is another question.
> >
> > >
> > > EX.. of features which need network controls and hard to
> define trigs in sip proxy.
> > > (1) Call Park (Park a call and then pick the call later
> somewhere else).
> > > (2) Call Pick Up (Answer a call which is ringing
> somewhere else in a call pick up
> > > group).
> > > (3) Adhoc conference using centralized conference bridge.
> > >  and more.
> >
> > These services were discussed extensively on this list a
> number of weeks
> > ago (see the list archives), with different solutions
> proposed, since it
> > doesn't make sense to translate the behavior exactly from
> PSTN to IP.
> > Conferencing is also addressed in the SIP FAQ and requires
> no SIP proxy.
> >
>
> (1) It may not make sense to translate the behavior exactly
> from PSTN to IP, but people
> are still looking for
> those traditional services.
>
> (2) The key point here is:
>         There may be hundred suggested different ways for
> some service by SIP signaling.
>         The question is which is the best systematic
> mechanism we should follow and we
> can also easily
>         use this same systematic mechanism for any new
> feature service later.
>
>
>
> >
> > --
> > Henning Schulzrinne   http://www.cs.columbia.edu/~hgs
>
>
>
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip
>
--------------843D16CD722DF00EC492103E-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Sep 6 13:34: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 ESMTP id NAA18601 for ; Wed, 6 Sep 2000 13:34: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 D4A81443B9; Wed, 6 Sep 2000 12:32:11 -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 2565A443B5 for ; Wed, 6 Sep 2000 12:32:08 -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 KAA10159; Wed, 6 Sep 2000 10:32:25 -0700 (PDT) Received: from rmahy-home-nt (rmahy-dsl1.cisco.com [10.19.53.122]) by imop.cisco.com (Mirapoint) with ESMTP id AAC56402; Wed, 6 Sep 2000 10:32:01 -0700 (PDT) Message-Id: <4.2.0.58.20000906100500.03b085f0@lint.cisco.com> X-Sender: rmahy@imop.cisco.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Wed, 06 Sep 2000 10:31:13 -0700 To: "Skip Cave" From: Rohan Mahy Subject: Re: [SIP] Two Keystroke Encodings Cc: 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Skip, What is your definition of a key or keystroke? I think you are missing a critical point here. T.140 is designed for text chat, where the characters are simply renderred, rather than interpreted. I don't think this is what you want. AVT tones is designed for carrying input that has traditionally been associated with the telephony world. If a SIP UA has a keypad that looks like a DTMF keypad, then _most of the time_ it should act like a DTMF keypad, and send the corresponding AVT encoding. If you are interested in getting generic input, I would use something completely different that has nothing to do with RTP. For example, if I write some characters on my Palm, is that a keystroke? If I tap a region on a touchscreen, or select a region with a mouse, is that a keystroke? What about speach rec of canned vocabularies (Yes, No, numbers..) Do we care? I think what we are really after is a way to send the kind of "menus" and "forms" that we are now used to in traditional IVRs, down to the end device (a SIP UA), where it can render the request as speech, text, buttons, whatever; the *method* of input is irrelevant. It is the selection of a particular menu choice, or the completion of a specific bit of information (account number) that your service logic cares about, so let the end-system render the damn thing. An example of such a system is a "distributed IVR" that uses VoXML on each UA. If I want the help-desk... INVITE sip:help-desk@company.com SIP/2.0 To: From: ... 301 Moved Contact: I get a reference to the script, then start running it. At the end of some of the menus are SIP URLs. sip:card-replacement-line@company.com?Priority=urgent&Subject=account714352 I like this model. I'm much less interested in "keystrokes" than generic input (VoXML-type model works here), and I think most SIP UAs will want the ability to talk to the PSTN some of the time (AVT tones model will be needed here). If we need to get DTMF input to a party that isn't otherwise involved in media, we can either tunnel AVT tones inside of SIP, or "conference" in the thrid party for AVT tones only. thanks, -rohan At 08:30 PM 9/5/00 , Skip Cave wrote: >My last post on this subject did not get any discussion. This usually >means that >everyone agrees, or no one understood it. Since what I was preposing >was >fairly radical, I assume the no-response was because of my poor >description > of the issue, and resulting incomprehension. I will try again, >and this time I won't mix together so many issues in one post. > >Henning and Jonathan have shown generally how RTP can be used as >a mechanism to carry keystrokes. They have shown how the delivery >can be made reliable. This clears several significant hurdles in the >path >towards using RTP as a practical keystroke transport method. There >are >only a few remaining issues. The following discussion addresses the >next critical issue. > >Colin Perkins writes: > > I suggest you read RFC 2793 which describes how to use > > RFC 2198 redundancy as a `reliable' transport for non-audio >keystrokes. > >http://lists.bell-labs.com/pipermail/sip/2000q3/002113.html > >RFC 2793 - "RTP Payload for Text Conversation" is an RFC which I had > >somehow overlooked (thank you, Colin) which proposes a method to use >RTP >to transport T.140 "text conversation" sessions. > >So, the IETF now has two different protocols to transmit exactly the >same >data - keystrokes - over RTP: RFC 2833, and RFC 2793. >The primary difference between the two protocols is simply the >encoding >of the keystrokes. > >RFC 2833 uses the following encoding for keys: > >Event encoding (decimal) >_________________________ >0--9 0--9 >* 10 ># 11 >A--D 12--15 > >RFC 2833 doesn't define encodings for any other keys. It seems to >assume >that all devices will only have a maximum of 16 keys. > >RFC 2793 proposes ISO/IEC 10646-1, level 3 (Unicode) encoding to >define a >much larger set of keys, but the 16 keys defined in RFC 2833 are >also >included in the RFC 2973 encoding: > >0x0030 DIGIT ZERO >0x0031 DIGIT ONE >0x0032 DIGIT TWO >0x0033 DIGIT THREE >0x0034 DIGIT FOUR >0x0035 DIGIT FIVE >0x0036 DIGIT SIX >0x0037 DIGIT SEVEN >0x0038 DIGIT EIGHT >0x0039 DIGIT NINE >....... >0x0041 LATIN CAPITAL LETTER A >0x0042 LATIN CAPITAL LETTER B >0x0043 LATIN CAPITAL LETTER C >0x0044 LATIN CAPITAL LETTER D >......... >0x002A ASTERISK >0x0023 NUMBER SIGN >....... > >As you can see, the two protocols have two vastly different ways to >encode >exactly the same thing - numeric & alphabetic keys on a terminal >device. > >Some other issues with the two protocols: > >RFC 2833 allows the transmission of keystrokes from a terminal over >RTP. >However, RFC 2833 also defines a large set of other events besides >keystrokes >that can be carried in the same RTP stream format: > o DTMF tones (Section 3.10); > o fax-related tones (Section 3.11); > o standard subscriber line tones (Section 3.12); > o country-specific subscriber line tones (Section 3.13) and; > o trunk events (Section 3.14). > >While this multiple-event-type property may be useful in some PSTN >transport >applications, it is definitely not appropriate as a general keystroke >communications >mechanism. Many applications will not want anything but keystrokes to >come over >the RTP session - no audio, no fax tones. > >RFC 2793 also allows the transmission of keystrokes from a terminal > >over RTP. This RFC uses ISO/IEC 10646-1, level 3 to define a much >larger set >of possible keys, but the keys on a 12-button terminal device are all >included in the larger set. >This RFC does not include any other event types except keystrokes, >but RFC 2793 >does not include a method to carry keystroke duration as a function >of the protocol. > >So to summarize: >RFC 2833 >1) doesn't cover all of the possible keys available in a terminal >device >2) carries extra stuff besides keystrokes in the protocol > >RFC 2793 >1) Doesn't carry keystroke duration information. > >Meanwhile, both protocols use the same redundancy mechanism >(RFC 2198) for more reliable delivery of keystrokes. > >My issue: >As a general rule, a device establishing a SIP session with another >device should not have to discover what type of device it is >sessioning with >before knowing whether to send keystrokes using RFC 2833 or RFC 2793 >over >the RTP session. There should be only one protocol and one encoding >for keystrokes >in SIP and RTP, regardless of the device that has the keys on it. > >My solution: >Combine the best of RFC 2833 and RFC 2793 for a universal keystroke >protocol. >1) Use RFC 2793's encoding scheme for all keys along with T.140 >protocol stucture >2) Use RFC 2833's duration scheme for keystroke durations >3) Use RFC 2198 for reliability >4) Remove the DTMF keystroke events from from Section 3 of RFC 2833 >and keep that protocol format specifically for telephony events >(fax tones, subscriber line tones, etc.). >5) Add a new payload format in RFC 2833 that is specifically for >keystrokes >using the 2833-2973 hybrid protocol. > >In this way, you could INVITE only the 2833-2973 hybrid protocol if >you wanted >just keystrokes, or you could INVITE the RTP audio also, or just the >telephony >events, or any combination using SDP media control mechanisms (m=3D) > >In my company's applications we plan to establish SIP sessions with >PSTN/SIP >Gateways, Softswitches, SIP phones, SIP mobile devices, and SIP PCs. >The key input from all of these different sources should use the >same >protocol. The key input that we send to all of these devices should >use >the same protocol. We don't want to have to use different protocols >to >send keystrokes to a SIP gateway, a SIP wireless device, a >Softswitch, or >a PC. We don't want to have to know ahead of time what type of device >we >are calling to determine what kind of session to INVITE to get >keystrokes. >The keystroke protocol for all devices that have keys should be the >same. > >If PSTN transport application developers vendors want to stick fax >tones >and call progress in with the compressed audio in a >gateway-to-gateway >RTP session, that's fine. Just don't make everybody have to support >those >events when all you want are keystrokes. > >Skip Cave > > > > > > > >_______________________________________________ >SIP mailing list >SIP@lists.bell-labs.com >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 Sep 6 13:43: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 ESMTP id NAA18957 for ; Wed, 6 Sep 2000 13:43: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 456BB443BC; Wed, 6 Sep 2000 12:42:46 -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 0EC15443B5 for ; Wed, 6 Sep 2000 12:42:43 -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 KAA19235; Wed, 6 Sep 2000 10:43:00 -0700 (PDT) Received: from rmahy-home-nt (rmahy-dsl1.cisco.com [10.19.53.122]) by imop.cisco.com (Mirapoint) with ESMTP id AAC56578; Wed, 6 Sep 2000 10:42:38 -0700 (PDT) Message-Id: <4.2.0.58.20000906103512.019e1020@lint.cisco.com> X-Sender: rmahy@imop.cisco.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Wed, 06 Sep 2000 10:41:50 -0700 To: Hong Chen From: Rohan Mahy Subject: Re: [SIP] SIP feature services Cc: Tom-PT Taylor , Henning Schulzrinne , Jonathan Rosenberg , Anders Kristensen , sip@lists.bell-labs.com In-Reply-To: <39B67405.7355F47@cisco.com> References: <28560036253BD41191A10000F8BCBD11480D07@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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Henry, Different web browsers do not all display the same content in exactly the same way, but they the server still interoperates with all of these browsers. Likewise SIP UAs don't have to act exactly the same way, as long as the right parties end up communicating. That said, I think the *example* call flow work is extremely important, but I feel that the examples plus the bakeoff is sufficient guidance to yield interoperable product. Ultimately, the market will decide what variations people like. thanks, -rohan At 09:42 AM 9/6/00 , Hong Chen wrote: > > >Tom-PT Taylor wrote: >> >> >>The answer to all this that I'm seeing in my admittedly limited >>experience is that individual networks define how they want services to >>operate and expect vendors to support the resulting information flows. >You might be right. But we do not want to break one of the promising SIP >principals by feature services: Interoperability. >> >> > -----Original Message----- >> > From: Hong Chen [mailto:hjlechen@cisco.com] >> > Sent: Tuesday, September 05, 2000 1:33 PM >> > To: Henning Schulzrinne >> > Cc: Jonathan Rosenberg; Anders Kristensen; sip@lists.bell-labs.com >> > Subject: Re: [SIP] SIP feature services >> > >> > >> > >> > >> > Henning Schulzrinne wrote: >> > >> > > Hong Chen wrote: >> > > > >> > > > Jonathan Rosenberg wrote: >> > > >> > > > I agree that additional standardization may not be >> > necessary, but a standard call >> > > > model >> > > > for sip proxy may help for the feature developments and >> > interpretability. >> > > >> > > Attempts at a call model have been made by various people. >> > See the draft >> > > archives. Whether they are useful is another question. >> > > >> > > > >> > > > EX.. of features which need network controls and hard to >> > define trigs in sip proxy. >> > > > (1) Call Park (Park a call and then pick the call later >> > somewhere else). >> > > > (2) Call Pick Up (Answer a call which is ringing >> > somewhere else in a call pick up >> > > > group). >> > > > (3) Adhoc conference using centralized conference bridge. >> > > > and more. >> > > >> > > These services were discussed extensively on this list a >> > number of weeks >> > > ago (see the list archives), with different solutions >> > proposed, since it >> > > doesn't make sense to translate the behavior exactly from >> > PSTN to IP. >> > > Conferencing is also addressed in the SIP FAQ and requires >> > no SIP proxy. >> > > >> > >> > (1) It may not make sense to translate the behavior exactly >> > from PSTN to IP, but people >> > are still looking for >> > those traditional services. >> > >> > (2) The key point here is: >> > There may be hundred suggested different ways for >> > some service by SIP signaling. >> > The question is which is the best systematic >> > mechanism we should follow and we >> > can also easily >> > use this same systematic mechanism for any new >> > feature service later. >> > >> > >> > >> > > >> > > -- >> > > Henning >> Schulzrinne http://www.cs.columbia.edu/~hgs >> > >> > >> > >> > _______________________________________________ >> > 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.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Sep 6 14:06: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 ESMTP id OAA19501 for ; Wed, 6 Sep 2000 14:06: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 6DA37443B2; Wed, 6 Sep 2000 13:06: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 6AA584434C for ; Wed, 6 Sep 2000 13:03:53 -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 OAA05191; Wed, 6 Sep 2000 14:03:19 -0400 (EDT) Message-ID: <39B686E7.65E0D6C1@cs.columbia.edu> Date: Wed, 06 Sep 2000 14:03:19 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Rohan Mahy Cc: Skip Cave , sip@lists.bell-labs.com Subject: Re: [SIP] Two Keystroke Encodings References: <4.2.0.58.20000906100500.03b085f0@lint.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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit See also the WAP menu model. (This is probably separable from the rest of the WAP stuff.) Also, you're well on your way to just downloading Java or Javascript. I don't think that voice and menu interaction are all that similar except in the most trivial cases. For example, you typically present many menu fields visually at the same time, but (naturally) only one at a time with voice. Rohan Mahy wrote: > > Skip, > > What is your definition of a key or keystroke? > > I think you are missing a critical point here. T.140 is designed for text > chat, where the characters are simply renderred, rather than > interpreted. I don't think this is what you want. AVT tones is designed > for carrying input that has traditionally been associated with the > telephony world. If a SIP UA has a keypad that looks like a DTMF keypad, > then _most of the time_ it should act like a DTMF keypad, and send the > corresponding AVT encoding. > > If you are interested in getting generic input, I would use something > completely different that has nothing to do with RTP. For example, if I > write some characters on my Palm, is that a keystroke? If I tap a region > on a touchscreen, or select a region with a mouse, is that a > keystroke? What about speach rec of canned vocabularies (Yes, No, > numbers..) Do we care? > > I think what we are really after is a way to send the kind of "menus" and > "forms" that we are now used to in traditional IVRs, down to the end device > (a SIP UA), where it can render the request as speech, text, buttons, > whatever; the *method* of input is irrelevant. It is the selection of a > particular menu choice, or the completion of a specific bit of information > (account number) that your service logic cares about, so let the end-system > render the damn thing. > > An example of such a system is a "distributed IVR" that uses VoXML on each UA. > > If I want the help-desk... > > INVITE sip:help-desk@company.com SIP/2.0 > To: > From: > ... > > 301 Moved > Contact: > > I get a reference to the script, then start running it. At the end of some > of the menus are SIP URLs. > > sip:card-replacement-line@company.com?Priority=urgent&Subject=account714352 > > I like this model. I'm much less interested in "keystrokes" than generic > input (VoXML-type model works here), and I think most SIP UAs will want the > ability to talk to the PSTN some of the time (AVT tones model will be > needed here). If we need to get DTMF input to a party that isn't otherwise > involved in media, we can either tunnel AVT tones inside of SIP, or > "conference" in the thrid party for AVT tones only. > > thanks, > -rohan > -- 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 Sep 6 19:10: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 ESMTP id TAA24612 for ; Wed, 6 Sep 2000 19:10: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 4AFD4443A5; Wed, 6 Sep 2000 18:10:48 -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 AF73D4439A for ; Wed, 6 Sep 2000 18:10:44 -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 e86NAfl01531 for ; Thu, 7 Sep 2000 02:10:41 +0300 (EET DST) Received: by daebh01nok with Internet Mail Service (5.5.2448.0) id ; Wed, 6 Sep 2000 18:07:38 -0500 Message-ID: From: Cliff.Harris@nokia.com To: sip@lists.bell-labs.com Date: Wed, 6 Sep 2000 18:04:37 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] Receiving unrecognized To tags Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Section 7.4.18 of rfc-bis says a 481 is returned if "the server received an INVITE with a To tag that does not match the local tag value." Section 10.1.1 says, "An incoming request is accepted unless the Call-ID value matches an existing call and the request has a tag value of To header that does not match the user agent server's tag value." Section 11.5 says, "It is possible that the To header in an INVITE request has a tag, but the UAS believes this to be a new call. [...] The UAS MAY either accept or reject the request." What if a UA receives an INVITE with an unknown Call ID and an unknown To tag? Sections 7 and 11 would seem to imply that the INVITE could be rejected with a 481, and section 10 would seem to imply that a new call leg should be created. Which is correct? Or am I misreading something? If a UA always uses the same tag value, shouldn't it automatically reject any request that has a different To tag? On the other hand, if a UA for some reason generates a new tag for every call, I suppose it wouldn't necessarily be able to tell whether an unrecognized To tag was one that it had in fact previously issued. Also, I'm a little confused about the forking issue. Suppose an INVITE gets forked to two UA's, one of which ends up as the UAS in a lengthy call. Later on, a re-INVITE from the UAC gets forked to the same two UA's. To the one that is not in the call, couldn't the wording of section 11.5 apply, so that the UA that is not involved in the call could reply to the re-INVITE with a 200 OK? I would have thought that the existence of the tag in the INVITE would indicate to this UA that it should not accept the INVITE. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Sep 6 20:12: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 ESMTP id UAA25196 for ; Wed, 6 Sep 2000 20:12: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 C6E00443BB; Wed, 6 Sep 2000 19:12:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mailserver2.sylantro.com (unknown [38.185.174.4]) by lists.bell-labs.com (Postfix) with SMTP id 2060C4439A for ; Wed, 6 Sep 2000 19:11:59 -0400 (EDT) Received: from 172.16.128.16 by mailserver2.sylantro.com with ESMTP ( WorldSecure Server SMTP Relay(WSS) v4.3); Wed, 06 Sep 00 17:10:37 -0700 X-Server-Uuid: 59490da2-986c-11d3-91ca-00104b9c3900 Received: by mailserver2.sylantro.com with Internet Mail Service ( 5.5.2650.21) id ; Wed, 6 Sep 2000 17:10:37 -0700 Message-ID: From: "Sharath Rajasekar" To: sip@lists.bell-labs.com Subject: Re: [SIP] transaction identification Date: Wed, 6 Sep 2000 17:10:36 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) X-WSS-ID: 15A803774519-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Implementing loop detection in *stateless proxies*, is it essential to compute the first part of branch id as a hash of To, From, CallID, Cseq in addition to RequestURI and topmost Via. Is it not sufficient to simply use the request URI and topmost Via alone for the hash computation since the other values are not going to change anyway ? I am not sure I understand why these fields are being used for the hash computation even in the case of stateless proxies. The second part of the branch could be computed as the hash of outgoing request uri + some server instance ? --Sharath R. Sharath Rajasekar Sylantro Systems Inc. http://www.sylantro.com -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Monday, September 04, 2000 8:41 PM To: Henning Schulzrinne Cc: Neil Deason; sip@lists.bell-labs.com Subject: Re: [SIP] transaction identification Henning Schulzrinne wrote: > > Neil Deason wrote: > > > > > > > This possible fix was not introduced just for Via hiding. > > The original discussion was about request retransmissions > > on reverse spirals when record routing is in operation. > > > > A -INV-> P1 -INV-> P2 -INV-> P1 -INV-> B > > > > A is originating UA, B is receiving UA, P1 & P2 are proxies > > that Record-Route. B now sends a BYE. When the P2-P1 "portion" > > of the BYE reaches P1, how will it distinguish that request > > from the initial B-P1 as the spec stands? So the idea was to > > change the definition of isomorphic requests to include a > > globally unique branch param. > > Added to the spec. The definition of the second branch parameter was > always pretty vague, including "a sequence number", which presumably > would do as long as the count is across all transactions. Just to be clear here; the discussion to date of having a third component that is globally unique is going to be folded into the second component. That component was used for the actual "branch" identification - if a proxy forks, and the response comes, for which forked request is the response? So, a globally unique ID will be used here instead of a simple sequence number that resets for each transaction. -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 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Sep 6 20:16: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 ESMTP id UAA25213 for ; Wed, 6 Sep 2000 20:16: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 8D2F5443CA; Wed, 6 Sep 2000 19:15: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 A64B4443BF for ; Wed, 6 Sep 2000 19:14: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 RAA03848; Wed, 6 Sep 2000 17:15:14 -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 AAC62836; Wed, 6 Sep 2000 17:14:52 -0700 (PDT) Message-Id: <4.2.0.58.20000906161507.00b208f0@imop.cisco.com> X-Sender: rmahy@imop.cisco.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Wed, 06 Sep 2000 17:11:32 -0700 To: "Skip Cave" From: Rohan Mahy Subject: Re: [SIP] Two Keystroke Encodings Cc: sip@lists.bell-labs.com In-Reply-To: X-BeenThere: sip@lists.bell-labs.com At 02:41 PM 9/6/00 , Skip Cave wrote: >Rohan Mahy said: What is your definition of a key or keystroke? >http://lists.bell-labs.com/pipermail/sip/2000q3/002612.html > >Skip Cave says: A keystroke occurs whenever the terminal device user >presses a key on the terminal device. > >I think you are missing a critical point here. T.140 is designed for text >chat, where the characters are simply renderred, rather than interpreted. > >I have no idea what the difference between "rendering" and "interpreting" >a keystroke is. When you press a key, you want an indication that the key >is pressed to be passed over the network to the application server. If you >are saying that the terminal device should somehow "interpret" the >keystroke and convert it into some other form, that could be an option. >You certainly can have the application in the terminal translate other UI >actions into keystrokes if you like. I don't want to translate anything *into* keystrokes. I don't want keystrokes to become somehow a fundamental form of input that everything else is translated into. I want a generic input mechanism (like HTML forms). In this kind of scheme, keystrokes and clicks and voice commands and other input would all be equal. >I don't think this is what you want. AVT tones is designed for carrying >input that has traditionally been associated with the telephony world. If >a SIP UA has a keypad that looks like a DTMF keypad, then _most of the >time_ it should act like a DTMF keypad, and send the corresponding AVT >encoding. > >What if the SIP UA has 5 keys, or 10 keys, or 20 keys, or 40 keys? Which >encoding scheme do you use then? Just because 12 keys is a "tradition" >doesn't mean that there should be something magic about the fact is that many SIP UAs will have these specific 12 keys because they want them to work more or less like the 12-keys on the original touch-tone telephone. the reason it has such a pad is so it can interoperate with the PSTN and other PSTN networks. if your UA has a graphical representation of a DTMF keypad, chances are, that keypad is still used for interop with a TDM network, and it should also generate AVT over RTP when you click on those things. >12 keys that causes them to use a different protocol. > >Applications don't just get keystrokes from a terminal. Applications need >to send keystrokes TO a terminal. this is news. please supply an example. >Which encoding scheme do I use? How do I tell whether the SIP device that >I am sending keystrokes to should get RFC 2833 or RC 2793? why are you sending "keystrokes". I think you should either send DTMF or generic input. >If you are interested in getting generic input, I would use something >completely different that has nothing to do with RTP. For example, if I >write some characters on my Palm, is that a keystroke? > >The application running on the Palm can certainly issue a keystroke >indication to the network when a number or letter is written on the Palm >screen. > >This is an excellent example of how an application in the network can be >written to use a generic keystroke protocol. The various device types can >be adapted to utilize this model, even if they don't have keys. > >If I tap a region on a touchscreen, or select a region with a mouse, is >that a keystroke? > >Again, you can do this if the application warrants. This approach is >particularly useful when the device does not have enough keys to support >the application, but the device has .some other user input mechanism that >can be converted to a keystroke indication. again, I don't want to convert anything to keystrokes. I don't need this on web pages (where I can have similar one decision at-a-time pages), so why do I need this on SIP? >Essentially, keystrokes become THE general-purpose >user-input-event-reporting mechanism for terminals on the packet network. YUCK! >What about speech rec of canned vocabularies (Yes, No, numbers..) > >If your speech rec is resident in the terminal device, converting the >spoken phrases into keystroke indications is a good way to generalize an >application so it could work on anything from a simple phone, all the way >up to a I think you've got it backwards. If you use a generic input scheme to begin with, then the UA can render that in any appropriate way (just like a web page). You shouldn't start with one input mechanism and promote it to King of All Input Methods, then expect everyone to translate. Keystrokes are particularly bad at this. How do I enter Chinese or Kanji characters for example? >voice-reco-enabled wireless PDA. > >The application can ask: "Please say what you would like to do next, or >press 1 for your account balance, 2 for ... etc." In this way the exact >same application in the network could work across simple PSTN phones or >voice- reco-enabled wireless PDAs. The network-based application just sees >keystroke indications, no matter what the terminal device looks like. NO, NO, NO, NO, NO! The application logic has a list of choices in your example menu. It does not need to be the responsibility of the application to choose that 1=account balance. The app doesn't have to say "Please press "1" or say "balance". The UA should do that. If the UA is a TDD device, it can display "Please *type* "balance", "sales", or "operator". If the UA has no screen and a DTMF-pad, and the user is Spanish it can say, ".. marque el numero uno .." >Do we care? > >If your question is: "Do we care about what user actions are classified as >keystrokes", the answer is no. Any user action can be classified as a >keystroke by the terminal device. If the terminal device has the >capability to understand a particular mode of user input (keystrokes, >stylus taps, spoken words, eye winks, etc.) it can report that action as a >keystroke or user event. > >I think what we are really after is a way to send the kind of "menus" and >"forms" that we are now used to in traditional IVRs, down to the end >device (a SIP UA), where it can render the request as speech, text, >buttons, whatever; the *method* of input is irrelevant. It is the >selection of a particular menu choice, or the completion of a specific bit >of information (account number) that your service logic cares about, so >let the end-system render the damn thing. > >.... clipped example of VoXML > >The model you present is certainly one of the many interesting >architectures proposed for providing a user interface on a terminal >device. You can download all of the user prompts (both spoken and printed) >to the terminal device before presenting them. You can download all of the >interaction logic to the terminal device so it can present the complete >user interaction with minimal external intervention. You can aggregate or >store all of the user input in the terminal (keyed, spoken, tapped, >winked, etc.) assuming the device can detect and understand the input, and >transmit the result of the complex user interaction at the very end. > >In this scenario, you certainly don't need a keystroke protocol to >propogate the result of the complex user interactions. A XML-structured >message carrying the result of a complex user interaction from the >terminal device to the application server in the network, is probably the >way to go. > >VoXML provides an alternate apporoach. VoXML stores all of the user >prompts, interaction logic, and user input on the "Voice Browser". >Actually, the interaction logic can be said to reside at the VoXML page's >URL, but in any case it isn't in the terminal device. The terminal device >can be very "dumb". This model is suitable when you don't want to put lots >of smarts, storage, or fancy UI equipment on the terminal device, and that >isn't just on PSTN phones! Don't forget, in this model, VoXML relies on a >standardized keystroke protocol (DTMF) to communicate the user input to >the VoXML server. > >So we have at least two models - everything on the device, and everything >in the network. The first approach makes for simpler network devices. The >latter approach has the advantage of simpler terminal devices. But simpler >terminal devices REQUIRES a standard input event (or keystroke) model. You can ask around, but I think the trend is for more stuff on the end systems. If you really want dumb and simple, you can make a SIP device with just a DTMF keypad, or you can implement a stimulus response protocol like MGCP or Cisco's "Skinny", but that is not within the SIP WG charter. >However, the general architecture should support both of these models. If >you decide that you want to build a SIP device that is really dumb, and >it won't support XML or WAP pages, and it won't support voice reco, and it >won't support a display, you should still be able to do it. VoXML points >the way. > >Remember, not all terminal devices will have the capability to store > >a sequence of keystrokes, that's absurd. what terminal device that can speak SIP can't store a sequence of keystrokes? SIP requires enough storage to keep TCBs and store packets for possible retransmission. They have to have at least SOME memory. >let alone do voice reco, locally. These dumb terminal devices may be a >PSTN device, but they may not. You should be able to build a SIP device >that essentially has no UI except a few keys and a display or speaker, >with no storage requirements other > >than the display matrix. > >In any case, VoXML REQUIRES that the dumb device have a keystroke >reporting mechanism, if it doesn't have an audio input mechanism for voice >reco, or particularly if can't even aggregate keystrokes locally. So, >there is already the requirement for a keystroke standard. VoXML >originally was focused on calls from a PSTN phone to a Voice Browser, but >the calling device could easily be a simple SIP device. > >The VoXML device may have 5 keys, or 10 keys, or 200 keys, but the >"dumb-terminal, smart-network-server" model needs a way to get the >keypresses, (or stylus-taps, or eye-winks) to the "smart" application >server (or VoXML server, or Telephony Platform, or whatever) over the >network in a standard way. > >Remember, some terminal devices will not have the capability to store > >a sequence of keystrokes, let alone do voice reco, locally. > >I like this model. I'm much less interested in "keystrokes" than generic >input (VoXML-type model works here), > >I'm not sure what you mean by "generic input". If you mean: Pressing the >"5" key OR, saying the word "five" OR, scribing the symbol "5" on the >screen with the stylus will result in a "5-key pressed" message from the >terminal. If this is what you mean by "generic input", then I agree with you. please look carefully at html forms. for example: the select tag presents a list of options. it returns that menu-choice="balance", not that the menu choice was "5". the first input tag collects a complete string. not "5", but "546325245" and will eventually POST that information back. >and I think most SIP UAs will want the ability to talk to the PSTN some >of the time (AVT tones model will be needed here). > >A SIP UA should never need to know whether it is sending keystrokes to a >PSTN device or another SIP device. The protocol to achieve both should be >identical. For one thing, it probably won't be easy to figure out whether >the device you are estasblishing a SIP session with is in the PSTN or the >packet network. You definitely should NOT be REQUIRED to find out. > >If, in the course of an application. I want to send the key indication "5" >to the other device, I do not want to have to figure out whether to send >the info as RFC 2833 or RFC 2739. There should only be one way. Don't worry, you won't find anyone at the SIP bakeoff who will try to send the "5" character to a terminal using RFC 2739. >If we need to get DTMF input to a party that isn't otherwise involved in >media, we can either tunnel AVT tones inside of SIP, or > >"conference" in the third party for AVT tones only. > >No, just send standard keystrokes in a standard protocol that all devices >(or their proxies) understand. You assume that everyone else shares your love of keystrokes. >Henning said: See also the WAP menu model. (This is probably separable >from the rest of the WAP stuff.) Also, you're well on your way to just >downloading Java or Javascript. I don't think that voice and menu >interaction are all that similar except in the most trivial cases. For >example, you typically present many menu fields visually at the same time, >but (naturally) only one at a time with voice. >http://lists.bell-labs.com/pipermail/sip/2000q3/002614.html > >Again, this model assumes that you want to store the interaction logic on >the terminal device. The interaction logic is may be simply > >keystroke aggregation, or full blown Javascript and voice reco, but you do >not want to force this model as the only way to do user interactions. why not. it is probably nearly as light at this point to implementing keystrokes on top of RTP. thanks, -rohan >You may not want to put a WAP browser or voice reco on the terminal >device. A particular application provider may be prefectly happy with a >simple 5 or 10-key terminal device with no display. The standard keystroke >model solves these issues simply and powerfully. > >Skip Cave Sr. Principal Engineer InterVoice-Brite Inc. > > > > > > > > Rohan Mahy >What is your definition of a key or keystroke? > >I think you are missing a critical point here. T.140 is designed for text >chat, where the characters are simply renderred, rather than >interpreted. I don't think this is what you want. AVT tones is designed >for carrying input that has traditionally been associated with the >telephony world. If a SIP UA has a keypad that looks like a DTMF keypad, >then _most of the time_ it should act like a DTMF keypad, and send the >corresponding AVT encoding. > >If you are interested in getting generic input, I would use something > >completely different that has nothing to do with RTP. For example, if I >write some characters on my Palm, is that a keystroke? If I tap a region >on a touchscreen, or select a region with a mouse, is that a >keystroke? What about speach rec of canned vocabularies (Yes, No, >numbers..) Do we care? > >I think what we are really after is a way to send the kind of "menus" and >"forms" that we are now used to in traditional IVRs, down to the end >device (a SIP UA), where it can render the request as speech, text, buttons, > >whatever; the *method* of input is irrelevant. It is the selection of a >particular menu choice, or the completion of a specific bit of information >(account number) that your service logic cares about, so let the >end-system render the damn thing. > >An example of such a system is a "distributed IVR" that uses VoXML on each UA. > >If I want the help-desk... > >INVITE sip:help-desk@company.com SIP/2.0 To: >301 Moved Contact: > >I get a reference to the script, then start running it. At the end of >some of the menus are SIP URLs. > >sip:card-replacement-line@company.com?Priority=urgent&Subject=account714352 > > >I like this model. I'm much less interested in "keystrokes" than generic >input (VoXML-type model works here), and I think most SIP UAs will want >the ability to talk to the PSTN some of the time (AVT tones model will be > >needed here). If we need to get DTMF input to a party that isn't >otherwise involved in media, we can either tunnel AVT tones inside of SIP, >or "conference" in the thrid party for AVT tones only. > >thanks, -rohan > > >At 08:30 PM 9/5/00 , Skip Cave wrote: My last post on this subject did not >get any discussion. This usually means that everyone agrees, or no one >understood it. Since what I was preposing was fairly radical, I assume the >no-response was because of my poor description of the issue, and >resulting incomprehension. I will try again, and this time I won't mix >together so many issues in one post. Henning and Jonathan have shown >generally how RTP can be used as a mechanism to carry keystrokes. They >have shown how the delivery can be made reliable. This clears several >significant hurdles in the path towards using RTP as a practical keystroke >transport method. There are only a few remaining issues. The following >discussion addresses the next critical issue. Colin Perkins writes: I >suggest you read RFC 2793 which describes how to use RFC 2198 redundancy >as a `reliable' transport for non-audio >keystrokes. http://lists.bell-labs.com/pipermail/sip/2000q3/002113.html >RFC 2793 - "RTP Payload for Text Conversation" is an RFC which I >had somehow overlooked (thank you, Colin) which proposes a method to use >RTP to transport T.140 "text conversation" sessions. So, the IETF now has >two different protocols to transmit exactly the same data - keystrokes - >over RTP: RFC 2833, and RFC 2793. The primary difference between the two >protocols is simply the encoding of the keystrokes. RFC 2833 uses the >following encoding for keys: Event encoding (decimal) >_________________________ 0--9 0--9 >* 10 # 11 >A--D 12--15 RFC 2833 doesn't define encodings for any other >keys. It seems to assume that all devices will only have a maximum of 16 >keys. RFC 2793 proposes ISO/IEC 10646-1, level 3 (Unicode) encoding to >define a much larger set of keys, but the 16 keys defined in RFC 2833 are >also included in the RFC 2973 encoding: 0x0030 DIGIT ZERO >0x0031 DIGIT ONE 0x0032 DIGIT TWO 0x0033 DIGIT >THREE 0x0034 DIGIT FOUR 0x0035 DIGIT FIVE >0x0036 DIGIT SIX 0x0037 DIGIT SEVEN 0x0038 DIGIT >EIGHT 0x0039 DIGIT NINE ....... 0x0041 LATIN CAPITAL >LETTER A 0x0042 LATIN CAPITAL LETTER B 0x0043 LATIN >CAPITAL LETTER C 0x0044 LATIN CAPITAL LETTER D ......... >0x002A ASTERISK 0x0023 NUMBER SIGN ....... As you can >see, the two protocols have two vastly different ways to encode exactly >the same thing - numeric & alphabetic keys on a terminal device. Some >other issues with the two protocols: RFC 2833 allows the transmission of >keystrokes from a terminal over RTP. However, RFC 2833 also defines a >large set of other events besides keystrokes that can be carried in the >same RTP stream format: o DTMF tones (Section >3.10); o fax-related tones (Section 3.11); o standard >subscriber line tones (Section 3.12); o country-specific subscriber >line tones (Section 3.13) and; o trunk events (Section 3.14). While >this multiple-event-type property may be useful in some PSTN transport >applications, it is definitely not appropriate as a general keystroke >communications mechanism. Many applications will not want anything but >keystrokes to come over the RTP session - no audio, no fax tones. RFC >2793 also allows the transmission of keystrokes from a terminal over RTP. >This RFC uses ISO/IEC 10646-1, level 3 to define a much larger set of >possible keys, but the keys on a 12-button terminal device are all >included in the larger set. This RFC does not include any other event >types except keystrokes, but RFC 2793 does not include a method to carry >keystroke duration as a function of the protocol. So to summarize: RFC >2833 1) doesn't cover all of the possible keys available in a terminal >device 2) carries extra stuff besides keystrokes in the protocol RFC 2793 >1) Doesn't carry keystroke duration information. Meanwhile, both >protocols use the same redundancy mechanism (RFC 2198) for more reliable >delivery of keystrokes. My issue: As a general rule, a device >establishing a SIP session with another device should not have to discover >what type of device it is sessioning with before knowing whether to send >keystrokes using RFC 2833 or RFC 2793 over the RTP session. There should >be only one protocol and one encoding for keystrokes in SIP and RTP, >regardless of the device that has the keys on it. My solution: Combine >the best of RFC 2833 and RFC 2793 for a universal keystroke protocol. 1) >Use RFC 2793's encoding scheme for all keys along with T.140 protocol >stucture 2) Use RFC 2833's duration scheme for keystroke durations 3) Use >RFC 2198 for reliability 4) Remove the DTMF keystroke events from from >Section 3 of RFC 2833 and keep that protocol format specifically for >telephony events (fax tones, subscriber line tones, etc.). 5) Add a new >payload format in RFC 2833 that is specifically for keystrokes using the >2833-2973 hybrid protocol. In this way, you could INVITE only the >2833-2973 hybrid protocol if you wanted just keystrokes, or you could >INVITE the RTP audio also, or just the telephony events, or any >combination using SDP media control mechanisms (m=3D) In my company's >applications we plan to establish SIP sessions with PSTN/SIP Gateways, >Softswitches, SIP phones, SIP mobile devices, and SIP PCs. The key input >from all of these different sources should use the same protocol. The key >input that we send to all of these devices should use the same protocol. >We don't want to have to use different protocols to send keystrokes to a >SIP gateway, a SIP wireless device, a Softswitch, or a PC. We don't want >to have to know ahead of time what type of device we are calling to >determine what kind of session to INVITE to get keystrokes. The keystroke >protocol for all devices that have keys should be the same. If PSTN >transport application developers vendors want to stick fax tones and call >progress in with the compressed audio in a gateway-to-gateway RTP session, >that's fine. Just don't make everybody have to support those events when >all you want are keystrokes. Skip Cave > > > > > > >_______________________________________________ >SIP mailing list >SIP@lists.bell-labs.com >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 Sep 7 01:46: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 ESMTP id BAA04986 for ; Thu, 7 Sep 2000 01:46: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 5EC974435D; Thu, 7 Sep 2000 00:46:15 -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 4B3094433D for ; Thu, 7 Sep 2000 00:46:11 -0400 (EDT) Received: from dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA18967; Thu, 7 Sep 2000 01:47:59 -0400 (EDT) Message-ID: <39B72B78.89213C99@dynamicsoft.com> Date: Thu, 07 Sep 2000 01:45:28 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Jon.Peterson@Level3.com Cc: sip@lists.bell-labs.com Subject: Re: [SIP] tel URL v. SIP URL References: <87A245E94948D3118DE30008C716B01301523B24@c0005v1idc1.oss.level3.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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Jon.Peterson@Level3.com wrote: > > I note that in 2543bis the 'np-queried' parameter has been removed from the > SIP URL, since a mechanism is now available in the tel URL to support local > number portability (draft-yu-tel-url-00.txt?). Is this an indication that, > in the long term, the SIP URL is not a preferred manner to carry telephone > numbers, especially LRNs? No. The SIP URL will be able to carry these. The idea is that the BNF for telephone-subscriber from the tel URL is usable directly as the user portion of the SIP URL. Since telephone subscriber encapsulates everything in the tel URL, you can put the LNP parameters into the SIP URL: sip:5551212;npdbi=true@level3.com kind of ugly, but it 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: (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 Sep 7 07:48: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 ESMTP id HAA15036 for ; Thu, 7 Sep 2000 07:48:53 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A990B443B4; Thu, 7 Sep 2000 06:48:33 -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 5FD244433D for ; Thu, 7 Sep 2000 06:48:30 -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 EAA25886; Thu, 7 Sep 2000 04:48:47 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id EAA01873; Thu, 7 Sep 2000 04:48:27 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14775.32907.438110.474581@thomasm-u1.cisco.com> Date: Thu, 7 Sep 2000 04:48:27 -0700 (PDT) To: Henning Schulzrinne Cc: sip Subject: Re: [SIP] Re: SIP gateways and authentication In-Reply-To: <39AE519C.99177233@cs.columbia.edu> References: <39A6D968.647FBFDB@cs.columbia.edu> <89866A7EC9C0D1119C950000F8BCC282016352E9@zrtpd00n.us.nortel.com> <39A6035E.4DDC74C0@dynamicsoft.com> <14758.38134.851139.496078@thomasm-u1.cisco.com> <39A6B1C4.E424802F@cs.columbia.edu> <14758.48066.388917.988364@thomasm-u1.cisco.com> <39A6C0C3.7BEC4838@cs.columbia.edu> <14758.49815.427708.431582@thomasm-u1.cisco.com> <39A6C49E.9844FF65@cs.columbia.edu> <14758.51787.331133.132625@thomasm-u1.cisco.com> <4.3.1.2.20000830092306.00bbeeb0@shell11.ba.best.com> <39AE519C.99177233@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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Henning Schulzrinne writes: > Since most authentication is client-to-client, Why do you suppose that? This assumes that proxy-routed traffic won't be the norm. I can think of a lot of cases where that assumption is incorrect. > CPU issues are probably > not as grave a concern (no more than, say, for email). Email does not have post dial delay constraints. PGP/SMIME email doesn't have scaling issues on large trunking gateways, conference servers, voice mail servers, etc, either. > The ability to > implement PK protocols (or Kerberos) in very small devices is much more > likely to be an issue. Symmetric key algorithms can fairly easily be accommodated by IP toaster grade embedded CPU's these days; not so public key intensive applications. Flash is finally coming down in price due to pressure from camaras and the like. Security isn't free but designed intelligently it doesn't have to be either brain-dead slow or out-of-reach expensive. 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 Sep 7 08:57: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 ESMTP id IAA15651 for ; Thu, 7 Sep 2000 08:57: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 63563443B8; Thu, 7 Sep 2000 07:56:54 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from anchor-post-33.mail.demon.net (anchor-post-33.mail.demon.net [194.217.242.91]) by lists.bell-labs.com (Postfix) with ESMTP id 0F1454433D for ; Thu, 7 Sep 2000 07:56:51 -0400 (EDT) Received: from pqm-cons.demon.co.uk ([158.152.93.237] helo=P162U) by anchor-post-33.mail.demon.net with smtp (Exim 2.12 #1) id 13X1EW-000HV7-0X; Thu, 7 Sep 2000 13:56:48 +0100 From: "Alex Hardisty" To: "Rohan Mahy" Cc: Subject: RE: [SIP] SIP feature services Date: Thu, 7 Sep 2000 14:00:07 +0100 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 In-Reply-To: <4.2.0.58.20000906103512.019e1020@lint.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Rohan Mahy wrote: > Ultimately, the market will decide what variations people like. No! Ultimately, what the market has to put up with is the lowest common denominator of functionality that can be made to work between equipments that purport to support a particular capability but whose vendors have implemented it in different ways! -- Alex Hardisty PQM Consultants _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Sep 7 09:20:22 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15868 for ; Thu, 7 Sep 2000 09:20: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 5B450443BE; Thu, 7 Sep 2000 08:20: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 727D34439A for ; Wed, 6 Sep 2000 16:43:54 -0400 (EDT) Received: from intervoice-brite.com ([172.16.16.64]) by ivigate.intervoice.com (Build 98 8.9.3/NT-8.9.3) with SMTP id QAA02227 for ; Wed, 06 Sep 2000 16:45:04 -0500 Received: from INTERVOICE-Message_Server by intervoice-brite.com with Novell_GroupWise; Wed, 06 Sep 2000 16:42:23 -0500 Message-Id: X-Mailer: Novell GroupWise 5.2 Date: Wed, 06 Sep 2000 16:41:48 -0500 From: "Skip Cave" To: rohan@cisco.com Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Two Keystroke Encodings Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Rohan Mahy said: >What is your definition of a key or keystroke? >http://lists.bell-labs.com/pipermail/sip/2000q3/002612.html Skip Cave says: A keystroke occurs whenever the terminal device user presses a key on the terminal device. >I think you are missing a critical point here. T.140 is designed for text >chat, where the characters are simply renderred, rather than >interpreted. I have no idea what the difference between "rendering" and "interpreting" a keystroke is. When you press a key, you want an indication that the key is pressed to be passed over the network to the application server. If you are saying that the terminal device should somehow "interpret" the keystroke and convert it into some other form, that could be an option. You certainly can have the application in the terminal translate other UI actions into keystrokes if you like. >I don't think this is what you want. AVT tones is designed >for carrying input that has traditionally been associated with the >telephony world. If a SIP UA has a keypad that looks like a DTMF keypad, >then _most of the time_ it should act like a DTMF keypad, and send the >corresponding AVT encoding. What if the SIP UA has 5 keys, or 10 keys, or 20 keys, or 40 keys? Which encoding scheme do you use then? Just because 12 keys is a "tradition" doesn't mean that there should be something magic about 12 keys that causes them to use a different protocol. Applications don't just get keystrokes from a terminal. Applications need to send keystrokes TO a terminal. Which encoding scheme do I use? How do I tell whether the SIP device that I am sending keystrokes to should get RFC 2833 or RC 2793? >If you are interested in getting generic input, I would use something >completely different that has nothing to do with RTP. For example, if I >write some characters on my Palm, is that a keystroke? The application running on the Palm can certainly issue a keystroke indication to the network when a number or letter is written on the Palm screen. This is an excellent example of how an application in the network can be written to use a generic keystroke protocol. The various device types can be adapted to utilize this model, even if they don't have keys. >If I tap a region on a touchscreen, or select a region with a mouse, is that a >keystroke? Again, you can do this if the application warrants. This approach is particularly useful when the device does not have enough keys to support the application, but the device has .some other user input mechanism that can be converted to a keystroke indication. Essentially, keystrokes become THE general-purpose user-input-event-reporting mechanism for terminals on the packet network. >What about speech rec of canned vocabularies (Yes, No, numbers..) If your speech rec is resident in the terminal device, converting the spoken phrases into keystroke indications is a good way to generalize an application so it could work on anything from a simple phone, all the way up to a voice-reco-enabled wireless PDA. The application can ask: "Please say what you would like to do next, or press 1 for your account balance, 2 for ... etc." In this way the exact same application in the network could work across simple PSTN phones or voice- reco-enabled wireless PDAs. The network-based application just sees keystroke indications, no matter what the terminal device looks like. >Do we care? If your question is: "Do we care about what user actions are classified as keystrokes", the answer is no. Any user action can be classified as a keystroke by the terminal device. If the terminal device has the capability to understand a particular mode of user input (keystrokes, stylus taps, spoken words, eye winks, etc.) it can report that action as a keystroke or user event. >I think what we are really after is a way to send the kind of "menus" and >"forms" that we are now used to in traditional IVRs, down to the end device >(a SIP UA), where it can render the request as speech, text, buttons, >whatever; the *method* of input is irrelevant. It is the selection of a >particular menu choice, or the completion of a specific bit of information >(account number) that your service logic cares about, so let the end-system >render the damn thing. >.... clipped example of VoXML The model you present is certainly one of the many interesting architectures proposed for providing a user interface on a terminal device. You can download all of the user prompts (both spoken and printed) to the terminal device before presenting them. You can download all of the interaction logic to the terminal device so it can present the complete user interaction with minimal external intervention. You can aggregate or store all of the user input in the terminal (keyed, spoken, tapped, winked, etc.) assuming the device can detect and understand the input, and transmit the result of the complex user interaction at the very end. In this scenario, you certainly don't need a keystroke protocol to propogate the result of the complex user interactions. A XML-structured message carrying the result of a complex user interaction from the terminal device to the application server in the network, is probably the way to go. VoXML provides an alternate apporoach. VoXML stores all of the user prompts, interaction logic, and user input on the "Voice Browser". Actually, the interaction logic can be said to reside at the VoXML page's URL, but in any case it isn't in the terminal device. The terminal device can be very "dumb". This model is suitable when you don't want to put lots of smarts, storage, or fancy UI equipment on the terminal device, and that isn't just on PSTN phones! Don't forget, in this model, VoXML relies on a standardized keystroke protocol (DTMF) to communicate the user input to the VoXML server. So we have at least two models - everything on the device, and everything in the network. The first approach makes for simpler network devices. The latter approach has the advantage of simpler terminal devices. But simpler terminal devices REQUIRES a standard input event (or keystroke) model. However, the general architecture should support both of these models. If you decide that you want to build a SIP device that is really dumb, and it won't support XML or WAP pages, and it won't support voice reco, and it won't support a display, you should still be able to do it. VoXML points the way. Remember, not all terminal devices will have the capability to store a sequence of keystrokes, let alone do voice reco, locally. These dumb terminal devices may be a PSTN device, but they may not. You should be able to build a SIP device that essentially has no UI except a few keys and a display or speaker, with no storage requirements other than the display matrix. In any case, VoXML REQUIRES that the dumb device have a keystroke reporting mechanism, if it doesn't have an audio input mechanism for voice reco, or particularly if can't even aggregate keystrokes locally. So, there is already the requirement for a keystroke standard. VoXML originally was focused on calls from a PSTN phone to a Voice Browser, but the calling device could easily be a simple SIP device. The VoXML device may have 5 keys, or 10 keys, or 200 keys, but the "dumb-terminal, smart-network-server" model needs a way to get the keypresses, (or stylus-taps, or eye-winks) to the "smart" application server (or VoXML server, or Telephony Platform, or whatever) over the network in a standard way. Remember, some terminal devices will not have the capability to store a sequence of keystrokes, let alone do voice reco, locally. >I like this model. I'm much less interested in "keystrokes" than generic >input (VoXML-type model works here), I'm not sure what you mean by "generic input". If you mean: Pressing the "5" key OR, saying the word "five" OR, scribing the symbol "5" on the screen with the stylus will result in a "5-key pressed" message from the terminal. If this is what you mean by "generic input", then I agree with you. >and I think most SIP UAs will want the ability to talk to the PSTN > some of the time (AVT tones model will be needed here). A SIP UA should never need to know whether it is sending keystrokes to a PSTN device or another SIP device. The protocol to achieve both should be identical. For one thing, it probably won't be easy to figure out whether the device you are estasblishing a SIP session with is in the PSTN or the packet network. You definitely should NOT be REQUIRED to find out. If, in the course of an application. I want to send the key indication "5" to the other device, I do not want to have to figure out whether to send the info as RFC 2833 or RFC 2739. There should only be one way. >If we need to get DTMF input to a party that isn't otherwise >involved in media, we can either tunnel AVT tones inside of SIP, or >"conference" in the third party for AVT tones only. No, just send standard keystrokes in a standard protocol that all devices (or their proxies) understand. Henning said: >See also the WAP menu model. (This is probably separable from the rest >of the WAP stuff.) Also, you're well on your way to just downloading >Java or Javascript. I don't think that voice and menu interaction are >all that similar except in the most trivial cases. For example, you >typically present many menu fields visually at the same time, but >(naturally) only one at a time with voice. >http://lists.bell-labs.com/pipermail/sip/2000q3/002614.html Again, this model assumes that you want to store the interaction logic on the terminal device. The interaction logic is may be simply keystroke aggregation, or full blown Javascript and voice reco, but you do not want to force this model as the only way to do user interactions. You may not want to put a WAP browser or voice reco on the terminal device. A particular application provider may be prefectly happy with a simple 5 or 10-key terminal device with no display. The standard keystroke model solves these issues simply and powerfully. Skip Cave Sr. Principal Engineer InterVoice-Brite Inc. >>> Rohan Mahy 09/06 12:31 PM >>> Skip, What is your definition of a key or keystroke? I think you are missing a critical point here. T.140 is designed for text chat, where the characters are simply renderred, rather than interpreted. I don't think this is what you want. AVT tones is designed for carrying input that has traditionally been associated with the telephony world. If a SIP UA has a keypad that looks like a DTMF keypad, then _most of the time_ it should act like a DTMF keypad, and send the corresponding AVT encoding. If you are interested in getting generic input, I would use something completely different that has nothing to do with RTP. For example, if I write some characters on my Palm, is that a keystroke? If I tap a region on a touchscreen, or select a region with a mouse, is that a keystroke? What about speach rec of canned vocabularies (Yes, No, numbers..) Do we care? I think what we are really after is a way to send the kind of "menus" and "forms" that we are now used to in traditional IVRs, down to the end device (a SIP UA), where it can render the request as speech, text, buttons, whatever; the *method* of input is irrelevant. It is the selection of a particular menu choice, or the completion of a specific bit of information (account number) that your service logic cares about, so let the end-system render the damn thing. An example of such a system is a "distributed IVR" that uses VoXML on each UA. If I want the help-desk... INVITE sip:help-desk@company.com SIP/2.0 To: From: ... 301 Moved Contact: I get a reference to the script, then start running it. At the end of some of the menus are SIP URLs. sip:card-replacement-line@company.com?Priority=urgent&Subject=account714352 I like this model. I'm much less interested in "keystrokes" than generic input (VoXML-type model works here), and I think most SIP UAs will want the ability to talk to the PSTN some of the time (AVT tones model will be needed here). If we need to get DTMF input to a party that isn't otherwise involved in media, we can either tunnel AVT tones inside of SIP, or "conference" in the thrid party for AVT tones only. thanks, -rohan At 08:30 PM 9/5/00 , Skip Cave wrote: >My last post on this subject did not get any discussion. This usually >means that >everyone agrees, or no one understood it. Since what I was preposing >was >fairly radical, I assume the no-response was because of my poor >description > of the issue, and resulting incomprehension. I will try again, >and this time I won't mix together so many issues in one post. > >Henning and Jonathan have shown generally how RTP can be used as >a mechanism to carry keystrokes. They have shown how the delivery >can be made reliable. This clears several significant hurdles in the >path >towards using RTP as a practical keystroke transport method. There >are >only a few remaining issues. The following discussion addresses the >next critical issue. > >Colin Perkins writes: > > I suggest you read RFC 2793 which describes how to use > > RFC 2198 redundancy as a `reliable' transport for non-audio >keystrokes. > >http://lists.bell-labs.com/pipermail/sip/2000q3/002113.html > >RFC 2793 - "RTP Payload for Text Conversation" is an RFC which I had > >somehow overlooked (thank you, Colin) which proposes a method to use >RTP >to transport T.140 "text conversation" sessions. > >So, the IETF now has two different protocols to transmit exactly the >same >data - keystrokes - over RTP: RFC 2833, and RFC 2793. >The primary difference between the two protocols is simply the >encoding >of the keystrokes. > >RFC 2833 uses the following encoding for keys: > >Event encoding (decimal) >_________________________ >0--9 0--9 >* 10 ># 11 >A--D 12--15 > >RFC 2833 doesn't define encodings for any other keys. It seems to >assume >that all devices will only have a maximum of 16 keys. > >RFC 2793 proposes ISO/IEC 10646-1, level 3 (Unicode) encoding to >define a >much larger set of keys, but the 16 keys defined in RFC 2833 are >also >included in the RFC 2973 encoding: > >0x0030 DIGIT ZERO >0x0031 DIGIT ONE >0x0032 DIGIT TWO >0x0033 DIGIT THREE >0x0034 DIGIT FOUR >0x0035 DIGIT FIVE >0x0036 DIGIT SIX >0x0037 DIGIT SEVEN >0x0038 DIGIT EIGHT >0x0039 DIGIT NINE >....... >0x0041 LATIN CAPITAL LETTER A >0x0042 LATIN CAPITAL LETTER B >0x0043 LATIN CAPITAL LETTER C >0x0044 LATIN CAPITAL LETTER D >......... >0x002A ASTERISK >0x0023 NUMBER SIGN >....... > >As you can see, the two protocols have two vastly different ways to >encode >exactly the same thing - numeric & alphabetic keys on a terminal >device. > >Some other issues with the two protocols: > >RFC 2833 allows the transmission of keystrokes from a terminal over >RTP. >However, RFC 2833 also defines a large set of other events besides >keystrokes >that can be carried in the same RTP stream format: > o DTMF tones (Section 3.10); > o fax-related tones (Section 3.11); > o standard subscriber line tones (Section 3.12); > o country-specific subscriber line tones (Section 3.13) and; > o trunk events (Section 3.14). > >While this multiple-event-type property may be useful in some PSTN >transport >applications, it is definitely not appropriate as a general keystroke >communications >mechanism. Many applications will not want anything but keystrokes to >come over >the RTP session - no audio, no fax tones. > >RFC 2793 also allows the transmission of keystrokes from a terminal > >over RTP. This RFC uses ISO/IEC 10646-1, level 3 to define a much >larger set >of possible keys, but the keys on a 12-button terminal device are all >included in the larger set. >This RFC does not include any other event types except keystrokes, >but RFC 2793 >does not include a method to carry keystroke duration as a function >of the protocol. > >So to summarize: >RFC 2833 >1) doesn't cover all of the possible keys available in a terminal >device >2) carries extra stuff besides keystrokes in the protocol > >RFC 2793 >1) Doesn't carry keystroke duration information. > >Meanwhile, both protocols use the same redundancy mechanism >(RFC 2198) for more reliable delivery of keystrokes. > >My issue: >As a general rule, a device establishing a SIP session with another >device should not have to discover what type of device it is >sessioning with >before knowing whether to send keystrokes using RFC 2833 or RFC 2793 >over >the RTP session. There should be only one protocol and one encoding >for keystrokes >in SIP and RTP, regardless of the device that has the keys on it. > >My solution: >Combine the best of RFC 2833 and RFC 2793 for a universal keystroke >protocol. >1) Use RFC 2793's encoding scheme for all keys along with T.140 >protocol stucture >2) Use RFC 2833's duration scheme for keystroke durations >3) Use RFC 2198 for reliability >4) Remove the DTMF keystroke events from from Section 3 of RFC 2833 >and keep that protocol format specifically for telephony events >(fax tones, subscriber line tones, etc.). >5) Add a new payload format in RFC 2833 that is specifically for >keystrokes >using the 2833-2973 hybrid protocol. > >In this way, you could INVITE only the 2833-2973 hybrid protocol if >you wanted >just keystrokes, or you could INVITE the RTP audio also, or just the >telephony >events, or any combination using SDP media control mechanisms (m=3D) > >In my company's applications we plan to establish SIP sessions with >PSTN/SIP >Gateways, Softswitches, SIP phones, SIP mobile devices, and SIP PCs. >The key input from all of these different sources should use the >same >protocol. The key input that we send to all of these devices should >use >the same protocol. We don't want to have to use different protocols >to >send keystrokes to a SIP gateway, a SIP wireless device, a >Softswitch, or >a PC. We don't want to have to know ahead of time what type of device >we >are calling to determine what kind of session to INVITE to get >keystrokes. >The keystroke protocol for all devices that have keys should be the >same. > >If PSTN transport application developers vendors want to stick fax >tones >and call progress in with the compressed audio in a >gateway-to-gateway >RTP session, that's fine. Just don't make everybody have to support >those >events when all you want are keystrokes. > >Skip Cave > > > > > > > >_______________________________________________ >SIP mailing list >SIP@lists.bell-labs.com >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 Sep 7 09: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 ESMTP id JAA16133 for ; Thu, 7 Sep 2000 09: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 0717A443C8; Thu, 7 Sep 2000 08:47:32 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from polaris.shore.net (polaris.shore.net [207.244.124.105]) by lists.bell-labs.com (Postfix) with ESMTP id 743F7443B5 for ; Thu, 7 Sep 2000 08:47:29 -0400 (EDT) Received: from (hither.rfdsoftware.com) [209.192.222.62] by polaris.shore.net with esmtp (Exim) id 13X21L-0001PN-00; Thu, 07 Sep 2000 09:47:15 -0400 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 JAA27859; Thu, 7 Sep 2000 09:40:21 -0400 (EDT) Message-Id: <4.3.2.7.2.20000901073305.00d8ae60@webhost.tactical-sw.com> X-Sender: dnyon@webhost.tactical-sw.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 07 Sep 2000 09:46:09 -0400 To: "Fairlie-Cuninghame, Robert" , sip@lists.bell-labs.com From: David Yon Subject: RE: [SIP] SIP, SDP, and TCP-based media transport 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Thanks for the quick feedback. Sorry it has taken so long to follow up. At 08:08 PM 8/29/00 -0700, Fairlie-Cuninghame, Robert wrote: >Hi David, > >Great work !! > >Here are my comments: > >- Section 1.2: Are you referring to the driection parameter ? If so, then >Section 1.1 should also refer to this parameter to be consistent. The direction parameter goes on the a= line, not the m= line. The "fmt" identifier is a qualification of the protocol above TCP. For want of a better example, "t38" would be a valid entry in that position on the m= line. >- I think there should be an assumed direction of "both" if the direction >parameter is missing. I'm pretty agnostic on this issue, so if nobody else has a problem with it I can live with that. >- IMO, in Section 2.3 the statement "Endpoints may choose to specify >direction:both under one or more of the following conditions:" should be >reworded as none of the bullets are really "conditions". Perhaps "Endpoints >may choose to specify direction:both for one of the following reasons:" >would be better. Agreed, fixed. >- In the case of both sides using "direction:both" I believe we decided not >to close either of the tcp connections to avoid a race condition. I think I've finally had some time to work through some of the scenarios, and I think the solution is to abandon the "highest port wins" heuristic and replace it with the following: In the event that both TCP connections succeed: 1) Each endpoint MUST accept data from either TCP connection. 2) Once an endpoint has started to transmit data on one of the TCP connections, it MUST use that TCP connection exclusively for transmission. 3) If as a result of (2), one of the TCP connections is determined to be idle, either endpoint MAY close the idle TCP connection. I think that gets rid of the race condition, works through an ALG where port numbers might change, yet still allows one of the connections to be shut down when circumstances permit. Worst case is each connection becomes unidirectional. Comments? Anyone see a hole I missed? >someone made to point that the stated algorithm doesn't work is both sides >are behind ALGs. Can anyone confirm? I'm having trouble parsing this sentence to begin with, never mind recalling the original issue. :-) Could you rephrase? >- I think that "the endpoints intend to use one/two TCP connections" should >be removed from the second and third reasons for using direction:both >(Section 2.3). If we are not dropping one of the TCP connections (see above) >then those two statements don't make a lot of sense. In my mind, there are >only two main reasons for using direction:both: 1) want to allow otherside >to specify either active or passive [your first point] 2) want to be able to >traverse a NAT or NAPT [your second point]. I agree with most, but not all of this. Certainly if you "want to be able to traverse a NAT/NAPT", then you likely would only need a single TCP connection but are forced to attempt two in order to determine who has the unimpeded path. >- In the case of both sides using "direction:both", it also needs to be >stated that each endpoint must be willing to receive media from either or >both connections. Yes. 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 Thu Sep 7 09:58: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 ESMTP id JAA16255 for ; Thu, 7 Sep 2000 09:58: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 44E87443CC; Thu, 7 Sep 2000 08:58:00 -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 1E60A443CC for ; Thu, 7 Sep 2000 08:51: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 JAA21392 for ; Thu, 7 Sep 2000 09:51:11 -0400 (EDT) Message-ID: <39B79D4F.36EC50E1@cs.columbia.edu> Date: Thu, 07 Sep 2000 09:51:11 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.72 [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] Addressing devices without user identities Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit This is just a heads-up, in case it needs more discussion. Some SIP devices allow "dialing" IP addresses, but seem to have different notions as to the user name to be used. I've seen 'sip:anybody@128.1.2.3', for example. This is not what the spec intends, however. It says: user: The name of the user addressed. Note that this field MAY be empty where the destination host does not have a notion of users, e.g., for embedded devices. Thus, 'sip:128.1.2.3' would be the correct approach. -- 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 Sep 7 10:22: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 ESMTP id KAA16791 for ; Thu, 7 Sep 2000 10:22: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 ACC06443D5; Thu, 7 Sep 2000 09:21:50 -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 AAA31443B5 for ; Thu, 7 Sep 2000 09:21:43 -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 e87EHml13635; Thu, 7 Sep 2000 17:17:49 +0300 (EET DST) Received: by daebh02nok with Internet Mail Service (5.5.2448.0) id ; Thu, 7 Sep 2000 09:17:47 -0500 Message-ID: From: Cliff.Harris@nokia.com To: etremblay@mediatrix.com Cc: sip@lists.bell-labs.com Subject: RE: [SIP] Possible REFER problem? Date: Thu, 7 Sep 2000 09:11:42 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com 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. Although it is not the intention of To tags that they be included in INVITEs to new sessions, UAS's currently may allow new INVITEs with To tags as a means of working around a crash. So why not take advantage of that to make REFERs more robust (and maybe add a couple of SHOULDs to the RFC)?. > -----Original Message----- > From: EXT Eric Tremblay [mailto:etremblay@mediatrix.com] > Sent: Monday, September 04, 2000 8:24 PM > To: Robert Sparks (E-mail) > Cc: sip@lists.bell-labs.com > Subject: [SIP] Possible REFER problem? > > > Hi, > > I think I see a possible problem with the REFER request in > the context of a > call transfer with consultation: > > Suppose that Transferor and Transferee are connected. Transferor puts > Transferee on hold and calls Transfer Target (TT). After the > brief call > between Transferor and TT, Transferor sends a REFER request > to Transferee: > > Transferor has 2 choices for the URL to put into the Refer-To > header of the > REFER request. It can either use the contact it has received > in the 200 > response of the call with TT or it can use the original URL > it has used to > establish the call to TT (which usually points to a proxy or redirect > server). > > I think that using the contact URL in the Refer-To is not the > best thing to > do because this could bypass some of the system policies that > requires all > calls to go trough a proxy (for tracing, billing or whatever > services). > Note that this is fixed by having TT return a 305 response to > the INVITE > received from Transferee, in which case Transferee should > resend the INVITE > to a proxy. > > On the other hand, when using the original URL in the > Refer-To, I think it > is possible that the call from Transferee to TT will be > routed to a totaly > different destination, probably because the proxy has forked > and someone > else has answered before TT could. > > > I think the problem is as follows: > > How can we make sure that the INVITE from Transferee to TT > will be answered > by the same UA as the INVITE from Transferor to TT? I think > that we want to > allow some mobility to TT, but I also think that we would > like to reach the > exact same UA as the call between Transferor and TT. > > 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. > > First, is this really a problem or I'm forgetting something? > > 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 > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Sep 7 10: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 ESMTP id KAA17106 for ; Thu, 7 Sep 2000 10: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 9C9B8443D1; Thu, 7 Sep 2000 09:31:34 -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 829D5443B7 for ; Thu, 7 Sep 2000 09:31:30 -0400 (EDT) Received: from driftwood.cisco.com (driftwood.cisco.com [171.71.157.40]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id HAA26620; Thu, 7 Sep 2000 07:31:44 -0700 (PDT) Received: from cisco.com ([171.71.159.231]) by driftwood.cisco.com (Mirapoint) with ESMTP id ACF12981; Thu, 7 Sep 2000 09:28:14 -0500 (CDT) Message-ID: <39B7A6FE.D615452F@cisco.com> Date: Thu, 07 Sep 2000 09:32:30 -0500 From: Hong Chen Organization: Cisco Systems X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Rohan Mahy Cc: Tom-PT Taylor , Henning Schulzrinne , Jonathan Rosenberg , Anders Kristensen , sip@lists.bell-labs.com Subject: Re: [SIP] SIP feature services References: <28560036253BD41191A10000F8BCBD11480D07@zcard00g.ca.nortel.com> <4.2.0.58.20000906103512.019e1020@lint.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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Rohan Mahy wrote: > Henry, > > Different web browsers do not all display the same content in exactly the > same way, but they the server still interoperates with all of these browsers. > > Likewise SIP UAs don't have to act exactly the same way, as long as the > right parties end up communicating. That said, I think the *example* call > flow work is extremely important, but I feel that the examples plus the > bakeoff is sufficient guidance to yield interoperable product. I agree, " the *example* call flow work is extremely important" for the success of SIP and expect to have it ASAP, plus I hope it will have some guideline of the systematic mechanism we can use for features not included in example and features in the future. > > > Ultimately, the market will decide what variations people like. > > thanks, > -rohan > > At 09:42 AM 9/6/00 , Hong Chen wrote: > > > > > >Tom-PT Taylor wrote: > >> > >> > >>The answer to all this that I'm seeing in my admittedly limited > >>experience is that individual networks define how they want services to > >>operate and expect vendors to support the resulting information flows. > >You might be right. But we do not want to break one of the promising SIP > >principals by feature services: Interoperability. > >> > >> > -----Original Message----- > >> > From: Hong Chen [mailto:hjlechen@cisco.com] > >> > Sent: Tuesday, September 05, 2000 1:33 PM > >> > To: Henning Schulzrinne > >> > Cc: Jonathan Rosenberg; Anders Kristensen; sip@lists.bell-labs.com > >> > Subject: Re: [SIP] SIP feature services > >> > > >> > > >> > > >> > > >> > Henning Schulzrinne wrote: > >> > > >> > > Hong Chen wrote: > >> > > > > >> > > > Jonathan Rosenberg wrote: > >> > > > >> > > > I agree that additional standardization may not be > >> > necessary, but a standard call > >> > > > model > >> > > > for sip proxy may help for the feature developments and > >> > interpretability. > >> > > > >> > > Attempts at a call model have been made by various people. > >> > See the draft > >> > > archives. Whether they are useful is another question. > >> > > > >> > > > > >> > > > EX.. of features which need network controls and hard to > >> > define trigs in sip proxy. > >> > > > (1) Call Park (Park a call and then pick the call later > >> > somewhere else). > >> > > > (2) Call Pick Up (Answer a call which is ringing > >> > somewhere else in a call pick up > >> > > > group). > >> > > > (3) Adhoc conference using centralized conference bridge. > >> > > > and more. > >> > > > >> > > These services were discussed extensively on this list a > >> > number of weeks > >> > > ago (see the list archives), with different solutions > >> > proposed, since it > >> > > doesn't make sense to translate the behavior exactly from > >> > PSTN to IP. > >> > > Conferencing is also addressed in the SIP FAQ and requires > >> > no SIP proxy. > >> > > > >> > > >> > (1) It may not make sense to translate the behavior exactly > >> > from PSTN to IP, but people > >> > are still looking for > >> > those traditional services. > >> > > >> > (2) The key point here is: > >> > There may be hundred suggested different ways for > >> > some service by SIP signaling. > >> > The question is which is the best systematic > >> > mechanism we should follow and we > >> > can also easily > >> > use this same systematic mechanism for any new > >> > feature service later. > >> > > >> > > >> > > >> > > > >> > > -- > >> > > Henning > >> Schulzrinne http://www.cs.columbia.edu/~hgs > >> > > >> > > >> > > >> > _______________________________________________ > >> > 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.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Sep 7 11:40:57 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19137 for ; Thu, 7 Sep 2000 11:40: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 8F71B443B5; Thu, 7 Sep 2000 10:39:59 -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 0C4A04435F for ; Thu, 7 Sep 2000 10:39:52 -0400 (EDT) Received: from zrtpd004.us.nortel.com by zrtps06s.us.nortel.com; Thu, 7 Sep 2000 11:39:10 -0400 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Thu, 7 Sep 2000 11:39:09 -0400 Message-ID: <28560036253BD41191A10000F8BCBD11480D40@zcard00g.ca.nortel.com> From: "Tom-PT Taylor" To: "'Rohan Mahy'" , Skip Cave Cc: sip@lists.bell-labs.com Subject: RE: [SIP] Two Keystroke Encodings Date: Thu, 7 Sep 2000 11:39:06 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C018E1.C196FD20" X-Orig: Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com 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_01C018E1.C196FD20 Content-Type: text/plain; charset="iso-8859-1" At least some of this debate seems to be a replay of the ancient (from ISDN days) stimulus vs. functional protocol debate. Skip is talking about stimulus signalling, Rohan about functional. Oldtimers can tell you the merits of each, and also that functional may have won in the short term, but stimulus keeps coming back. Tom T > -----Original Message----- > From: Rohan Mahy [mailto:rohan@cisco.com] > Sent: Wednesday, September 06, 2000 8:12 PM > To: Skip Cave > Cc: sip@lists.bell-labs.com > Subject: Re: [SIP] Two Keystroke Encodings > > > At 02:41 PM 9/6/00 , Skip Cave wrote: > >Rohan Mahy said: What is your definition of a key or keystroke? > >http://lists.bell-labs.com/pipermail/sip/2000q3/002612.html > > > >Skip Cave says: A keystroke occurs whenever the terminal device user > >presses a key on the terminal device. > > > >I think you are missing a critical point here. T.140 is > designed for text > >chat, where the characters are simply renderred, rather than > interpreted. > > > >I have no idea what the difference between "rendering" and > "interpreting" > >a keystroke is. When you press a key, you want an indication > that the key > >is pressed to be passed over the network to the application > server. If you > >are saying that the terminal device should somehow "interpret" the > >keystroke and convert it into some other form, that could be > an option. > >You certainly can have the application in the terminal > translate other UI > >actions into keystrokes if you like. > > > I don't want to translate anything *into* keystrokes. I don't want > keystrokes to become somehow a fundamental form of input that > everything > else is translated into. I want a generic input mechanism (like HTML > forms). In this kind of scheme, keystrokes and clicks and > voice commands > and other input would all be equal. > > > >I don't think this is what you want. AVT tones is designed > for carrying > >input that has traditionally been associated with the > telephony world. If > >a SIP UA has a keypad that looks like a DTMF keypad, then > _most of the > >time_ it should act like a DTMF keypad, and send the > corresponding AVT > >encoding. > > > >What if the SIP UA has 5 keys, or 10 keys, or 20 keys, or 40 > keys? Which > >encoding scheme do you use then? Just because 12 keys is a > "tradition" > >doesn't mean that there should be something magic about > > the fact is that many SIP UAs will have these specific 12 > keys because they > want them to work more or less like the 12-keys on the > original touch-tone > telephone. the reason it has such a pad is so it can > interoperate with the > PSTN and other PSTN networks. > > if your UA has a graphical representation of a DTMF keypad, > chances are, > that keypad is still used for interop with a TDM network, and > it should > also generate AVT over RTP when you click on those things. > > >12 keys that causes them to use a different protocol. > > > >Applications don't just get keystrokes from a terminal. > Applications need > >to send keystrokes TO a terminal. > > this is news. please supply an example. > > >Which encoding scheme do I use? How do I tell whether the > SIP device that > >I am sending keystrokes to should get RFC 2833 or RC 2793? > > why are you sending "keystrokes". I think you should either > send DTMF or > generic input. > > >If you are interested in getting generic input, I would use > something > >completely different that has nothing to do with RTP. For > example, if I > >write some characters on my Palm, is that a keystroke? > > > >The application running on the Palm can certainly issue a keystroke > >indication to the network when a number or letter is written > on the Palm > >screen. > > > >This is an excellent example of how an application in the > network can be > >written to use a generic keystroke protocol. The various > device types can > >be adapted to utilize this model, even if they don't have keys. > > > >If I tap a region on a touchscreen, or select a region with > a mouse, is > >that a keystroke? > > > >Again, you can do this if the application warrants. This approach is > >particularly useful when the device does not have enough > keys to support > >the application, but the device has .some other user input > mechanism that > >can be converted to a keystroke indication. > > again, I don't want to convert anything to keystrokes. I > don't need this > on web pages (where I can have similar one decision at-a-time > pages), so > why do I need this on SIP? > > >Essentially, keystrokes become THE general-purpose > >user-input-event-reporting mechanism for terminals on the > packet network. > > YUCK! > > >What about speech rec of canned vocabularies (Yes, No, numbers..) > > > >If your speech rec is resident in the terminal device, > converting the > >spoken phrases into keystroke indications is a good way to > generalize an > >application so it could work on anything from a simple > phone, all the way > >up to a > > I think you've got it backwards. If you use a generic input > scheme to > begin with, then the UA can render that in any appropriate > way (just like a > web page). You shouldn't start with one input mechanism and > promote it to > King of All Input Methods, then expect everyone to translate. > Keystrokes > are particularly bad at this. How do I enter Chinese or > Kanji characters > for example? > > >voice-reco-enabled wireless PDA. > > > >The application can ask: "Please say what you would like to > do next, or > >press 1 for your account balance, 2 for ... etc." In this > way the exact > >same application in the network could work across simple > PSTN phones or > >voice- reco-enabled wireless PDAs. The network-based > application just sees > >keystroke indications, no matter what the terminal device looks like. > > NO, NO, NO, NO, NO! > > The application logic has a list of choices in your example > menu. It does > not need to be the responsibility of the application to choose that > 1=account balance. The app doesn't have to say "Please press > "1" or say > "balance". The UA should do that. If the UA is a TDD device, it can > display "Please *type* "balance", "sales", or "operator". If > the UA has no > screen and a DTMF-pad, and the user is Spanish it can say, > ".. marque el > numero uno .." > > >Do we care? > > > >If your question is: "Do we care about what user actions are > classified as > >keystrokes", the answer is no. Any user action can be > classified as a > >keystroke by the terminal device. If the terminal device has the > >capability to understand a particular mode of user input > (keystrokes, > >stylus taps, spoken words, eye winks, etc.) it can report > that action as a > >keystroke or user event. > > > >I think what we are really after is a way to send the kind > of "menus" and > >"forms" that we are now used to in traditional IVRs, down to the end > >device (a SIP UA), where it can render the request as speech, text, > >buttons, whatever; the *method* of input is irrelevant. It is the > >selection of a particular menu choice, or the completion of > a specific bit > >of information (account number) that your service logic > cares about, so > >let the end-system render the damn thing. > > > >.... clipped example of VoXML > > > >The model you present is certainly one of the many interesting > >architectures proposed for providing a user interface on a terminal > >device. You can download all of the user prompts (both > spoken and printed) > >to the terminal device before presenting them. You can > download all of the > >interaction logic to the terminal device so it can present > the complete > >user interaction with minimal external intervention. You can > aggregate or > >store all of the user input in the terminal (keyed, spoken, tapped, > >winked, etc.) assuming the device can detect and understand > the input, and > >transmit the result of the complex user interaction at the very end. > > > >In this scenario, you certainly don't need a keystroke protocol to > >propogate the result of the complex user interactions. A > XML-structured > >message carrying the result of a complex user interaction from the > >terminal device to the application server in the network, is > probably the > >way to go. > > > >VoXML provides an alternate apporoach. VoXML stores all of the user > >prompts, interaction logic, and user input on the "Voice Browser". > >Actually, the interaction logic can be said to reside at the > VoXML page's > >URL, but in any case it isn't in the terminal device. The > terminal device > >can be very "dumb". This model is suitable when you don't > want to put lots > >of smarts, storage, or fancy UI equipment on the terminal > device, and that > >isn't just on PSTN phones! Don't forget, in this model, > VoXML relies on a > >standardized keystroke protocol (DTMF) to communicate the > user input to > >the VoXML server. > > > >So we have at least two models - everything on the device, > and everything > >in the network. The first approach makes for simpler network > devices. The > >latter approach has the advantage of simpler terminal > devices. But simpler > >terminal devices REQUIRES a standard input event (or > keystroke) model. > > You can ask around, but I think the trend is for more stuff > on the end > systems. If you really want dumb and simple, you can make a > SIP device > with just a DTMF keypad, or you can implement a stimulus > response protocol > like MGCP or Cisco's "Skinny", but that is not within the SIP > WG charter. > > >However, the general architecture should support both of > these models. If > >you decide that you want to build a SIP device that is > really dumb, and > >it won't support XML or WAP pages, and it won't support > voice reco, and it > >won't support a display, you should still be able to do it. > VoXML points > >the way. > > > >Remember, not all terminal devices will have the capability to store > > > >a sequence of keystrokes, > > that's absurd. what terminal device that can speak SIP can't store a > sequence of keystrokes? SIP requires enough storage to keep > TCBs and store > packets for possible retransmission. They have to have at > least SOME memory. > > >let alone do voice reco, locally. These dumb terminal > devices may be a > >PSTN device, but they may not. You should be able to build a > SIP device > >that essentially has no UI except a few keys and a display > or speaker, > >with no storage requirements other > > > >than the display matrix. > > > >In any case, VoXML REQUIRES that the dumb device have a keystroke > >reporting mechanism, if it doesn't have an audio input > mechanism for voice > >reco, or particularly if can't even aggregate keystrokes > locally. So, > >there is already the requirement for a keystroke standard. VoXML > >originally was focused on calls from a PSTN phone to a Voice > Browser, but > >the calling device could easily be a simple SIP device. > > > >The VoXML device may have 5 keys, or 10 keys, or 200 keys, but the > >"dumb-terminal, smart-network-server" model needs a way to get the > >keypresses, (or stylus-taps, or eye-winks) to the "smart" > application > >server (or VoXML server, or Telephony Platform, or whatever) > over the > >network in a standard way. > > > >Remember, some terminal devices will not have the capability to store > > > >a sequence of keystrokes, let alone do voice reco, locally. > > > >I like this model. I'm much less interested in "keystrokes" > than generic > >input (VoXML-type model works here), > > > >I'm not sure what you mean by "generic input". If you mean: > Pressing the > >"5" key OR, saying the word "five" OR, scribing the symbol > "5" on the > >screen with the stylus will result in a "5-key pressed" > message from the > >terminal. If this is what you mean by "generic input", then > I agree with you. > > please look carefully at html forms. for example: > > > > > > the select tag presents a list of options. it returns that > menu-choice="balance", not that the menu choice was "5". > > the first input tag collects a complete string. not "5", but > "546325245" > and will eventually POST that information back. > > > >and I think most SIP UAs will want the ability to talk to > the PSTN some > >of the time (AVT tones model will be needed here). > > > >A SIP UA should never need to know whether it is sending > keystrokes to a > >PSTN device or another SIP device. The protocol to achieve > both should be > >identical. For one thing, it probably won't be easy to > figure out whether > >the device you are estasblishing a SIP session with is in > the PSTN or the > >packet network. You definitely should NOT be REQUIRED to find out. > > > >If, in the course of an application. I want to send the key > indication "5" > >to the other device, I do not want to have to figure out > whether to send > >the info as RFC 2833 or RFC 2739. There should only be one way. > > Don't worry, you won't find anyone at the SIP bakeoff who > will try to send > the "5" character to a terminal using RFC 2739. > > >If we need to get DTMF input to a party that isn't otherwise > involved in > >media, we can either tunnel AVT tones inside of SIP, or > > > >"conference" in the third party for AVT tones only. > > > >No, just send standard keystrokes in a standard protocol > that all devices > >(or their proxies) understand. > > You assume that everyone else shares your love of keystrokes. > > >Henning said: See also the WAP menu model. (This is probably > separable > >from the rest of the WAP stuff.) Also, you're well on your > way to just > >downloading Java or Javascript. I don't think that voice and menu > >interaction are all that similar except in the most trivial > cases. For > >example, you typically present many menu fields visually at > the same time, > >but (naturally) only one at a time with voice. > >http://lists.bell-labs.com/pipermail/sip/2000q3/002614.html > > > >Again, this model assumes that you want to store the > interaction logic on > >the terminal device. The interaction logic is may be simply > > > >keystroke aggregation, or full blown Javascript and voice > reco, but you do > >not want to force this model as the only way to do user interactions. > > why not. it is probably nearly as light at this point to > implementing > keystrokes on top of RTP. > > thanks, > -rohan > > > > >You may not want to put a WAP browser or voice reco on the terminal > >device. A particular application provider may be prefectly > happy with a > >simple 5 or 10-key terminal device with no display. The > standard keystroke > >model solves these issues simply and powerfully. > > > >Skip Cave Sr. Principal Engineer InterVoice-Brite Inc. > > > > > > > > > > > > > > > > Rohan Mahy > > >What is your definition of a key or keystroke? > > > >I think you are missing a critical point here. T.140 is > designed for text > >chat, where the characters are simply renderred, rather than > >interpreted. I don't think this is what you want. AVT > tones is designed > >for carrying input that has traditionally been associated with the > >telephony world. If a SIP UA has a keypad that looks like a > DTMF keypad, > >then _most of the time_ it should act like a DTMF keypad, > and send the > >corresponding AVT encoding. > > > >If you are interested in getting generic input, I would use something > > > >completely different that has nothing to do with RTP. For > example, if I > >write some characters on my Palm, is that a keystroke? If I > tap a region > >on a touchscreen, or select a region with a mouse, is that a > >keystroke? What about speach rec of canned vocabularies (Yes, No, > >numbers..) Do we care? > > > >I think what we are really after is a way to send the kind > of "menus" and > >"forms" that we are now used to in traditional IVRs, down to the end > >device (a SIP UA), where it can render the request as > speech, text, buttons, > > > >whatever; the *method* of input is irrelevant. It is the > selection of a > >particular menu choice, or the completion of a specific bit > of information > >(account number) that your service logic cares about, so let the > >end-system render the damn thing. > > > >An example of such a system is a "distributed IVR" that uses > VoXML on each UA. > > > >If I want the help-desk... > > > >INVITE sip:help-desk@company.com SIP/2.0 To: > > > >301 Moved Contact: > > > > >I get a reference to the script, then start running it. At > the end of > >some of the menus are SIP URLs. > > > >sip:card-replacement-line@company.com?Priority=urgent&Subject > =account714352 > > > > > >I like this model. I'm much less interested in "keystrokes" > than generic > >input (VoXML-type model works here), and I think most SIP > UAs will want > >the ability to talk to the PSTN some of the time (AVT tones > model will be > > > >needed here). If we need to get DTMF input to a party that isn't > >otherwise involved in media, we can either tunnel AVT tones > inside of SIP, > >or "conference" in the thrid party for AVT tones only. > > > >thanks, -rohan > > > > > >At 08:30 PM 9/5/00 , Skip Cave wrote: My last post on this > subject did not > >get any discussion. This usually means that everyone agrees, > or no one > >understood it. Since what I was preposing was fairly > radical, I assume the > >no-response was because of my poor description of the issue, and > >resulting incomprehension. I will try again, and this time I > won't mix > >together so many issues in one post. Henning and Jonathan > have shown > >generally how RTP can be used as a mechanism to carry > keystrokes. They > >have shown how the delivery can be made reliable. This > clears several > >significant hurdles in the path towards using RTP as a > practical keystroke > >transport method. There are only a few remaining issues. The > following > >discussion addresses the next critical issue. Colin Perkins > writes: I > >suggest you read RFC 2793 which describes how to use RFC > 2198 redundancy > >as a `reliable' transport for non-audio > >keystrokes. > http://lists.bell-labs.com/pipermail/sip/2000q3/002113.html > >RFC 2793 - "RTP Payload for Text Conversation" is an RFC which I > >had somehow overlooked (thank you, Colin) which proposes a > method to use > >RTP to transport T.140 "text conversation" sessions. So, > the IETF now has > >two different protocols to transmit exactly the same data - > keystrokes - > >over RTP: RFC 2833, and RFC 2793. The primary difference > between the two > >protocols is simply the encoding of the keystrokes. RFC > 2833 uses the > >following encoding for keys: Event encoding (decimal) > >_________________________ 0--9 0--9 > >* 10 # 11 > >A--D 12--15 RFC 2833 doesn't define encodings > for any other > >keys. It seems to assume that all devices will only have a > maximum of 16 > >keys. RFC 2793 proposes ISO/IEC 10646-1, level 3 (Unicode) > encoding to > >define a much larger set of keys, but the 16 keys defined in > RFC 2833 are > >also included in the RFC 2973 encoding: 0x0030 DIGIT ZERO > >0x0031 DIGIT ONE 0x0032 DIGIT TWO 0x0033 > DIGIT > >THREE 0x0034 DIGIT FOUR 0x0035 DIGIT FIVE > >0x0036 DIGIT SIX 0x0037 DIGIT SEVEN 0x0038 > DIGIT > >EIGHT 0x0039 DIGIT NINE ....... 0x0041 LATIN CAPITAL > >LETTER A 0x0042 LATIN CAPITAL LETTER B 0x0043 LATIN > >CAPITAL LETTER C 0x0044 LATIN CAPITAL LETTER D ......... > >0x002A ASTERISK 0x0023 NUMBER SIGN ....... > As you can > >see, the two protocols have two vastly different ways to > encode exactly > >the same thing - numeric & alphabetic keys on a terminal > device. Some > >other issues with the two protocols: RFC 2833 allows the > transmission of > >keystrokes from a terminal over RTP. However, RFC 2833 also > defines a > >large set of other events besides keystrokes that can be > carried in the > >same RTP stream format: o DTMF tones (Section > >3.10); o fax-related tones (Section 3.11); o standard > >subscriber line tones (Section 3.12); o > country-specific subscriber > >line tones (Section 3.13) and; o trunk events (Section > 3.14). While > >this multiple-event-type property may be useful in some PSTN > transport > >applications, it is definitely not appropriate as a general > keystroke > >communications mechanism. Many applications will not want > anything but > >keystrokes to come over the RTP session - no audio, no fax > tones. RFC > >2793 also allows the transmission of keystrokes from a > terminal over RTP. > >This RFC uses ISO/IEC 10646-1, level 3 to define a much > larger set of > >possible keys, but the keys on a 12-button terminal device are all > >included in the larger set. This RFC does not include any > other event > >types except keystrokes, but RFC 2793 does not include a > method to carry > >keystroke duration as a function of the protocol. So to > summarize: RFC > >2833 1) doesn't cover all of the possible keys available in > a terminal > >device 2) carries extra stuff besides keystrokes in the > protocol RFC 2793 > >1) Doesn't carry keystroke duration information. Meanwhile, both > >protocols use the same redundancy mechanism (RFC 2198) for > more reliable > >delivery of keystrokes. My issue: As a general rule, a device > >establishing a SIP session with another device should not > have to discover > >what type of device it is sessioning with before knowing > whether to send > >keystrokes using RFC 2833 or RFC 2793 over the RTP session. > There should > >be only one protocol and one encoding for keystrokes in SIP and RTP, > >regardless of the device that has the keys on it. My > solution: Combine > >the best of RFC 2833 and RFC 2793 for a universal keystroke > protocol. 1) > >Use RFC 2793's encoding scheme for all keys along with T.140 > protocol > >stucture 2) Use RFC 2833's duration scheme for keystroke > durations 3) Use > >RFC 2198 for reliability 4) Remove the DTMF keystroke events > from from > >Section 3 of RFC 2833 and keep that protocol format specifically for > >telephony events (fax tones, subscriber line tones, etc.). > 5) Add a new > >payload format in RFC 2833 that is specifically for > keystrokes using the > >2833-2973 hybrid protocol. In this way, you could INVITE only the > >2833-2973 hybrid protocol if you wanted just keystrokes, or > you could > >INVITE the RTP audio also, or just the telephony events, or any > >combination using SDP media control mechanisms (m=3D) In my > company's > >applications we plan to establish SIP sessions with > PSTN/SIP Gateways, > >Softswitches, SIP phones, SIP mobile devices, and SIP PCs. > The key input > >from all of these different sources should use the same > protocol. The key > >input that we send to all of these devices should use the > same protocol. > >We don't want to have to use different protocols to send > keystrokes to a > >SIP gateway, a SIP wireless device, a Softswitch, or a PC. > We don't want > >to have to know ahead of time what type of device we are calling to > >determine what kind of session to INVITE to get keystrokes. > The keystroke > >protocol for all devices that have keys should be the same. If PSTN > >transport application developers vendors want to stick fax > tones and call > >progress in with the compressed audio in a > gateway-to-gateway RTP session, > >that's fine. Just don't make everybody have to support those > events when > >all you want are keystrokes. Skip Cave > > > > > > > > > > > > > >_______________________________________________ > >SIP mailing list > >SIP@lists.bell-labs.com > >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_01C018E1.C196FD20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [SIP] Two Keystroke Encodings

At least some of this debate seems to be a replay of = the ancient (from ISDN days) stimulus vs. functional protocol = debate.  Skip is talking about stimulus signalling, Rohan about = functional.  Oldtimers can tell you the merits of each, and also = that functional may have won in the short term, but stimulus keeps = coming back.

Tom T

> -----Original Message-----
> From: Rohan Mahy [mailto:rohan@cisco.com]
> Sent: Wednesday, September 06, 2000 8:12 = PM
> To: Skip Cave
> Cc: sip@lists.bell-labs.com
> Subject: Re: [SIP] Two Keystroke = Encodings
>
>
> At 02:41 PM 9/6/00 , Skip Cave wrote:
> >Rohan Mahy said: What is your definition of = a key or keystroke?
> >http://lists.bell-labs.com/pipermail/sip/2000q3/002612= .html
> >
> >Skip Cave says: A keystroke occurs whenever = the terminal device user
> >presses a key on the terminal = device.
> >
> >I think you are missing a critical point = here.  T.140 is
> designed for text
> >chat, where the characters are simply = renderred, rather than
> interpreted.
> >
> >I have no idea what the difference between = "rendering" and
> "interpreting"
> >a keystroke is. When you press a key, you = want an indication
> that the key
> >is pressed to be passed over the network to = the application
> server. If you
> >are saying that the terminal device should = somehow "interpret" the
> >keystroke and convert it into some other = form, that could be
> an option.
> >You certainly can have the application in = the terminal
> translate other UI
> >actions into keystrokes if you like.
>
> <philosophy>
> I don't want to translate anything *into* = keystrokes.  I don't want
> keystrokes to become somehow a fundamental form = of input that
> everything
> else is translated into.  I want a generic = input mechanism (like HTML
> forms).  In this kind of scheme, = keystrokes and clicks and
> voice commands
> and other input would all be equal.
> </philosophy>
>
> >I don't think this is what you want.  = AVT tones is designed
> for carrying
> >input that has traditionally been = associated with the
> telephony world.  If
> >a SIP UA has a keypad that looks like a = DTMF keypad, then
> _most of the
> >time_ it should act like a DTMF keypad, and = send the
> corresponding AVT
> >encoding.
> >
> >What if the SIP UA has 5 keys, or 10 keys, = or 20 keys, or 40
> keys? Which
> >encoding scheme do you use then? Just = because 12 keys is a
> "tradition"
> >doesn't mean that there should be something = magic about
>
> the fact is that many SIP UAs will have these = specific 12
> keys because they
> want them to work more or less like the 12-keys = on the
> original touch-tone
> telephone.  the reason it has such a pad = is so it can
> interoperate with the
> PSTN and other PSTN  networks.
>
> if your UA has a graphical representation of a = DTMF keypad,
> chances are,
> that keypad is still used for interop with a = TDM network, and
> it should
> also generate AVT over RTP when you click on = those things.
>
> >12 keys that causes them to use a different = protocol.
> >
> >Applications don't just get keystrokes from = a terminal.
> Applications need
> >to send keystrokes TO a terminal.
>
> this is news.  please supply an = example.
>
> >Which encoding scheme do I use? How do I = tell whether the
> SIP device that
> >I am sending keystrokes to should get RFC = 2833 or RC 2793?
>
> why are you sending = "keystrokes".  I think you should either
> send DTMF or
> generic input.
>
> >If you are interested in getting generic = input, I would use
> something
> >completely different that has nothing to do = with RTP.  For
> example, if I
> >write some characters on my Palm, is that a = keystroke?
> >
> >The application running on the Palm can = certainly issue a keystroke
> >indication to the network when a number or = letter is written
> on the Palm
> >screen.
> >
> >This is an excellent example of how an = application in the
> network can be
> >written to use a generic keystroke = protocol.  The various
> device types can
> >be adapted to utilize this model, even if = they don't have keys.
> >
> >If I tap a region on a touchscreen, or = select a region with
> a mouse, is
> >that a keystroke?
> >
> >Again, you can do this if the application = warrants. This approach is
> >particularly useful when the device does = not have enough
> keys to support
> >the application, but the device has .some = other user input
> mechanism that
> >can be converted to a keystroke = indication.
>
> again, I don't want to convert anything to = keystrokes.  I
> don't need this
> on web pages (where I can have similar one = decision at-a-time
> pages), so
> why do I need this on SIP?
>
> >Essentially, keystrokes become THE = general-purpose
> >user-input-event-reporting mechanism for = terminals on the
> packet network.
>
> YUCK!
>
> >What about speech rec of canned = vocabularies (Yes, No, numbers..)
> >
> >If your speech rec is resident in the = terminal device,
> converting the
> >spoken phrases into keystroke indications = is a good way to
> generalize an
> >application so it could work on anything = from a simple
> phone, all the way
> >up to a
>
> I think you've got it backwards.  If you = use a generic input
> scheme to
> begin with, then the UA can render that in any = appropriate
> way (just like a
> web page).  You shouldn't start with one = input mechanism and
> promote it to
> King of All Input Methods, then expect everyone = to translate.
>  Keystrokes
> are particularly bad at this.  How do I = enter Chinese or
> Kanji characters
> for example?
>
> >voice-reco-enabled wireless PDA.
> >
> >The application can ask: "Please say = what you would like to
> do next, or
> >press 1 for your account balance, 2 for ... = etc." In this
> way the exact
> >same application in the network could work = across simple
> PSTN phones or
> >voice- reco-enabled wireless PDAs. The = network-based
> application just sees
> >keystroke indications, no matter what the = terminal device looks like.
>
> NO, NO, NO, NO, NO!
>
> The application logic has a list of choices in = your example
> menu.  It does
> not need to be the responsibility of the = application to choose that
> 1=3Daccount balance.  The app doesn't have = to say "Please press
> "1" or say
> "balance".  The UA should do = that.  If the UA is a TDD device, it can
> display "Please *type* "balance",= "sales", or "operator".  If
> the UA has no
> screen and a DTMF-pad, and the user is Spanish = it can say,
> ".. marque el
> numero uno .."
>
> >Do we care?
> >
> >If your question is: "Do we care about = what user actions are
> classified as
> >keystrokes", the answer is no. Any = user action can be
> classified as a
> >keystroke by the terminal  device. If = the terminal device has the
> >capability to understand a particular mode = of user input
> (keystrokes,
> >stylus taps, spoken words, eye winks, etc.) = it can report
> that action as a
> >keystroke or user event.
> >
> >I think what we are really after is a way = to send the kind
> of "menus" and
> >"forms" that we are now used to = in traditional IVRs, down to the end
> >device (a SIP UA), where it can render the = request as speech, text,
> >buttons, whatever;  the *method* of = input is irrelevant.  It is the
> >selection of a particular menu choice, or = the completion of
> a specific bit
> >of information (account number) that your = service logic
> cares about, so
> >let the end-system render the damn = thing.
> >
> >.... clipped example of VoXML
> >
> >The model you present is certainly one of = the many interesting
> >architectures proposed for providing a user = interface on a terminal
> >device. You can download all of the user = prompts (both
> spoken and printed)
> >to the terminal device before presenting = them. You can
> download all of the
> >interaction logic to the terminal device so = it can present
> the complete
> >user interaction with minimal external = intervention. You can
> aggregate or
> >store all of the user input in the terminal = (keyed, spoken, tapped,
> >winked, etc.) assuming the device can = detect and understand
> the input, and
> >transmit the result of the complex user = interaction at the very end.
> >
> >In this scenario, you certainly don't need = a keystroke protocol to
> >propogate the result of the complex user = interactions. A
> XML-structured
> >message carrying the result of a complex = user interaction from the
> >terminal device to the application server = in the network, is
> probably the
> >way to go.
> >
> >VoXML provides an alternate apporoach. = VoXML stores all of the user
> >prompts, interaction logic, and user input = on the "Voice Browser".
> >Actually, the interaction logic can be said = to reside at the
> VoXML page's
> >URL, but in any case it isn't in the = terminal device. The
> terminal device
> >can be very "dumb". This model is = suitable when you don't
> want to put lots
> >of smarts, storage, or fancy UI equipment = on the terminal
> device, and that
> >isn't just on PSTN phones! Don't forget, in = this model,
> VoXML relies on a
> >standardized keystroke protocol (DTMF) to = communicate the
> user input to
> >the VoXML server.
> >
> >So we have at least two models - everything = on the device,
> and everything
> >in the network. The first approach makes = for simpler network
> devices. The
> >latter approach has the advantage of = simpler terminal
> devices. But simpler
> >terminal devices REQUIRES a standard input = event (or
> keystroke) model.
>
> You can ask around, but I think the trend is = for more stuff
> on the end
> systems.  If you really want dumb and = simple, you can make a
> SIP device
> with just a DTMF keypad, or you can implement a = stimulus
> response protocol
> like MGCP or Cisco's "Skinny", but = that is not within the SIP
> WG charter.
>
> >However, the general architecture should = support both of
> these models. If
> >you decide that you want to build a  = SIP device that is
> really dumb, and
> >it won't support XML or WAP pages, and it = won't support
> voice reco, and it
> >won't support a display, you should still = be able to do it.
> VoXML points
> >the way.
> >
> >Remember, not all  terminal devices = will have the capability to store
> >
> >a sequence of keystrokes,
>
> that's absurd.  what terminal device that = can speak SIP can't store a
> sequence of keystrokes?  SIP requires = enough storage to keep
> TCBs and store
> packets for possible retransmission.  They = have to have at
> least SOME memory.
>
> >let alone do voice reco, locally. These = dumb terminal
> devices may be a
> >PSTN device, but they may not. You should = be able to build a
> SIP device
> >that essentially has no UI except a few = keys and a display
> or speaker,
> >with no storage requirements other
> >
> >than the display matrix.
> >
> >In any case, VoXML REQUIRES that the dumb = device have a keystroke
> >reporting mechanism, if it doesn't have an = audio input
> mechanism for voice
> >reco, or particularly if can't even = aggregate keystrokes
> locally. So,
> >there is already the requirement for a = keystroke standard. VoXML
> >originally was focused on calls from a PSTN = phone to a Voice
> Browser, but
> >the calling device could easily be a simple = SIP device.
> >
> >The VoXML device may have 5 keys, or 10 = keys, or 200 keys, but the
> >"dumb-terminal, = smart-network-server" model needs a way to get the
> >keypresses, (or stylus-taps, or eye-winks) = to the "smart"
> application
> >server (or VoXML server, or Telephony = Platform, or whatever)
> over the
> >network in a standard way.
> >
> >Remember, some terminal devices will not = have the capability to store
> >
> >a sequence of keystrokes, let alone do = voice reco, locally.
> >
> >I like this model.  I'm much less = interested in "keystrokes"
>  than generic
> >input (VoXML-type model works here),
> >
> >I'm not sure what you mean by "generic = input". If you mean:
> Pressing the
> >"5" key OR, saying the word = "five" OR, scribing the symbol
> "5" on the
> >screen with the stylus will result in a = "5-key pressed"
> message from the
> >terminal. If this is what you mean by = "generic input", then
> I agree with you.
>
> please look carefully at html forms.  for = example:
>
>          = <select name=3D"menu-choice">
>          = ;        = <option>balance</option>
>          = ;        = <option>operator</option>
>          = </select>
>          = <input type=3D"text" = value=3D"account">
>          = <input type=3D"submit">
>
> the select tag presents a list of = options.  it returns that
> menu-choice=3D"balance", not that the = menu choice was "5".
>
> the first input tag collects a complete = string.  not "5", but
> "546325245"
> and will eventually POST that information = back.
>
>
> >and I think most SIP UAs will want the = ability to talk to
> the PSTN  some
> >of the time (AVT tones model will be needed = here).
> >
> >A SIP UA should never need to know whether = it is sending
> keystrokes to a
> >PSTN device or another SIP device. The = protocol to achieve
> both should be
> >identical. For one thing, it probably won't = be easy to
> figure out whether
> >the device you are estasblishing a SIP = session with is in
> the PSTN or the
> >packet network. You definitely should NOT = be REQUIRED to find out.
> >
> >If, in the course of an application. I want = to send the key
> indication "5"
> >to the other device, I do not want to have = to figure out
> whether to send
> >the info as RFC 2833 or RFC 2739. There = should only be one way.
>
> Don't worry, you won't find anyone at the SIP = bakeoff who
> will try to send
> the "5" character to a terminal using = RFC 2739.
>
> >If we need to get DTMF input to a party = that isn't otherwise
> involved in
> >media, we can either tunnel AVT tones = inside of SIP, or
> >
> >"conference" in the third party = for AVT tones only.
> >
> >No, just send standard keystrokes in a = standard protocol
> that all devices
> >(or their proxies) understand.
>
> You assume that everyone else shares your love = of keystrokes.
>
> >Henning said: See also the WAP menu model. = (This is probably
> separable
> >from the rest of the WAP stuff.) Also, = you're well on your
> way to just
> >downloading Java or Javascript. I don't = think that voice and menu
> >interaction are all that similar except in = the most trivial
> cases. For
> >example, you typically present many menu = fields visually at
> the same time,
> >but (naturally) only one at a time with = voice.
> >http://lists.bell-labs.com/pipermail/sip/2000q3/002614= .html
> >
> >Again, this model assumes that you want to = store the
> interaction logic on
> >the terminal device. The interaction logic = is may be simply
> >
> >keystroke aggregation, or full blown = Javascript and voice
> reco, but you do
> >not want to force this model as the only = way to do user interactions.
>
> why not.  it is probably nearly as light = at this point to
> implementing
> keystrokes on top of RTP.
>
> thanks,
> -rohan
>
>
>
> >You may not want to put a WAP browser or = voice reco on the terminal
> >device. A particular application provider = may be prefectly
> happy with a
> >simple 5 or 10-key terminal device with no = display. The
> standard keystroke
> >model solves these issues simply and = powerfully.
> >
> >Skip Cave Sr. Principal Engineer = InterVoice-Brite Inc.
> >
> >
> >
> >
> >
> >
> >
> >  Rohan Mahy <rohan@cisco.com 09/06 = 12:31 PM  Skip,
> >
> >What is your definition of a key or = keystroke?
> >
> >I think you are missing a critical point = here.  T.140 is
> designed for text
> >chat, where the characters are simply = renderred, rather than
> >interpreted.  I don't think this is = what you want.  AVT
> tones is designed
> >for carrying input that has traditionally = been associated with the
> >telephony world.  If a SIP UA has a = keypad that looks like a
> DTMF keypad,
> >then _most of the time_ it should act like = a DTMF keypad,
> and send the
> >corresponding AVT encoding.
> >
> >If you are interested in getting generic = input, I would use something
> >
> >completely different that has nothing to do = with RTP.  For
> example, if I
> >write some characters on my Palm, is that a = keystroke?  If I
> tap a region
> >on a touchscreen, or select a region with a = mouse, is that a
> >keystroke?  What about speach rec of = canned vocabularies (Yes, No,
> >numbers..) Do we care?
> >
> >I think what we are really after is a way = to send the kind
> of "menus" and
> >"forms" that we are now used to = in traditional IVRs, down to the end
> >device (a SIP UA), where it can render the = request as
> speech, text, buttons,
> >
> >whatever;  the *method* of input is = irrelevant.  It is the
> selection of a
> >particular menu choice, or the completion = of a specific bit
> of information
> >(account number) that your service logic = cares about, so let the
> >end-system render the damn thing.
> >
> >An example of such a system is a = "distributed IVR" that uses
> VoXML on each UA.
> >
> >If I want the help-desk...
> >
> >INVITE sip:help-desk@company.com SIP/2.0 = To: <sip:help-desk From:
> ><sip:rohan@cisco.com ...
> >
> >301 Moved Contact:
> ><http://support.company.com/scripts/help-desk-ivr-scrip= t.voxml
> >
> >I get a reference to the script, then start = running it.  At
> the end of
> >some of the menus are SIP URLs.
> >
> = >sip:card-replacement-line@company.com?Priority=3Durgent&Subject<= /FONT>
> =3Daccount714352
> >
> >
> >I like this model.  I'm much less = interested in "keystrokes"
>  than generic
> >input (VoXML-type model works here), and I = think most SIP
> UAs will want
> >the ability to talk to the PSTN some of the = time (AVT tones
> model will be
> >
> >needed here).  If we need to get DTMF = input to a party that isn't
> >otherwise involved in media, we can either = tunnel AVT tones
> inside of SIP,
> >or "conference" in the thrid = party for AVT tones only.
> >
> >thanks, -rohan
> >
> >
> >At 08:30 PM 9/5/00 , Skip Cave wrote: My = last post on this
> subject did not
> >get any discussion. This usually means that = everyone agrees,
> or no one
> >understood it. Since what I was preposing = was fairly
> radical, I assume the
> >no-response was because of my poor = description   of the issue, and
> >resulting incomprehension. I will try = again, and this time I
> won't mix
> >together so many issues in one post.  = Henning and Jonathan
> have shown
> >generally  how RTP can be used as a = mechanism to carry
> keystrokes. They
> >have shown how the delivery can be made = reliable. This
> clears several
> >significant hurdles in the path towards = using RTP as a
> practical keystroke
> >transport method. There are only a few = remaining issues. The
> following
> >discussion addresses the next critical = issue.  Colin Perkins
> writes:   I
> >suggest you read RFC 2793 which describes = how to use   RFC
> 2198 redundancy
> >as a `reliable' transport for non-audio =
> >keystrokes. 
> http://lists.bell-labs.com/pipermail/sip/2000q3/002113= .html
> >RFC 2793 - "RTP Payload for Text = Conversation" is an RFC which I
> >had  somehow overlooked (thank you, = Colin) which proposes a
> method to use
> >RTP to transport T.140 "text = conversation" sessions.  So,
> the IETF now has
> >two different protocols to transmit exactly = the same data -
> keystrokes -
> >over RTP:  RFC 2833, and RFC 2793. The = primary difference
> between the two
> >protocols is simply the encoding of the = keystrokes.  RFC
> 2833 uses the
> >following encoding for keys:  = Event  encoding (decimal)
> >_________________________ = 0--9           &n= bsp;    0--9
> = >*           &= nbsp;         10 = #            = ;         11
> = >A--D          &nbs= p;   12--15  RFC 2833 doesn't define encodings
> for any other
> >keys. It seems to assume that all devices = will only have a
> maximum of 16
> >keys.  RFC 2793 proposes ISO/IEC = 10646-1, level 3 (Unicode)
> encoding to
> >define a much larger set of keys, but the = 16 keys defined in
> RFC 2833 are
> >also included in the RFC 2973 = encoding:  0x0030         = DIGIT ZERO
> = >0x0031         DIGIT ONE = 0x0032         DIGIT TWO = 0x0033    
>     DIGIT
> >THREE = 0x0034         DIGIT FOUR = 0x0035         DIGIT FIVE =
> = >0x0036         DIGIT SIX = 0x0037         DIGIT SEVEN = 0x0038  
>       DIGIT =
> >EIGHT = 0x0039         DIGIT NINE = ....... 0x0041         LATIN = CAPITAL
> >LETTER A = 0x0042         LATIN CAPITAL = LETTER B 0x0043         LATIN =
> >CAPITAL LETTER C = 0x0044         LATIN CAPITAL = LETTER D .........
> = >0x002A         ASTERISK = 0x0023         NUMBER SIGN = ....... 
> As you can
> >see, the two protocols have two vastly = different ways to
> encode exactly
> >the same thing - numeric & alphabetic = keys on a terminal
> device.  Some
> >other issues with the two protocols:  = RFC 2833 allows the
> transmission of
> >keystrokes from a terminal over RTP. = However, RFC 2833 also
> defines a
> >large set of other events besides = keystrokes that can be
> carried in the
> >same RTP stream = format:      o  DTMF tones (Section =
> >3.10);      = o  fax-related tones (Section 3.11);      = o  standard
> >subscriber line tones (Section = 3.12);      o 
> country-specific subscriber
> >line tones (Section 3.13) = and;      o  trunk events (Section =
> 3.14).  While
> >this multiple-event-type property may be = useful in some PSTN
> transport
> >applications, it is definitely not = appropriate as a general
> keystroke
> >communications mechanism. Many applications = will not want
> anything but
> >keystrokes to come over the RTP session - = no audio, no fax
> tones.  RFC
> >2793 also allows the transmission of = keystrokes from a
> terminal  over RTP.
> >This RFC uses ISO/IEC 10646-1, level 3 to = define a much
> larger set of
> >possible keys, but the keys on a 12-button = terminal device are all
> >included in the larger set. This RFC does = not include any
> other event
> >types except keystrokes, but RFC 2793 does = not include a
> method to carry
> >keystroke duration as a function of the = protocol.  So to
> summarize: RFC
> >2833 1) doesn't cover all of the possible = keys available in
> a terminal
> >device 2) carries extra stuff besides = keystrokes in the
> protocol  RFC 2793
> >1) Doesn't carry keystroke duration = information.  Meanwhile, both
> >protocols use the same redundancy mechanism = (RFC 2198) for
> more reliable
> >delivery of keystrokes.  My issue: As = a general rule, a device
> >establishing a SIP session with another = device should not
> have to discover
> >what type of device it is sessioning with = before knowing
> whether to send
> >keystrokes using RFC 2833 or RFC 2793 over = the RTP session.
> There should
> >be only one protocol and one encoding for = keystrokes in SIP and RTP,
> >regardless of the device that has the keys = on it.  My
> solution: Combine
> >the best of RFC 2833 and RFC 2793 for a = universal keystroke
> protocol. 1)
> >Use RFC 2793's encoding scheme for all keys = along with T.140
> protocol
> >stucture 2) Use RFC 2833's duration scheme = for keystroke
> durations 3) Use
> >RFC 2198 for reliability 4) Remove the DTMF = keystroke events
> from from
> >Section 3 of RFC 2833 and keep that = protocol format specifically for
> >telephony events (fax tones, subscriber = line tones, etc.).
> 5) Add a new
> >payload format in RFC 2833 that is = specifically for
> keystrokes using the
> >2833-2973 hybrid protocol.  In this = way, you could INVITE only the
> >2833-2973 hybrid protocol if you wanted = just keystrokes, or
> you could
> >INVITE the RTP audio also, or just the = telephony events, or any
> >combination using SDP media control = mechanisms (m=3D3D)  In my
> company's
> >applications we plan to establish  SIP = sessions with
> PSTN/SIP Gateways,
> >Softswitches, SIP phones, SIP mobile = devices, and SIP PCs.
> The key input
> >from all of these different sources should = use the same
> protocol. The key
> >input that we send to all of these devices = should use the
> same protocol.
> >We don't want to have to use different = protocols to send
> keystrokes to a
> >SIP gateway, a SIP wireless device, a = Softswitch, or a PC.
> We don't want
> >to have to know ahead of time what type of = device we are calling to
> >determine what kind of session to INVITE to = get keystrokes.
> The keystroke
> >protocol for all devices that have keys = should be the same.  If PSTN
> >transport application developers vendors = want to stick fax
> tones and call
> >progress in with the compressed audio in a =
> gateway-to-gateway RTP session,
> >that's fine. Just don't make everybody have = to support those
> events when
> >all you want are keystrokes.  Skip = Cave
> >
> >
> >
> >
> >
> >
> = >_______________________________________________
> >SIP mailing list
> >SIP@lists.bell-labs.com
> >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_01C018E1.C196FD20-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Sep 7 12:14: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 ESMTP id MAA19811 for ; Thu, 7 Sep 2000 12:14: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 8470F443D6; Thu, 7 Sep 2000 11:13:27 -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 5817A4435F for ; Thu, 7 Sep 2000 11:13:24 -0400 (EDT) Received: from tate ([216.181.56.35]) by broadsoft.com (8.8.8) id MAA21826; Thu, 7 Sep 2000 12:13:15 -0400 (EDT) Message-ID: <034b01c018e7$28bf94d0$3202a8c0@broadsoft.com> From: "Brett Tate" To: Cc: References: Subject: Re: [SIP] Possible REFER problem? Date: Thu, 7 Sep 2000 12:17:45 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Using the To tag would work but opens/maintains a pin-hole in the proxies for most anyone to suddenly reach a specific user behind a proxy (or B2BUA). I'd rather see something like a "PENDING-INVITE" method be used to temporarily open the pin-hole with needed approval by the Referred-To user agent. The "PENDING-INVITE" was briefly mentioned in the "draft-ietf-sip-cc-transfer-00 comments and questions" thread. In addition to ensuring anonymity behind a proxy (or B2BUA) and the correct party being reached, it would also identify how the REFERring party was hoping the resulting INVITE would be treated in relation to the other corresponding call-leg (switch-bye, mixed, reject, hold-me, ...). ----- Original Message ----- From: To: Cc: Sent: Thursday, September 07, 2000 10:11 AM Subject: RE: [SIP] Possible REFER problem? > 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. > > Although it is not the intention of To tags that they be included in INVITEs > to new sessions, UAS's currently may allow new INVITEs with To tags as a > means of working around a crash. So why not take advantage of that to make > REFERs more robust (and maybe add a couple of SHOULDs to the RFC)?. > > > -----Original Message----- > > From: EXT Eric Tremblay [mailto:etremblay@mediatrix.com] > > Sent: Monday, September 04, 2000 8:24 PM > > To: Robert Sparks (E-mail) > > Cc: sip@lists.bell-labs.com > > Subject: [SIP] Possible REFER problem? > > > > > > Hi, > > > > I think I see a possible problem with the REFER request in > > the context of a > > call transfer with consultation: > > > > Suppose that Transferor and Transferee are connected. Transferor puts > > Transferee on hold and calls Transfer Target (TT). After the > > brief call > > between Transferor and TT, Transferor sends a REFER request > > to Transferee: > > > > Transferor has 2 choices for the URL to put into the Refer-To > > header of the > > REFER request. It can either use the contact it has received > > in the 200 > > response of the call with TT or it can use the original URL > > it has used to > > establish the call to TT (which usually points to a proxy or redirect > > server). > > > > I think that using the contact URL in the Refer-To is not the > > best thing to > > do because this could bypass some of the system policies that > > requires all > > calls to go trough a proxy (for tracing, billing or whatever > > services). > > Note that this is fixed by having TT return a 305 response to > > the INVITE > > received from Transferee, in which case Transferee should > > resend the INVITE > > to a proxy. > > > > On the other hand, when using the original URL in the > > Refer-To, I think it > > is possible that the call from Transferee to TT will be > > routed to a totaly > > different destination, probably because the proxy has forked > > and someone > > else has answered before TT could. > > > > > > I think the problem is as follows: > > > > How can we make sure that the INVITE from Transferee to TT > > will be answered > > by the same UA as the INVITE from Transferor to TT? I think > > that we want to > > allow some mobility to TT, but I also think that we would > > like to reach the > > exact same UA as the call between Transferor and TT. > > > > 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. > > > > First, is this really a problem or I'm forgetting something? > > > > 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 > > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > 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 Sep 7 12:52: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 ESMTP id MAA20799 for ; Thu, 7 Sep 2000 12:52: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 2BEC2443CF; Thu, 7 Sep 2000 11:51:59 -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 C84844435F for ; Thu, 7 Sep 2000 11:51:54 -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 JAA29323; Thu, 7 Sep 2000 09:52:12 -0700 (PDT) Received: from rmahy-home-nt (rmahy-dsl1.cisco.com [10.19.53.122]) by imop.cisco.com (Mirapoint) with ESMTP id AAC69782; Thu, 7 Sep 2000 09:51:51 -0700 (PDT) Message-Id: <4.2.0.58.20000907094712.0394a9e0@lint.cisco.com> X-Sender: rmahy@imop.cisco.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Thu, 07 Sep 2000 09:50:07 -0700 To: "Tom-PT Taylor" From: Rohan Mahy Subject: RE: [SIP] Two Keystroke Encodings Cc: Skip Cave , sip@lists.bell-labs.com In-Reply-To: <28560036253BD41191A10000F8BCBD11480D40@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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com I agree with Tom's assesment. My feeling is that stimulus signalling is fine for MGCP and Megaco, but is not appropriate in the SIP WG. thanks, -rohan At 08:39 AM 9/7/00 , Tom-PT Taylor wrote: >At least some of this debate seems to be a replay of the ancient (from >ISDN days) stimulus vs. functional protocol debate. Skip is talking about >stimulus signalling, Rohan about functional. Oldtimers can tell you the >merits of each, and also that functional may have won in the short term, >but stimulus keeps coming back. > >Tom T _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Sep 7 13:04: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 ESMTP id NAA21104 for ; Thu, 7 Sep 2000 13:04: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 7F3FA443D4; Thu, 7 Sep 2000 12:04:23 -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 AB5CB4435F for ; Thu, 7 Sep 2000 11:42:34 -0400 (EDT) Received: by exchange01.iirltd.co.uk with Internet Mail Service (5.5.2650.21) id ; Thu, 7 Sep 2000 17:42:38 +0100 Message-ID: From: Claire Tranah To: "'sip@lists.bell-labs.com'" Date: Thu, 7 Sep 2000 17:42:27 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] SIP- Speaking Opportunities Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA21104 HI All, IIR are putting togther a conference on SIP Implementations and Deployments to run alongside its sister event 'AllIP Mobile Networks'. The SIP event will take place on 6th-7th Dec in Lisbon and I am looking for speakers to present the following topics. 1/ SIP – A Carriers Perspective -Identifying and Meeting the Challenges of Building a SIP-Enabled Network 2/ SIP Services and Commercial Applications – Engineering New Revenue Streams from SIP- Enabled Telephony and Mobility 3/ Examining the Latest Development in Standards for SIP from the 3GP Partnership 4/ Building a Compelling Business Case and Examining Time-Scales for Commercial Deployment 5/ Examining theBusiness Model for the Provision of SIP-Based Telecom Services to ASPs, ISPs and ITSPs Should you be interested could you please contact me as soon as possible as opportunities are being taken quickly. Further information on the event can be found at www.iir-conferences.com/ipmobile Many 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 ********************************** _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Sep 7 16: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 QAA26745 for ; Thu, 7 Sep 2000 16:43: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 6D3BC443E4; Thu, 7 Sep 2000 15:42:25 -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 8304C443CD for ; Thu, 7 Sep 2000 15:42:21 -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 QAA03502; Thu, 7 Sep 2000 16:38:13 -0400 (EDT) Message-ID: <39B7FDAA.B5E139B3@nist.gov> Date: Thu, 07 Sep 2000 16:42:18 -0400 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=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] REGISTER Method questions. Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Hello! At the risk of asking simple questions that have been asked and answered in the past, I would be grateful if somebody could help me understand a few things about the REGISTER request. 1. The RFC states that Registrations with the same Call-ID must have increasing CSeq header values, however the server does not reject out of order requests. I am confused about the purpose of the CSeq value in that case. Is there an implication here that the headers must have montonically increasing (but not necessarily sequentially increasing ) values? 2. If a new registration for a given SIP URI supersedes an existing registration for the same URI, do the contact headers in the new request replace the existing ones? (i.e. are the old contact headers implicitly discarded or do they have to be explicitly discarded with another register request containing the contact header and a 0 expires time?) 3. What "action value" is being referred to in the statement "All current registrations must share the same action value" Thank you in advance for your replies. Ranga. -- M.Ranganathan NIST Advanced Networking Technologies Group, 100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899. Tel: 301 975 3664 Fax: 301 590 0934 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Sep 7 18:55: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 SAA28764 for ; Thu, 7 Sep 2000 18:55: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 0497E443E2; Thu, 7 Sep 2000 17:54:41 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from empowertel.com (unknown [64.220.200.243]) by lists.bell-labs.com (Postfix) with ESMTP id 9BB38443CD for ; Thu, 7 Sep 2000 17:46:19 -0400 (EDT) Received: from Rajeev ([192.168.111.39]) by empowertel.com (8.9.3+Sun/8.9.3) with SMTP id PAA15973; Thu, 7 Sep 2000 15:43:01 -0700 (PDT) Reply-To: From: "Rajeev Gupta" To: "'Hong Chen'" , "'Jonathan Rosenberg'" Cc: "'Anders Kristensen'" , Subject: RE: [SIP] SIP feature services Date: Wed, 6 Sep 2000 13:03:07 -0700 Message-ID: <000001c0191d$b42f0420$276fa8c0@empowertel.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 In-Reply-To: <39B523C1.3CD12149@cisco.com> 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit How do you indicate the occurence of a mid-call trigger (such as for call waiting) from a SIP proxy (which could be running in a softswitch) to an application server (which contains logic on how to handle the feature for this specific subscriber, and may be running on another SCP-like node)? This is a transaction-type messaging between SIP proxy and application server, which is not necessarily in the context of a SIP session setup between the two. Rajeev Gupta empowerTel Networks 475 Sycamore Drive, Milpitas, CA 95035 Phone: +1 408 519 7136 Fax: +1 408 519 7420 mailto:rajeev@empowertel.com http://www.empowertel.com -----Original Message----- From: sip-admin@lists.bell-labs.com [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Hong Chen Sent: Tuesday, September 05, 2000 9:48 AM To: Jonathan Rosenberg Cc: Anders Kristensen; sip@lists.bell-labs.com Subject: Re: [SIP] SIP feature services Jonathan Rosenberg wrote: > Hong Chen wrote: > > > > > Request URIs won't (usually) contain info that identifies services to be > > > invoked. Maybe you subscribe to feature-i at some proxy -- it is then up > > > to that proxy to figure out to apply feature-i to your calls. > > > > > > > Yes, some services can be subscribed by users and can be trigged inside SIP > > proxy. > > But the issues are: > > - Do we need to define the trig points (for both originating and > > terminating trigs) and their conditions in Proxy? > > A trigger point is simply some kind of system event that is useful for > the purposes of doing something service related. SIP as a protocol > defines various state machines and messages, any of which might serve as > a useful trigger for doing something. I see no need for any additional > standardization. I agree that additional standardization may not be necessary, but a standard call model for sip proxy may help for the feature developments and interpretability. > > > > This could be a design and implementation issue. > > - Further more, it may not be possible to define and implement trigs for > some > > feature services. > > How can we handle these services by SIP? > > I cannot answer that without some examples or a more precise definition. > EX.. of features which need network controls and hard to define trigs in sip proxy. (1) Call Park (Park a call and then pick the call later somewhere else). (2) Call Pick Up (Answer a call which is ringing somewhere else in a call pick up group). (3) Adhoc conference using centralized conference bridge. and more. Thanks, > > > - How can we use SIP to implement user based and/or call based feature > > services? > > Has that not been the discussion of this thread to date? As Anders has > pointed out, the services are encapsulated within the logic of proxies > and other SIP devices along the session establishment path. > > -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 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Sep 7 23: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 XAA04309 for ; Thu, 7 Sep 2000 23: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 E1D39443E8; Thu, 7 Sep 2000 22:38:25 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from rly-ip02.mx.aol.com (rly-ip02.mx.aol.com [152.163.225.160]) by lists.bell-labs.com (Postfix) with ESMTP id 8D7E6443B7 for ; Thu, 7 Sep 2000 22:38:22 -0400 (EDT) Received: from tot-tf.proxy.aol.com (tot-tf.proxy.aol.com [152.163.197.131]) by rly-ip02.mx.aol.com (8.8.8/8.8.8/AOL-5.0.0) with ESMTP id XAA21949 for ; Thu, 7 Sep 2000 23:37:59 -0400 (EDT) Received: from ESCORT (ACA6B492.ipt.aol.com [172.166.180.146]) by tot-tf.proxy.aol.com (8.10.0/8.10.0) with SMTP id e883bvH10671 for ; Thu, 7 Sep 2000 23:37:57 -0400 (EDT) From: "Steve Donovan" To: Subject: RE: [SIP] transaction identification Date: Thu, 7 Sep 2000 22:38:11 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit I'll admit that I have not been able to track this discussion in its entirety and I applaud those that have been both able to keep up and to understand the intricacies involved. I also apologize as I am sure that I am asking for a repeat of what has already been discussed. However, I am very concerned that we are jumping through hoops and inventing things that are making implementation of proxies more complicated then they need to be. Back in a previous life, I thought I understood the solution to spirals (I think I called them legal proxy loops back then). The solution was for the proxy to use the request-uri as part of its identification of a request transaction and to add a branch tag to the via. The branch tag (which to the protocol could be an opaque blob) helped the proxy map responses to the appropriate call leg. Using the request-uri was used to map future requests (for call stateful proxies) to the original call leg. I recall at the Ericsson bake-off, I believe, that a number of us discovered that the wording had been added on building the route header that the original uri in the record-route header was not to be used. I did not understand then, and still do not understand why that is necessary. If that rule is removed, then it seems to me that all of this discussion goes away and the implementation of a proxy server becomes much more straight forward. So, can someone please explain again why that wording is required. In addition, please point out what I am missing in my assertion that all of these seemingly hundreds of messages on this topic would go away if this change is removed from the bis draft. As an alternative, if this is not removed from the bis draft, I would suggest that we owe it to future developers of SIP proxies to write up an informational rfc on how to handle loop detection and spirals. There is too much knowledge buried in the mailing list right now for anyone to be expected to be successful in the implementation (without asking the same questions all over again). OK, go ahead and throw things at me, but remember, my motives are pure. The protocol needs to be easy to implement. And given that this was added to the bis draft to fix 2543, removing it or changing it should not suffer a backwards compatibility test. Steve > -----Original Message----- > From: sip-admin@lists.bell-labs.com > [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Sharath Rajasekar > Sent: Wednesday, September 06, 2000 7:11 PM > To: sip@lists.bell-labs.com > Subject: Re: [SIP] transaction identification > > > > > Implementing loop detection in *stateless proxies*, is it essential to > compute the first part of branch id as a hash of To, From, CallID, Cseq in > addition to RequestURI and topmost Via. > > Is it not sufficient to simply use the request URI and topmost > Via alone for > the hash computation since the other values are not going to > change anyway ? > I am not sure I understand why these fields are being used for the hash > computation even in the case of stateless proxies. > > The second part of the branch could be computed as the hash of outgoing > request uri + some server instance ? > > --Sharath R. > > Sharath Rajasekar > Sylantro Systems Inc. > http://www.sylantro.com > > > > > > > > > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Monday, September 04, 2000 8:41 PM > To: Henning Schulzrinne > Cc: Neil Deason; sip@lists.bell-labs.com > Subject: Re: [SIP] transaction identification > > > > > Henning Schulzrinne wrote: > > > > Neil Deason wrote: > > > > > > > > > > > This possible fix was not introduced just for Via hiding. > > > The original discussion was about request retransmissions > > > on reverse spirals when record routing is in operation. > > > > > > A -INV-> P1 -INV-> P2 -INV-> P1 -INV-> B > > > > > > A is originating UA, B is receiving UA, P1 & P2 are proxies > > > that Record-Route. B now sends a BYE. When the P2-P1 "portion" > > > of the BYE reaches P1, how will it distinguish that request > > > from the initial B-P1 as the spec stands? So the idea was to > > > change the definition of isomorphic requests to include a > > > globally unique branch param. > > > > Added to the spec. The definition of the second branch parameter was > > always pretty vague, including "a sequence number", which presumably > > would do as long as the count is across all transactions. > > Just to be clear here; the discussion to date of having a third > component that is globally unique is going to be folded into the second > component. That component was used for the actual "branch" > identification - if a proxy forks, and the response comes, for which > forked request is the response? So, a globally unique ID will be used > here instead of a simple sequence number that resets for each > transaction. > > -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 > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > 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 Sep 8 01: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 BAA10828 for ; Fri, 8 Sep 2000 01: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 37EBA443F4; Fri, 8 Sep 2000 00:53:32 -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 21E7C443B7 for ; Fri, 8 Sep 2000 00:53:28 -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 e885rKw13374; Fri, 8 Sep 2000 07:53:20 +0200 (MEST) Received: from ericsson.fi (E0080C7FA22D6.lmf.ericsson.se [131.160.30.48]) by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id IAA29931; Fri, 8 Sep 2000 08:53:18 +0300 (EET DST) Message-ID: <39B87E6C.DA5B20A1@ericsson.fi> Date: Fri, 08 Sep 2000 08:51:40 +0300 From: Hisham Khartabil X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: mranga@nist.gov Cc: sip@lists.bell-labs.com Subject: Re: [SIP] REGISTER Method questions. References: <39B7FDAA.B5E139B3@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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit "m. ranganathan" wrote: > Hello! > > At the risk of asking simple questions that have been asked and answered > in the past, I would be grateful if somebody could help me understand a > few things about the REGISTER request. > > 1. The RFC states that Registrations with the same Call-ID must have > increasing CSeq header values, however the server does not reject out of > order requests. I am confused about the purpose of the CSeq value in > that case. Is there an implication here that the headers must have > montonically increasing (but not necessarily sequentially increasing ) > values? This is for the scenario where an older request arrives at the server later than a newer one. > > > 2. If a new registration for a given SIP URI supersedes an existing > registration for the same URI, do the contact headers in the new > request replace the existing ones? (i.e. are the old contact headers > implicitly discarded or do they have to be explicitly discarded with > another register request containing the contact header and a 0 expires > time?) no, you don't discard the older ones, you just add the new ones to the list. Contacts are removed when they expire according to the Expires header upon registration or with a REGISTER request with expires 0. > > > 3. What "action value" is being referred to in the statement "All > current registrations must share the same action value" Action indicates whether the client wishes that the server proxy or redirect future requests intended for the client. So, you can't have one contact with action=proxy and another with action=redirect. Regards, Hisham > > > Thank you in advance for your replies. > > Ranga. > > -- > M.Ranganathan > NIST Advanced Networking Technologies Group, > 100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899. > Tel: 301 975 3664 Fax: 301 590 0934 > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > 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 Sep 8 02:24: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 CAA17908 for ; Fri, 8 Sep 2000 02:24: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 76D83443F7; Fri, 8 Sep 2000 01:23:53 -0400 (EDT) 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 6C40944397 for ; Fri, 8 Sep 2000 01:23:49 -0400 (EDT) Received: by EXCHANGESVR with Internet Mail Service (5.5.2650.21) id ; Thu, 7 Sep 2000 23:23:43 -0700 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'David Yon'" , sip@lists.bell-labs.com Subject: RE: [SIP] SIP, SDP, and TCP-based media transport Date: Thu, 7 Sep 2000 23:23:33 -0700 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Hi David, > The direction parameter goes on the a= line, not the m= line. > The "fmt" > identifier is a qualification of the protocol above TCP. For > want of a > better example, "t38" would be a valid entry in that position > on the m= line. Oh sorry, my mistake. > I've finally had some time to work through some of the > scenarios, and I > think the solution is to abandon the "highest port wins" > heuristic and > replace it with the following: .... > > I think that gets rid of the race condition, works through an > ALG where > port numbers might change, yet still allows one of the > connections to be > shut down when circumstances permit. Worst case is each > connection becomes > unidirectional. > > Comments? Anyone see a hole I missed? > Sounds good - I can't see any problems. So I guess this also means that once you have received data on a TCP connection you may not close it. > >someone made to point that the stated algorithm doesn't work > is both sides > >are behind ALGs. Can anyone confirm? > > I'm having trouble parsing this sentence to begin with, never mind > recalling the original issue. :-) Could you rephrase? Hahaha, my stimulus based keystroke protocol must have been having some problems. :) I was saying that someone pointed out a problem in the "highest port wins" algorithm when both endpoints are behind an ALG. > I agree with most, but not all of this. Certainly if you > "want to be able > to traverse a NAT/NAPT", then you likely would only need a single TCP > connection but are forced to attempt two in order to > determine who has the > unimpeded path. Yup, that's fine now that we've got a workable tcp connection closing algorithm. Well that's about it then (other comments pending) - we've finally got a draft TCP profile for SDP. Cheers, Robert. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Sep 8 06:26: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 GAA19686 for ; Fri, 8 Sep 2000 06:26: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 EFC6D443C6; Fri, 8 Sep 2000 05:25:55 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id 06C8C44371 for ; Fri, 8 Sep 2000 05:25:51 -0400 (EDT) Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id LAA08638; Fri, 8 Sep 2000 11:23:53 +0100 (BST) Message-ID: <39B8BE39.F5566209@ubiquity.net> Date: Fri, 08 Sep 2000 11:23:53 +0100 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: Steve Donovan Cc: sip@lists.bell-labs.com Subject: Re: [SIP] transaction identification 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Good comments Steve, so nothing to throw here ;) I think a summary would be useful to make sure we haven't ended up chasing our own shadows. There was a lot mixed into the many postings over 3 threads but I take some encouragement if we we are getting down to the harder to find bugs. I can appreciate that it is not easy to follow for anyone not, or possibly just not yet, having to deal with this in an actual implementation. Hopefully it is true that implementing the solution is a lot simpler than describing the problem. So grab a coffee and I'll begin ... Proposed Change: Include the topmost Via branch param in the definition of isomorphic requests and make the Via branch param globally unique. [Note the addition of the topmost Via itself to the definition of isomorphic requests was not a direct result of this latest discussion but needed to be brought in to fix request merging. Also whether all of the Via branch param or the Xth part needs to be unique is really an implementation decision. Being more precise will help new implementers but should be no more than a MAY.] The Problem: Consider the following case where there is a legal loop and both proxies add themselves to the Record-Route. R-R R-R A -INV-> P1 -INV-> P2 -INV-> B B now sends a BYE: A <-BYE- P1 <-BYE- P2 <-BYE- B According to the way Route is constructed for a reverse request path, using the originating name-addr (Section 6.34.2), the Request-URI ends up the same across transmissions and so this is incorrectly failed as an illegal loop. As you say this wouldn't be a problem if original uri in the record-route header was used instead. But Jonathan pointed out that using the originating name-addr... " maintains the fundamental principle that the request URI indicates for whom the request is destined. By relying on Route headers to get the request there, even though the request URI says something completely difference, makes the operation of the protocol brittle. We have seen this at bakeoffs - loops often occur if any proxy has anything slightly wrong with their route processing." [I would point out that you hope this is the case, because the port could be incorrect for the intended recipient if sending UA copies a different port from the Record-Route into the Request URI in accordance with 6.34.2] So the simplest proposed solution appeared to be that a Proxy doesn't need to do loop detection if it's following a Route. However there is a slight problem. Consider the following more complex scenario... R-R R-R R-R R-R R-R A -INV-> P1 -INV-> P2 -INV-> P1 -INV-> P2 -INV-> B A is originating UA, B is receiving UA, P1 & P2 are proxies that Record-Route. The loops in the above scenario are both 'legal' loops, i.e. Request-URI gets rewritten between proxies. B now sends a BYE. A <-BYE- P1 <-BYE- P2 <-BYE- P1 <-BYE- P2 <-BYE- B (b) (a) How can P1 distinguish the BYE marked (a) from the one marked (b) as non isomorphic requests? Again according to the way Route is constructed for a reverse request path, using the originating name-addr (Section 6.34.2), the Request-URI ends up the same across transmissions. We are now not doing loop detection but we still need to be able to distinguish a new request from a retransmission. At this time the definition of isomorphic requests included same values for the Call-ID, To, From, CSeq Request-URI and topmost Via. So the proposal to fix this was to add a globally unique identifier to the Via branch param. Doing this has some other apparent benefits. It helps with general protocol robustness a proxy which detects a loop down the chain from where it actually happened, can use it to differentiate ACKs/CANCELs for the 1st/2nd time it saw the request. It also helped Proxies do loop detection with Via hiding more efficiently. However, there now appears to be a consensus to remove Via hiding completely. 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 Sep 8 11: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 LAA24214 for ; Fri, 8 Sep 2000 11: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 87294443E6; Fri, 8 Sep 2000 10:10: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 1833444371 for ; Fri, 8 Sep 2000 10:09:59 -0400 (EDT) Received: from driftwood.cisco.com (driftwood.cisco.com [171.71.157.40]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id IAA29122; Fri, 8 Sep 2000 08:10:11 -0700 (PDT) Received: from cisco.com ([171.71.159.231]) by driftwood.cisco.com (Mirapoint) with ESMTP id ACF20034; Fri, 8 Sep 2000 10:06:40 -0500 (CDT) Message-ID: <39B90180.E09A36A@cisco.com> Date: Fri, 08 Sep 2000 10:10:56 -0500 From: Hong Chen Organization: Cisco Systems X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: rajeev@empowertel.com Cc: "'Jonathan Rosenberg'" , "'Anders Kristensen'" , sip@lists.bell-labs.com Subject: Re: [SIP] SIP feature services References: <000001c0191d$b42f0420$276fa8c0@empowertel.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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Rajeev Gupta wrote: > How do you indicate the occurence of a mid-call trigger (such as for call > waiting) from a SIP proxy (which could be running in a softswitch) to an > application server (which contains logic on how to handle the feature for > this specific subscriber, and may be running on another SCP-like node)? This > is a transaction-type messaging between SIP proxy and application server, > which is not necessarily in the context of a SIP session setup between the > two. > I think the type of services above can be served in SIP proxy / AS by well defined triggers. The feature services I would like to discuss here are those services that need network side control and it is very hard to define triggers in SIP proxy for them. Thanks, Henry > > Rajeev Gupta > empowerTel Networks > 475 Sycamore Drive, Milpitas, CA 95035 > Phone: +1 408 519 7136 > Fax: +1 408 519 7420 > mailto:rajeev@empowertel.com > http://www.empowertel.com > > -----Original Message----- > From: sip-admin@lists.bell-labs.com > [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Hong Chen > Sent: Tuesday, September 05, 2000 9:48 AM > To: Jonathan Rosenberg > Cc: Anders Kristensen; sip@lists.bell-labs.com > Subject: Re: [SIP] SIP feature services > > Jonathan Rosenberg wrote: > > > Hong Chen wrote: > > > > > > > Request URIs won't (usually) contain info that identifies services to > be > > > > invoked. Maybe you subscribe to feature-i at some proxy -- it is then > up > > > > to that proxy to figure out to apply feature-i to your calls. > > > > > > > > > > Yes, some services can be subscribed by users and can be trigged inside > SIP > > > proxy. > > > But the issues are: > > > - Do we need to define the trig points (for both originating and > > > terminating trigs) and their conditions in Proxy? > > > > A trigger point is simply some kind of system event that is useful for > > the purposes of doing something service related. SIP as a protocol > > defines various state machines and messages, any of which might serve as > > a useful trigger for doing something. I see no need for any additional > > standardization. > > I agree that additional standardization may not be necessary, but a > standard call > model > for sip proxy may help for the feature developments and interpretability. > > > > > > > > This could be a design and implementation issue. > > > - Further more, it may not be possible to define and implement trigs > for > > some > > > feature services. > > > How can we handle these services by SIP? > > > > I cannot answer that without some examples or a more precise definition. > > > > EX.. of features which need network controls and hard to define trigs in sip > proxy. > (1) Call Park (Park a call and then pick the call later somewhere else). > (2) Call Pick Up (Answer a call which is ringing somewhere else in a call > pick up > group). > (3) Adhoc conference using centralized conference bridge. > and more. > > Thanks, > > > > > > - How can we use SIP to implement user based and/or call based > feature > > > services? > > > > Has that not been the discussion of this thread to date? As Anders has > > pointed out, the services are encapsulated within the logic of proxies > > and other SIP devices along the session establishment path. > > > > -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 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Sep 8 11:18: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 LAA24327 for ; Fri, 8 Sep 2000 11:18: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 C9C2C443F5; Fri, 8 Sep 2000 10:17:51 -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 19F75443B7 for ; Fri, 8 Sep 2000 10:17:48 -0400 (EDT) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate2.mot.com (motgate2 2.1) with ESMTP id IAA25864 for ; Fri, 8 Sep 2000 08:17:45 -0700 (MST)] Received: [from hpux4.miel.mot.com (hpux4.miel.mot.com [217.1.84.89]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id IAA25524 for ; Fri, 8 Sep 2000 08:17:43 -0700 (MST)] Received: from pc127162 (pc127162.miel.mot.com [217.1.127.162]) by miel.mot.com (8.9.3/8.9.3) with SMTP id UAA28623 for ; Fri, 8 Sep 2000 20:52:44 +0530 (IST) Reply-To: From: "Albee Vimal" To: Date: Fri, 8 Sep 2000 20:50:49 +0530 Message-ID: <012601c019a8$5fab0ee0$a27f01d9@pc127162.miel.mot.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Importance: Normal Subject: [SIP] Stateless Proxy Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Hi I have simple question on the following scenarios : When a stateless proxy receives a request, it does a registrar search for the RequestURI received. If the registrar search results in multiple entries being returned without any action specified(or with action = proxy). Should proxy drop this request, since it does not support redirection. Thanks Vimal _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Sep 8 11: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 LAA24360 for ; Fri, 8 Sep 2000 11: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 C41C4443FE; Fri, 8 Sep 2000 10:17:56 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from nautilus.shore.net (nautilus.shore.net [207.244.124.104]) by lists.bell-labs.com (Postfix) with ESMTP id 14373443F4 for ; Fri, 8 Sep 2000 10:17:49 -0400 (EDT) Received: from (hither.rfdsoftware.com) [209.192.222.62] by nautilus.shore.net with esmtp (Exim) id 13XPtk-0002k9-00; Fri, 08 Sep 2000 11:17:00 -0400 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 LAA28884; Fri, 8 Sep 2000 11:09:58 -0400 (EDT) Message-Id: <4.3.2.7.2.20000908111316.00eb9900@webhost.tactical-sw.com> X-Sender: dnyon@webhost.tactical-sw.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 08 Sep 2000 11:15:55 -0400 To: "Fairlie-Cuninghame, Robert" , sip@lists.bell-labs.com From: David Yon Subject: RE: [SIP] SIP, SDP, and TCP-based media transport 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com At 11:23 PM 9/7/00 -0700, Fairlie-Cuninghame, Robert wrote: > > > > I think that gets rid of the race condition, works through an > > ALG where > > port numbers might change, yet still allows one of the > > connections to be > > shut down when circumstances permit. Worst case is each > > connection becomes > > unidirectional. > > > > Comments? Anyone see a hole I missed? > > >Sounds good - I can't see any problems. So I guess this also means that once >you have received data on a TCP connection you may not close it. Correct. Ditto if you've sent data on a TCP connection. Once you've sent *and* received data, and they happen to occur both on the same TCP connection, it's safe to close the other one. > >Well that's about it then (other comments pending) - we've finally got a >draft TCP profile for SDP. Ok, I've updated the online copy to reflect the most recent discussion, any and all comments welcome: ftp://ftp.dialout.net/drafts/draft-ietf-sip-sdp-tcpmedia-00.txt So, if there are no additional comments, how do I go about getting this into the queue? Jonathan...? Henning...? Comment? 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 Fri Sep 8 11:40: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 LAA24672 for ; Fri, 8 Sep 2000 11:40: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 9853C44402; Fri, 8 Sep 2000 10:40:25 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id 6DA3B44371 for ; Fri, 8 Sep 2000 10:40:12 -0400 (EDT) Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id QAA17521; Fri, 8 Sep 2000 16:38:03 +0100 (BST) Message-ID: <39B907DB.704AB346@ubiquity.net> Date: Fri, 08 Sep 2000 16:38:03 +0100 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: albee@miel.mot.com Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Stateless Proxy References: <012601c019a8$5fab0ee0$a27f01d9@pc127162.miel.mot.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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit You would not expect to find a Stateless Proxy operating like this. In stateless mode a Proxy is really just a next hop router of SIP messages, where the next hop is most likely to be a stateful Proxy, possibly co-located with a Registrar, or a Redirect Server. Proxies operating in stateless mode can be thought of as existing in the core of the network and being concerned with issues of performance, reliability and scalability. Whilst Proxies operating in a stateful mode exist closer to the edge of the network nearer the users that they probably perform additional services for (SIP-CGI, Servlets, CPL, Presence, etc.). Cheers, Neil -- Ubiquity Software Corporation, UK http://www.ubiquity.net Albee Vimal wrote: > > Hi > I have simple question on the following scenarios : > > When a stateless proxy receives a request, it does a registrar search for > the RequestURI received. If the registrar search results in multiple entries > being returned without any action specified(or with action = proxy). Should > proxy drop this request, since it does not support redirection. > > Thanks > Vimal > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > 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 Sep 8 11:48: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 LAA24779 for ; Fri, 8 Sep 2000 11:48: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 DBA4244404; Fri, 8 Sep 2000 10:48:13 -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 79BC2443F4 for ; Fri, 8 Sep 2000 10:48:10 -0400 (EDT) Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-33 #42261) id <0G0K00C01RUPK2@firewall.mcit.com> for sip@lists.bell-labs.com; Fri, 8 Sep 2000 15:47:13 +0000 (GMT) Received: from dgismtp02.wcomnet.com ([166.38.58.142]) by firewall.mcit.com (PMDF V5.2-33 #42261) with ESMTP id <0G0K00C2IRUPDK@firewall.mcit.com>; Fri, 08 Sep 2000 15:47:13 +0000 (GMT) Received: from CONVERSION-DAEMON by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) id <0G0K00J01RUPM2@dgismtp02.wcomnet.com>; Fri, 08 Sep 2000 15:47:13 +0000 (GMT) Received: from dgismtp02.wcomnet.com by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) with SMTP id <0G0K00J01RUNLL@dgismtp02.wcomnet.com>; Fri, 08 Sep 2000 15:47:13 +0000 (GMT) Received: from omzexch007.mcit.com ([166.37.194.38]) by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) with ESMTP id <0G0K00H4XRUBTL@dgismtp02.wcomnet.com>; Fri, 08 Sep 2000 15:46:59 +0000 (GMT) Received: by omzexch007 with Internet Mail Service (5.5.2651.58) id ; Fri, 08 Sep 2000 15:46:59 +0000 Content-return: allowed Date: Fri, 08 Sep 2000 15:46:56 +0000 From: "Pizzimenti, Joe" Subject: RE: [SIP] Stateless Proxy To: "'albee@miel.mot.com'" , sip@lists.bell-labs.com Message-id: <75C79E507864D3118AFC00805FEAB7D87E6D6E@ripexch001.mcit.com> 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Vimal, According to the RFC The "action" parameter is used only when registering with the REGISTER request. It indicates whether the client wishes that the server proxy or redirect future requests intended for the client. If this parameter is not specified the action taken depends on server configuration." So if the action is not specified in the contact the server should, in my opinion, be permissive and proxy the request. In the case where the registrar search results in action values of "redirect" then the server should redirect the response back to the originator. When the intended behavior of the server is to only proxy requests, then when the server's registrar search results in a "redirect" action, I would think a 4xx response (e.g. "403 Forbidden") would be sent to the originating agent. Also, according to the RFC, "All current registrations MUST share the same action value. Registrations that have a different action than current registrations for the same user MUST be rejected with status of 409 (Conflict)." - Joe Pizzimenti WorldCom -----Original Message----- From: Albee Vimal [mailto:albee@miel.mot.com] Sent: Friday, September 08, 2000 11:21 AM To: sip@lists.bell-labs.com Subject: [SIP] Stateless Proxy Hi I have simple question on the following scenarios : When a stateless proxy receives a request, it does a registrar search for the RequestURI received. If the registrar search results in multiple entries being returned without any action specified(or with action = proxy). Should proxy drop this request, since it does not support redirection. Thanks Vimal _______________________________________________ SIP mailing list SIP@lists.bell-labs.com 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 Sep 8 12: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 MAA25078 for ; Fri, 8 Sep 2000 12:05: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 25C504440E; Fri, 8 Sep 2000 11:04:28 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id 41B47443B7 for ; Fri, 8 Sep 2000 11:04:23 -0400 (EDT) Received: from gethin by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id RAA27147; Fri, 8 Sep 2000 17:02:30 +0100 (BST) From: Gethin Liddell Organization: Ubiquity Software Corp. To: "Pizzimenti, Joe" , "'albee@miel.mot.com'" , sip@lists.bell-labs.com Subject: RE: [SIP] Stateless Proxy Date: Fri, 8 Sep 2000 16:44:54 +0100 X-Mailer: KMail [version 1.0.29.2] Content-Type: text/plain References: <75C79E507864D3118AFC00805FEAB7D87E6D6E@ripexch001.mcit.com> In-Reply-To: <75C79E507864D3118AFC00805FEAB7D87E6D6E@ripexch001.mcit.com> MIME-Version: 1.0 Message-Id: <00090816560600.14393@gethin> Content-Transfer-Encoding: 8bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 8bit Stateless proxies do NOT generate responses of any kind. As soon as responses are created, it becomes stateful. Now this all leads into the argument about how a stateless proxy is only a logical role that can be applied in certain circumstances (i.e. when everything is good and great) as soon as errors/redirect/etc... occur then the proxy needs to find someway to become stateful. so stateless proxies only proxy. if you have to re-direct, you have a statefull server. if you don't want to turn statefull then the only thing you can do is drop the request. HTH :) On Fri, 08 Sep 2000, Pizzimenti, Joe wrote: > Vimal, > > According to the RFC > > The "action" parameter is used only when registering with the REGISTER > request. It indicates whether the client wishes that the server proxy or > redirect future requests intended for the client. If this parameter is not > specified the action taken depends on server configuration." > > So if the action is not specified in the contact the server should, in my > opinion, be permissive and proxy the request. > > In the case where the registrar search results in action values of > "redirect" then the server should redirect the response back to the > originator. When the intended behavior of the server is to only proxy > requests, then when the server's registrar search results in a "redirect" > action, I would think a 4xx response (e.g. "403 Forbidden") would be sent to > the originating agent. > > Also, according to the RFC, "All current registrations MUST share the same > action value. Registrations that have a different action than current > registrations for the same user MUST be rejected with status of 409 > (Conflict)." > > - Joe Pizzimenti > WorldCom -- 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 Fri Sep 8 12:23: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 MAA25300 for ; Fri, 8 Sep 2000 12: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 A1D3F443F4; Fri, 8 Sep 2000 11:22:55 -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 8D1C544371 for ; Fri, 8 Sep 2000 11:22:52 -0400 (EDT) Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-32 #42257) id <0G0K00901THVG5@firewall.mcit.com> for sip@lists.bell-labs.com; Fri, 8 Sep 2000 16:22:43 +0000 (GMT) Received: from dgismtp02.wcomnet.com ([166.38.58.142]) by firewall.mcit.com (PMDF V5.2-32 #42257) with ESMTP id <0G0K005GXTHVZA@firewall.mcit.com>; Fri, 08 Sep 2000 16:22:43 +0000 (GMT) Received: from CONVERSION-DAEMON by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) id <0G0K00D01THV17@dgismtp02.wcomnet.com>; Fri, 08 Sep 2000 16:22:43 +0000 (GMT) Received: from dgismtp02.wcomnet.com by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) with SMTP id <0G0K00D01THT0V@dgismtp02.wcomnet.com>; Fri, 08 Sep 2000 16:22:43 +0000 (GMT) Received: from omzexch007.mcit.com ([166.37.194.38]) by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) with ESMTP id <0G0K009C7THGVL@dgismtp02.wcomnet.com>; Fri, 08 Sep 2000 16:22:28 +0000 (GMT) Received: by omzexch007 with Internet Mail Service (5.5.2651.58) id ; Fri, 08 Sep 2000 16:22:28 +0000 Content-return: allowed Date: Fri, 08 Sep 2000 16:22:21 +0000 From: "Pizzimenti, Joe" Subject: RE: [SIP] Stateless Proxy To: "'Gethin Liddell'" , "'albee@miel.mot.com'" , sip@lists.bell-labs.com Message-id: <75C79E507864D3118AFC00805FEAB7D87E6D6F@ripexch001.mcit.com> 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Agreed. - Joe -----Original Message----- From: Gethin Liddell [mailto:gethin@ubiquity.net] Sent: Friday, September 08, 2000 11:45 AM To: Pizzimenti, Joe; 'albee@miel.mot.com'; sip@lists.bell-labs.com Subject: RE: [SIP] Stateless Proxy Stateless proxies do NOT generate responses of any kind. As soon as responses are created, it becomes stateful. Now this all leads into the argument about how a stateless proxy is only a logical role that can be applied in certain circumstances (i.e. when everything is good and great) as soon as errors/redirect/etc... occur then the proxy needs to find someway to become stateful. so stateless proxies only proxy. if you have to re-direct, you have a statefull server. if you don't want to turn statefull then the only thing you can do is drop the request. HTH :) On Fri, 08 Sep 2000, Pizzimenti, Joe wrote: > Vimal, > > According to the RFC > > The "action" parameter is used only when registering with the REGISTER > request. It indicates whether the client wishes that the server proxy or > redirect future requests intended for the client. If this parameter is not > specified the action taken depends on server configuration." > > So if the action is not specified in the contact the server should, in my > opinion, be permissive and proxy the request. > > In the case where the registrar search results in action values of > "redirect" then the server should redirect the response back to the > originator. When the intended behavior of the server is to only proxy > requests, then when the server's registrar search results in a "redirect" > action, I would think a 4xx response (e.g. "403 Forbidden") would be sent to > the originating agent. > > Also, according to the RFC, "All current registrations MUST share the same > action value. Registrations that have a different action than current > registrations for the same user MUST be rejected with status of 409 > (Conflict)." > > - Joe Pizzimenti > WorldCom -- 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 Fri Sep 8 14:46: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 OAA27861 for ; Fri, 8 Sep 2000 14:46: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 0646944406; Fri, 8 Sep 2000 13:46:11 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from blanc.cisco.com (blanc.cisco.com [161.44.3.203]) by lists.bell-labs.com (Postfix) with ESMTP id B836244371 for ; Fri, 8 Sep 2000 13:46:08 -0400 (EDT) Received: (ddaiker@localhost) by blanc.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) id OAA25041; Fri, 8 Sep 2000 14:43:30 -0400 (EDT) From: David Daiker Message-Id: <200009081843.OAA25041@blanc.cisco.com> Subject: Re: [SIP] Stateless Proxy To: gethin@ubiquity.net (Gethin Liddell) Date: Fri, 8 Sep 2000 14:43:30 -0400 (EDT) Cc: Joe.Pizzimenti@wcom.com (Pizzimenti Joe), albee@miel.mot.com ('albee@miel.mot.com'), sip@lists.bell-labs.com In-Reply-To: <00090816560600.14393@gethin> from "Gethin Liddell" at Sep 08, 2000 04:44:54 PM 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit this is silly, are you saying that a stateless server that fails or can't decode the request can't respond with a 5xx or 4xx ? The only alternative is to drop the message and let the sender retransmit an invalid message 7 or 11 times ?, why not return the final response, if he gets it, he'll return an ACK which can be dropped, it not, he'll retransmit and you return the error again. Seems a lot friendlier to the sender, without any downside what's the problem ? david > Stateless proxies do NOT generate responses of any kind. > > As soon as responses are created, it becomes stateful. Now this all > leads into the argument about how a stateless proxy is only a logical > role that can be applied in certain circumstances (i.e. when everything > is good and great) as soon as errors/redirect/etc... occur then the > proxy needs to find someway to become stateful. > > so stateless proxies only proxy. if you have to re-direct, you have a > statefull server. if you don't want to turn statefull then the only > thing you can do is drop the request. > > HTH > > :) > > On Fri, 08 Sep 2000, Pizzimenti, Joe wrote: > > Vimal, > > > > According to the RFC > > > > The "action" parameter is used only when registering with the REGISTER > > request. It indicates whether the client wishes that the server proxy or > > redirect future requests intended for the client. If this parameter is not > > specified the action taken depends on server configuration." > > > > So if the action is not specified in the contact the server should, in my > > opinion, be permissive and proxy the request. > > > > In the case where the registrar search results in action values of > > "redirect" then the server should redirect the response back to the > > originator. When the intended behavior of the server is to only proxy > > requests, then when the server's registrar search results in a "redirect" > > action, I would think a 4xx response (e.g. "403 Forbidden") would be sent to > > the originating agent. > > > > Also, according to the RFC, "All current registrations MUST share the same > > action value. Registrations that have a different action than current > > registrations for the same user MUST be rejected with status of 409 > > (Conflict)." > > > > - Joe Pizzimenti > > WorldCom > > > -- > 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 > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Sep 8 14:57: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 OAA28073 for ; Fri, 8 Sep 2000 14:57: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 725C944418; Fri, 8 Sep 2000 13:57: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 18C8744371 for ; Fri, 8 Sep 2000 13:57:01 -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 OAA03932; Fri, 8 Sep 2000 14:58:48 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Fri, 8 Sep 2000 14:54:07 -0400 Message-ID: From: Jonathan Rosenberg To: "'Hisham Khartabil'" , "'mranga@nist.gov'" Cc: "'sip@lists.bell-labs.com'" Subject: RE: [SIP] REGISTER Method questions. Date: Fri, 8 Sep 2000 14:54:06 -0400 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com > -----Original Message----- > From: Hisham Khartabil [mailto:hisham.khartabil@lmf.ericsson.se] > Sent: Friday, September 08, 2000 1:52 AM > To: mranga@nist.gov > Cc: sip@lists.bell-labs.com > Subject: Re: [SIP] REGISTER Method questions. > > > > > "m. ranganathan" wrote: > > > Hello! > > > > At the risk of asking simple questions that have been asked > and answered > > in the past, I would be grateful if somebody could help me > understand a > > few things about the REGISTER request. > > > > 1. The RFC states that Registrations with the same Call-ID must have > > increasing CSeq header values, however the server does not > reject out of > > order requests. I am confused about the purpose of the CSeq value in > > that case. Is there an implication here that the headers must have > > montonically increasing (but not necessarily sequentially > increasing ) > > values? > > This is for the scenario where an older request arrives at > the server later > than a newer one. Let me clarify here. In general, CSeq is not sequentially increasing (i.e., 1,2,3) but just monotonically (this allows it to be derived off the system clock for robustness across reboots). With REGISTER, the requests are processed even if out of order; this is again for robustness for devices without persistent time, and also to allow registrations for the same address from different devices. Thus, CSeq is not really critical for registrations, but SHOULD increase in any case for consistency. > > > > > > > 2. If a new registration for a given SIP URI supersedes an existing > > registration for the same URI, do the contact headers in the new > > request replace the existing ones? (i.e. are the old > contact headers > > implicitly discarded or do they have to be explicitly discarded with > > another register request containing the contact header and > a 0 expires > > time?) > > no, you don't discard the older ones, you just add the new ones to the > list. Contacts are removed when they expire according to the > Expires header > upon registration or with a REGISTER request with expires 0. Careful; if the contacts in the new registration are the same as in the existing registration, these update the expiration time for those contacts. > > > > > > > 3. What "action value" is being referred to in the statement "All > > current registrations must share the same action value" > > Action indicates whether the client wishes that the server > proxy or redirect > future requests intended for the client. So, you can't have > one contact > with action=proxy and another with action=redirect. action is a Contact parameter that can be placed in REGISTER contact headers. As Hisham says, it indicates the clients desired processing. -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 Sep 8 15:28: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 PAA28771 for ; Fri, 8 Sep 2000 15: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 A80AD44415; Fri, 8 Sep 2000 14:27:49 -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 B23C544371 for ; Fri, 8 Sep 2000 14:27: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 PAA04268; Fri, 8 Sep 2000 15:25:37 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Fri, 8 Sep 2000 15:20:56 -0400 Message-ID: From: Jonathan Rosenberg To: "'David Daiker'" , "'gethin@ubiquity.net'" Cc: "'Joe.Pizzimenti@wcom.com'" , "'albee@miel.mot.com'" , "'sip@lists.bell-labs.com'" Subject: RE: [SIP] Stateless Proxy Date: Fri, 8 Sep 2000 15:20:55 -0400 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Actually, turns out that you can send a response and be stateless, but ONLY if you don't send a provisional response first. Here's how it goes. The "stateless" server receives a request, and sends some response. It then forgets the transaction. The response is lost, but thats OK. Because the client never got a 1xx, it resends the request. To the stateless server, this is a brand new request, and it regenerates and resends the response. Voila - reliability. Any ACKs it gets would just be dropped. Neil writes: >You would not expect to find a Stateless Proxy operating like >this. >In stateless mode a Proxy is really just a next hop router of SIP >messages, where the next hop is most likely to be a stateful >Proxy, >possibly co-located with a Registrar, or a Redirect Server. >Proxies >operating in stateless mode can be thought of as existing in the >core >of the network and being concerned with issues of performance, >reliability and scalability. I disagree. There is no reason a stateless proxy can't talk to a location server to access registrations, and use them to proxy. In general, a proxy is best being stateless whenever it can, and routing services can almost always be handled by a stateless proxy. -Jonathan R. > -----Original Message----- > From: David Daiker [mailto:ddaiker@cisco.com] > Sent: Friday, September 08, 2000 2:44 PM > To: gethin@ubiquity.net > Cc: Joe.Pizzimenti@wcom.com; albee@miel.mot.com; > sip@lists.bell-labs.com > Subject: Re: [SIP] Stateless Proxy > > > > this is silly, > are you saying that a stateless server that fails or can't > decode the request can't respond with a 5xx or 4xx ? > The only alternative is to drop the message and let the > sender retransmit an invalid message 7 or 11 times ?, > why not return the final response, if he gets it, > he'll return an ACK which can be dropped, > it not, he'll retransmit and you return the error again. > > Seems a lot friendlier to the sender, without any downside > > what's the problem ? > > david > > > > Stateless proxies do NOT generate responses of any kind. > > > > As soon as responses are created, it becomes stateful. Now this all > > leads into the argument about how a stateless proxy is only > a logical > > role that can be applied in certain circumstances (i.e. > when everything > > is good and great) as soon as errors/redirect/etc... occur then the > > proxy needs to find someway to become stateful. > > > > so stateless proxies only proxy. if you have to re-direct, > you have a > > statefull server. if you don't want to turn statefull then the only > > thing you can do is drop the request. > > > > HTH > > > > :) > > > > On Fri, 08 Sep 2000, Pizzimenti, Joe wrote: > > > Vimal, > > > > > > According to the RFC > > > > > > The "action" parameter is used only when registering with > the REGISTER > > > request. It indicates whether the client wishes that the > server proxy or > > > redirect future requests intended for the client. If this > parameter is not > > > specified the action taken depends on server configuration." > > > > > > So if the action is not specified in the contact the > server should, in my > > > opinion, be permissive and proxy the request. > > > > > > In the case where the registrar search results in action values of > > > "redirect" then the server should redirect the response > back to the > > > originator. When the intended behavior of the server is > to only proxy > > > requests, then when the server's registrar search results > in a "redirect" > > > action, I would think a 4xx response (e.g. "403 > Forbidden") would be sent to > > > the originating agent. > > > > > > Also, according to the RFC, "All current registrations > MUST share the same > > > action value. Registrations that have a different action > than current > > > registrations for the same user MUST be rejected with > status of 409 > > > (Conflict)." > > > > > > - Joe Pizzimenti > > > WorldCom > > > > > > -- > > 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 > > > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > 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 Sep 8 17:01: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 RAA00469 for ; Fri, 8 Sep 2000 17:01: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 6F5F04439D; Fri, 8 Sep 2000 16: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 60DED4435D for ; Fri, 8 Sep 2000 15:59:57 -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 ; Fri, 8 Sep 2000 13:58:08 -0700 From: "Simon Barber" To: Date: Fri, 8 Sep 2000 14:01:13 -0700 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0052_01C0199D.3FDEF4B0" 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 Subject: [SIP] REGISTER in call flows draft Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com This is a multi-part message in MIME format. ------=_NextPart_000_0052_01C0199D.3FDEF4B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, The rfc2543bis-01 specifies that REGISTER requests should be sent both by multicast and to the home address, with the request-URI set to the domain portion only of the user's from address. Is this a mistake in the REGISTER requests in the call flows draft? The call flows draft does not include an example of REGISTER being forwarded through proxies to reach the registration server for the 'from' domain. Could we have an example of this please? also perhaps a more explicit example of how REGISTER is sent *both* multicast to a local registration server *and* unicast to the home server. Simon Barber -----Original Message----- From: sip-admin@lists.bell-labs.com [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Jonathan Rosenberg Sent: Friday, September 08, 2000 11:54 AM To: 'Hisham Khartabil'; 'mranga@nist.gov' Cc: 'sip@lists.bell-labs.com' Subject: RE: [SIP] REGISTER Method questions. > -----Original Message----- > From: Hisham Khartabil [mailto:hisham.khartabil@lmf.ericsson.se] > Sent: Friday, September 08, 2000 1:52 AM > To: mranga@nist.gov > Cc: sip@lists.bell-labs.com > Subject: Re: [SIP] REGISTER Method questions. > > > > > "m. ranganathan" wrote: > > > Hello! > > > > At the risk of asking simple questions that have been asked > and answered > > in the past, I would be grateful if somebody could help me > understand a > > few things about the REGISTER request. > > > > 1. The RFC states that Registrations with the same Call-ID must have > > increasing CSeq header values, however the server does not > reject out of > > order requests. I am confused about the purpose of the CSeq value in > > that case. Is there an implication here that the headers must have > > montonically increasing (but not necessarily sequentially > increasing ) > > values? > > This is for the scenario where an older request arrives at > the server later > than a newer one. Let me clarify here. In general, CSeq is not sequentially increasing (i.e., 1,2,3) but just monotonically (this allows it to be derived off the system clock for robustness across reboots). With REGISTER, the requests are processed even if out of order; this is again for robustness for devices without persistent time, and also to allow registrations for the same address from different devices. Thus, CSeq is not really critical for registrations, but SHOULD increase in any case for consistency. > > > > > > > 2. If a new registration for a given SIP URI supersedes an existing > > registration for the same URI, do the contact headers in the new > > request replace the existing ones? (i.e. are the old > contact headers > > implicitly discarded or do they have to be explicitly discarded with > > another register request containing the contact header and > a 0 expires > > time?) > > no, you don't discard the older ones, you just add the new ones to the > list. Contacts are removed when they expire according to the > Expires header > upon registration or with a REGISTER request with expires 0. Careful; if the contacts in the new registration are the same as in the existing registration, these update the expiration time for those contacts. > > > > > > > 3. What "action value" is being referred to in the statement "All > > current registrations must share the same action value" > > Action indicates whether the client wishes that the server > proxy or redirect > future requests intended for the client. So, you can't have > one contact > with action=proxy and another with action=redirect. action is a Contact parameter that can be placed in REGISTER contact headers. As Hisham says, it indicates the clients desired processing. -Jonathan R. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip ------=_NextPart_000_0052_01C0199D.3FDEF4B0 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) 232-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: URL:http://www.firetalk.com EMAIL;PREF;INTERNET:simon@firetalk.com REV:20000908T025950Z END:VCARD ------=_NextPart_000_0052_01C0199D.3FDEF4B0-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Sep 8 17:23: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 RAA00859 for ; Fri, 8 Sep 2000 17:23: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 B187E443AC; Fri, 8 Sep 2000 16: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 50AAF4435D for ; Fri, 8 Sep 2000 16:23:03 -0400 (EDT) Received: from ESCORT (DYN001-DA02A03-114.arcommunications.net [64.17.132.243]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with SMTP id RAA05772; Fri, 8 Sep 2000 17:21:06 -0400 (EDT) From: "Steve Donovan" To: "Neil Deason" Cc: Subject: RE: [SIP] transaction identification Date: Fri, 8 Sep 2000 16:16:25 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <39B8BE39.F5566209@ubiquity.net> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Neil Deason wrote: > > As you say this wouldn't be a problem if > original uri in the record-route header was used > instead. But Jonathan pointed out that using the > originating name-addr... > > " maintains the fundamental principle that the > request URI indicates for whom the request is > destined. By relying on Route headers to get the > request there, even though the request URI says > something completely difference, makes the > operation of the protocol brittle. We have seen > this at bakeoffs - loops often occur if any proxy > has anything slightly wrong with their route > processing." > Let me push on this one a little bit. If the fundamental principle is to be held for Route headers in requests from the callee to the caller then why is that principle not also enforced for routes in requests going from the caller to the callee? If this is important then the same rule should be applied for building the route in both directions and the uri in the contact received in the 200 OK should be used for building the caller to callee route. Don't get me wrong, I don't think this should be done, I just don't understand the value of the request URI fundamental principle. I also don't understand how having broken proxies at bakeoffs makes the protocol brittle. It is also the case if proxies have anything wrong with their via processing. If the proxy is implemented correctly then using the original uri's in the Record-Route should work just fine. After all, proxies need to be able to handle routes with the original request uris correctly in the caller->callee direction. Why should they not be able to in the callee->caller direction? My other question on the proposed solution is how can call stateful proxies correlate requests with Route headers going in the callee->caller direction with the correct call leg/transaction without the original request-uri? Steve _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sat Sep 9 13: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 NAA22349 for ; Sat, 9 Sep 2000 13:55: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 DB91E44342; Sat, 9 Sep 2000 12:54:48 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from imr1.ericy.com (unknown [208.237.135.240]) by lists.bell-labs.com (Postfix) with ESMTP id 84CE544339 for ; Sat, 9 Sep 2000 12:54:45 -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 MAA25766 for ; Sat, 9 Sep 2000 12:54:43 -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 MAA26101 for ; Sat, 9 Sep 2000 12:54:43 -0500 (CDT) Received: from b04a45.exu.ericsson.se (b04a45 [138.85.60.145]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id MAA29664 for ; Sat, 9 Sep 2000 12:54:42 -0500 (CDT) From: Sean Olson Received: (from eussean@localhost) by b04a45.exu.ericsson.se (8.9.1/8.9.1) id MAA01863 for sip@lists.bell-labs.com; Sat, 9 Sep 2000 12:54:41 -0500 (CDT) Date: Sat, 9 Sep 2000 12:54:41 -0500 (CDT) Message-Id: <200009091754.MAA01863@b04a45.exu.ericsson.se> To: sip@lists.bell-labs.com Subject: Re: [SIP] tel URL v. SIP URL X-Sun-Charset: US-ASCII Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com > Previously, I had thought the only germane distinction between the two was > the absence of a host portion (and hence rules that do not allow the > inclusion of the tel URL in headers that are used in hop-by-hop routing like > Contact); the tacit host component of the tel URL in a Request-URI would be > the UA at which the network (proxies using local routing tables or ENUM or > what have you) feels this call should terminate. I see no reason to bar tel: URIs for hop-by-hop routing. The tsp and phone-context parameters provide sufficient context for a node that understands the tel: URI scheme to route the message. In general, the interpretation of a URI (sip, tel, whatever) may vary from node to node depending on local provisioning etc. at that node. In this sense, a SIP URI is no more or less definitive than a tel: URI. > Jon Peterson > Level(3) Communications -- 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 Sun Sep 10 00:40: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 AAA27370 for ; Sun, 10 Sep 2000 00:40: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 66A7E4433C; Sat, 9 Sep 2000 23:40: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 2378544338 for ; Sat, 9 Sep 2000 23:39: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 AAA08803; Sun, 10 Sep 2000 00:41:22 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Sun, 10 Sep 2000 00:36:38 -0400 Message-ID: From: Jonathan Rosenberg To: "'Neil Deason'" Cc: "'sip@lists.bell-labs.com'" Subject: RE: [SIP] transaction identification Date: Sun, 10 Sep 2000 00:36:38 -0400 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Neil writes: > > > What you copy from Record-Route into Route depends on whether > > > the UA finds the Record-Route in a request or a response. > > > If it is in a response then it copies the Record-Route into > > > Route header fields. If it finds it in a request it only copies > > > the maddr param and any port [bis-01]. The remainder of the > > > Route name-addr value being taken from the originating > > > name-addr value, i.e. the Contact or From header. > > > > Well, the name-addr is part of the URI. The question is: what about > > Record-Route parameters? Seems like these should be copied. The spec > > should be clarified in that regard. > > I am not sure I follow you. Are you proposing that generic > Record-Route params are copied into Route? This wouldn't > help as any salient parameters would be lost when the preceding > Server pops the Route into the Request URI. The spec is already > clear about what is copied from where in constructing Route > when it comes to URI params. But this has it's own problems > if you are banking on getting any params back from there. > Which URI would you expect to get it back from as it differs > depending whether the caller or callee sends the request. I'm just trying to ensure that we don't lose the possibility of extensibility. I understand the issue about not getting these parameters back. But, when we say in the spec "copy the URI" it should always mean the whole URI. Shiv writes: >> >> Unless there\'s loud protest, it will vanish soon, so speak up if >you\'re >> fond of Via hiding. >> > >I should start by saying I am not fond of Via hiding. It will make me >happy if is goes away. > >However, I see an overall problem in SIP+SDP as being leaking >internal network topololgy information. Firewalls go out >of the way to hide this kind of information, which SIP is giving >away. > >I think a narrow scope of attempting to hide only the topology should >suffice. Hiding every hop is probably not necessary. Problem areas >should include \'Contact:\' and SDP. The argument isn't that there is no need to hide topology; the argument is that via hiding is not achieving this goal. A much better was is through back to back UAS/UAC that not only strips the Vias, but also hides From, SDP, and other components that contain even more sensitive information. Sharath writes: > Implementing loop detection in *stateless proxies*, is it essential to > compute the first part of branch id as a hash of To, From, > CallID, Cseq in > addition to RequestURI and topmost Via. > > Is it not sufficient to simply use the request URI and > topmost Via alone for > the hash computation since the other values are not going to > change anyway ? > I am not sure I understand why these fields are being used > for the hash > computation even in the case of stateless proxies. Yes, I think that would be OK. There is no compelling reason they are included; its just typical to include them in transaction identification computations. > The second part of the branch could be computed as the hash > of outgoing > request uri + some server instance ? No. That won't make it unique across requests in the reverse direction after a spiral. It would have to also include the topmost Via of the incoming request. -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 Sun Sep 10 01:48: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 BAA02103 for ; Sun, 10 Sep 2000 01:48: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 B34A044343; Sun, 10 Sep 2000 00:48:26 -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 91EBB44338 for ; Sun, 10 Sep 2000 00:48: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 BAA08912; Sun, 10 Sep 2000 01:50:11 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Sun, 10 Sep 2000 01:45:28 -0400 Message-ID: From: Jonathan Rosenberg To: "'David Yon'" , "'Fairlie-Cuninghame, Robert'" , "'sip@lists.bell-labs.com'" Subject: RE: [SIP] SIP, SDP, and TCP-based media transport Date: Sun, 10 Sep 2000 01:45:27 -0400 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com > -----Original Message----- > From: David Yon [mailto:yon@dialout.net] > Sent: Friday, September 08, 2000 11:16 AM > To: Fairlie-Cuninghame, Robert; sip@lists.bell-labs.com > Subject: RE: [SIP] SIP, SDP, and TCP-based media transport > > > At 11:23 PM 9/7/00 -0700, Fairlie-Cuninghame, Robert wrote: > > > > > > I think that gets rid of the race condition, works through an > > > ALG where > > > port numbers might change, yet still allows one of the > > > connections to be > > > shut down when circumstances permit. Worst case is each > > > connection becomes > > > unidirectional. > > > > > > Comments? Anyone see a hole I missed? > > > > >Sounds good - I can't see any problems. So I guess this also > means that once > >you have received data on a TCP connection you may not close it. > > Correct. Ditto if you've sent data on a TCP connection. > Once you've sent > *and* received data, and they happen to occur both on the same TCP > connection, it's safe to close the other one. You should include this specific condition in the draft. Right now, its a bit unclear how to usefully determine when a "timeout" has occurred in order to close the other connection. > So, if there are no additional comments, how do I go about > getting this > into the queue? Jonathan...? Henning...? Comment? Submit it as an I-D. You do that by sending it to internet-drafts@ietf.org. It can't be a working group item yet, since there has not yet been consensus to add this as a working group item (to date, this has happened initially by proposing this at a meeting, and seeing if there are objections from the list afterwards). So, you will need a filename like: draft-yon-sip-sdp-tcpmedia-00.txt -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 Sun Sep 10 02:07: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 CAA07417 for ; Sun, 10 Sep 2000 02:07: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 3EBFD44360; Sun, 10 Sep 2000 01:06:45 -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 EB0F444350 for ; Sun, 10 Sep 2000 01:06: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 CAA08934; Sun, 10 Sep 2000 02:08:17 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Sun, 10 Sep 2000 02:03:34 -0400 Message-ID: From: Jonathan Rosenberg To: "'Hong Chen'" , "'Rohan Mahy'" Cc: "'Tom-PT Taylor'" , "'Henning Schulzrinne'" , "'Anders Kristensen'" , "'sip@lists.bell-labs.com'" Subject: RE: [SIP] SIP feature services Date: Sun, 10 Sep 2000 02:03:33 -0400 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Hong wrote: > > Different web browsers do not all display the same content > in exactly the > > same way, but they the server still interoperates with all > of these browsers. > > > > Likewise SIP UAs don't have to act exactly the same way, as > long as the > > right parties end up communicating. That said, I think the > *example* call > > flow work is extremely important, but I feel that the > examples plus the > > bakeoff is sufficient guidance to yield interoperable product. > > I agree, " the *example* call flow work is extremely > important" for the success > of SIP and expect to have it ASAP, plus I hope it will have > some guideline of > the systematic mechanism we can use for features not included > in example and > features in the future. This really depends on the type of feature. Many features are of the type that the entity providing the feature is the only one that need know about it; successful operation depends only on having the other entities operate according to standard rfc2543 behavior. This kind of feature is exactly how the web operates. It is our intention and hope to define into SIP and its extensions very general purpose behavior, so that more features, rather than less, can be defined in this way. In cases where that is not true (i.e., call hold), call flows are definitely important, and we have been doing that in the various drafts. -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 Sun Sep 10 02:11: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 CAA09986 for ; Sun, 10 Sep 2000 02:11: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 77AAC4436B; Sun, 10 Sep 2000 01:10:46 -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 4492A44338 for ; Sun, 10 Sep 2000 01:10: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 CAA08946; Sun, 10 Sep 2000 02:12:30 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Sun, 10 Sep 2000 02:07:47 -0400 Message-ID: From: Jonathan Rosenberg To: "'rajeev@empowertel.com'" , "'Hong Chen'" Cc: "'Anders Kristensen'" , "'sip@lists.bell-labs.com'" Subject: RE: [SIP] SIP feature services Date: Sun, 10 Sep 2000 02:07:46 -0400 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com This question only makes sense in the context of directly applying the IN model for SIP applications. I think SIP and its operation is sufficiently different that this really doesn't make sense. In the SIP model, the AS is simply another SIP entity. This means that it gets the initial INVITE, along with any other signaling in the call (if it record-routes). Any "mid-call" event, such as a re-INVITE, gets to the AS because the proxy will forward the INVITE there are per normal SIP procedures. Rajeev writes: > How do you indicate the occurence of a mid-call trigger (such > as for call > waiting) from a SIP proxy (which could be running in a > softswitch) to an > application server (which contains logic on how to handle the > feature for > this specific subscriber, and may be running on another > SCP-like node)? This > is a transaction-type messaging between SIP proxy and > application server, > which is not necessarily in the context of a SIP session > setup between the > two. -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 Sun Sep 10 03:00:22 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA10229 for ; Sun, 10 Sep 2000 03:00:22 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id EBE2D44354; Sun, 10 Sep 2000 02:00: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 775C444337 for ; Sun, 10 Sep 2000 02:00: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 CAA08989; Sun, 10 Sep 2000 02:58:03 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Sun, 10 Sep 2000 02:53:19 -0400 Message-ID: From: Jonathan Rosenberg To: "'Cliff.Harris@nokia.com'" , "'etremblay@mediatrix.com'" Cc: "'sip@lists.bell-labs.com'" Subject: RE: [SIP] Possible REFER problem? Date: Sun, 10 Sep 2000 02:53:15 -0400 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com 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 Sun Sep 10 09:57: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 JAA08522 for ; Sun, 10 Sep 2000 09:57: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 3305E44341; Sun, 10 Sep 2000 08:57:08 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from nautilus.shore.net (nautilus.shore.net [207.244.124.104]) by lists.bell-labs.com (Postfix) with ESMTP id C4FFB44337 for ; Sun, 10 Sep 2000 08:57:05 -0400 (EDT) Received: from (hither.rfdsoftware.com) [209.192.222.62] by nautilus.shore.net with esmtp (Exim) for sip@lists.bell-labs.com id 13Y7bI-0006M1-00; Sun, 10 Sep 2000 09:56:52 -0400 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 JAA00767 for ; Sun, 10 Sep 2000 09:49:56 -0400 (EDT) Message-Id: <4.3.2.7.2.20000910094800.00e25140@webhost.tactical-sw.com> X-Sender: dnyon@webhost.tactical-sw.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 10 Sep 2000 09:56:08 -0400 To: sip@lists.bell-labs.com From: David Yon Subject: RE: [SIP] SIP, SDP, and TCP-based media transport 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com At 01:45 AM 9/10/00 -0400, you wrote: > > > > Correct. Ditto if you've sent data on a TCP connection. > > Once you've sent > > *and* received data, and they happen to occur both on the same TCP > > connection, it's safe to close the other one. > >You should include this specific condition in the draft. Right now, its >a bit unclear how to usefully determine when a "timeout" has occurred in >order >to close the other connection. Well there's really no timeout involved. Each endpoint knows whether it has an idle connection only after it has both sent and received data. I see no value in trying to apply a timeout to that algorithm. > > So, if there are no additional comments, how do I go about > > getting this > > into the queue? Jonathan...? Henning...? Comment? > >Submit it as an I-D. You do that by sending it to internet-drafts@ietf.org. >It can't be a working group item yet, since there has not yet been consensus >to add this as a working group item (to date, this has happened initially by >proposing this at a meeting, and seeing if there are objections from the >list afterwards). So, you will need a filename like: > >draft-yon-sip-sdp-tcpmedia-00.txt As it turns out the SIP WG chairs believe this to be more appropriately an MMUSIC item (since it only affects SDP), pending approval from the MMUSIC chair. So I'll be taking that track instead of SIP. I will keep the SIP list informed of changes to the draft and will be monitoring this list for discussion, since the draft is mostly applicable in the context of SIP. 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 Sep 11 04:05: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 EAA27625 for ; Mon, 11 Sep 2000 04:05: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 25AC344337; Mon, 11 Sep 2000 03:05:13 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id 5A18544336 for ; Mon, 11 Sep 2000 03:05:08 -0400 (EDT) Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id JAA19541; Mon, 11 Sep 2000 09:03:02 +0100 (BST) Message-ID: <39BC91B6.A9A46CEE@ubiquity.net> Date: Mon, 11 Sep 2000 09:03:02 +0100 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: "'David Daiker'" , "'gethin@ubiquity.net'" , "'Joe.Pizzimenti@wcom.com'" , "'albee@miel.mot.com'" , "'sip@lists.bell-labs.com'" Subject: Re: [SIP] Stateless 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > Actually, turns out that you can send a response and be stateless, but > ONLY if you don't send a provisional response first. > > Here's how it goes. The "stateless" server receives a request, and sends > some response. It then forgets the transaction. The response is lost, but > thats OK. Because the client never got a 1xx, it resends the request. To the > stateless server, this is a brand new request, and it regenerates and > resends the > response. Voila - reliability. Any ACKs it gets would just be dropped. > > Neil writes: > >You would not expect to find a Stateless Proxy operating like > >this. > >In stateless mode a Proxy is really just a next hop router of SIP > >messages, where the next hop is most likely to be a stateful > >Proxy, > >possibly co-located with a Registrar, or a Redirect Server. > >Proxies > >operating in stateless mode can be thought of as existing in the > >core > >of the network and being concerned with issues of performance, > >reliability and scalability. > > I disagree. There is no reason a stateless proxy can't talk to a location > server to access registrations, and use them to proxy. In general, a proxy > is best being stateless whenever it can, and routing services can almost > always be handled by a stateless proxy. I did not say it was impossible, but the reason I would not expect this to be a typical configuration for a Stateless Proxy is that when a Registrar returns multiple locations a Stateless proxy cannot fork to them. I would expect a Proxy to operate in stateless mode when it is routing on to other domains. When it has a request for it's own domain, and hence is co-operating with the Registrar for that domain, it is Stateful. 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 Sep 11 07:05: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 HAA28717 for ; Mon, 11 Sep 2000 07: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 76E5A44337; Mon, 11 Sep 2000 06:04:49 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id A44FC44336 for ; Mon, 11 Sep 2000 06:04:45 -0400 (EDT) Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id MAA22571; Mon, 11 Sep 2000 12:02:45 +0100 (BST) Message-ID: <39BCBBD5.A0B0E01B@ubiquity.net> Date: Mon, 11 Sep 2000 12:02:45 +0100 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: "'David Daiker'" , "'gethin@ubiquity.net'" , "'Joe.Pizzimenti@wcom.com'" , "'albee@miel.mot.com'" , "'sip@lists.bell-labs.com'" Subject: Re: [SIP] Stateless 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > Actually, turns out that you can send a response and be stateless, but > ONLY if you don't send a provisional response first. > > Here's how it goes. The "stateless" server receives a request, and sends > some response. It then forgets the transaction. The response is lost, but > thats OK. Because the client never got a 1xx, it resends the request. To the > stateless server, this is a brand new request, and it regenerates and > resends the > response. Voila - reliability. Any ACKs it gets would just be dropped. Any ACKs it gets would be dropped? If the stateless server has no concept of transactions that it previously responded to this wouldn't this in effect mean all ACKs get dropped. I think that might break the odd thing, like basic call setup for example. If you really, really wanted to do this sort of thing I would say you need to route on all ACKs and make sorting things out after your poor implementation somebody elses problem. Not at all to be recommended. If you want to send a response become stateful, after all the spec states in 12.3 that: "A stateless proxy forwards every request it receives downstream, and every response it receives upstream." 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 Sep 11 07: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 HAA28740 for ; Mon, 11 Sep 2000 07:07: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 7B99E44351; Mon, 11 Sep 2000 06:05:50 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id 86CD04434F for ; Mon, 11 Sep 2000 06:05:46 -0400 (EDT) Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id MAA24231; Mon, 11 Sep 2000 12:04:01 +0100 (BST) Message-ID: <39BCBC20.65E194@ubiquity.net> Date: Mon, 11 Sep 2000 12:04:00 +0100 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: Steve Donovan Cc: sip@lists.bell-labs.com Subject: Re: [SIP] transaction identification 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Steve Donovan wrote: > > Neil Deason wrote: > > > > > As you say this wouldn't be a problem if > > original uri in the record-route header was used > > instead. But Jonathan pointed out that using the > > originating name-addr... > > > > " maintains the fundamental principle that the > > request URI indicates for whom the request is > > destined. By relying on Route headers to get the > > request there, even though the request URI says > > something completely difference, makes the > > operation of the protocol brittle. We have seen > > this at bakeoffs - loops often occur if any proxy > > has anything slightly wrong with their route > > processing." > > > > Let me push on this one a little bit. If the fundamental principle is to be > held for Route headers in requests from the callee to the caller then why is > that principle not also enforced for routes in requests going from the > caller to the callee? If this is important then the same rule should be > applied for building the route in both directions and the uri in the contact > received in the 200 OK should be used for building the caller to callee > route. Don't get me wrong, I don't think this should be done, I just don't > understand the value of the request URI fundamental principle. > > I also don't understand how having broken proxies at bakeoffs makes the > protocol brittle. It is also the case if proxies have anything wrong with > their via processing. If the proxy is implemented correctly then using the > original uri's in the Record-Route should work just fine. After all, > proxies need to be able to handle routes with the original request uris > correctly in the caller->callee direction. Why should they not be able to > in the callee->caller direction? > > My other question on the proposed solution is how can call stateful proxies > correlate requests with Route headers going in the callee->caller direction > with the correct call leg/transaction without the original request-uri? Can you elaborate on this please. As I see things call leg, transactions and call state are 3 slightly different things. The Request-URI is only important in the transasction ID. In this example the new request would be part of a new transaction. It is also part of an existing call leg as defined by the Call-ID, To and From headers (user, hostport and tag parts). If it needs to a Proxy can maintain call state by keeping track of all requests and responses over this call leg. 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 Sep 11 07:38: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 HAA29304 for ; Mon, 11 Sep 2000 07:38: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 0042F44354; Mon, 11 Sep 2000 06:37:17 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from gorilla.mchh.siemens.de (gorilla.mchh.siemens.de [194.138.158.18]) by lists.bell-labs.com (Postfix) with ESMTP id 7991A44336 for ; Mon, 11 Sep 2000 06:37:13 -0400 (EDT) Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id NAA25312 for ; Mon, 11 Sep 2000 13:36:59 +0200 (MET DST) Received: from mchh247e.demchh201e.icn.siemens.de ([139.21.200.57]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id NAA10352 for ; Mon, 11 Sep 2000 13:36:35 +0200 (MET DST) Received: by MCHH247E with Internet Mail Service (5.5.2650.21) id ; Mon, 11 Sep 2000 13:37:09 +0200 Message-ID: <679076A067F2D211A8F70090274481B844E896@LNN201E> From: Blanchard Jacqueline To: "'sip@lists.bell-labs.com'" Date: Mon, 11 Sep 2000 13:36:57 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Subject: [SIP] Keep-Alive mechanism : REGISTER Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Hi, What is the keepalive mechanism I should use between a User Agent and a Proxy, just to know in my proxy that the User Agent is still there and has not logoff. Do I need to send periodic REGISTER ? ( I know about the ietf draft from draft-ietf-sip-session-timer-02.txt, proposing to use Re-INVITE message to know whether a SIP call session is alive) Thanks for answer J. Blanchard _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Sep 11 07:51: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 HAA29658 for ; Mon, 11 Sep 2000 07:51: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 A317E44365; Mon, 11 Sep 2000 06:50:51 -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 58E6D44346 for ; Mon, 11 Sep 2000 06:50:48 -0400 (EDT) Received: from dynamicsoft.com (ip46.honxr1.ras.tele.dk [195.249.119.46]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id HAA02185; Mon, 11 Sep 2000 07:51:58 -0400 (EDT) Message-ID: <39BCC6ED.FE578156@dynamicsoft.com> Date: Mon, 11 Sep 2000 13:50:05 +0200 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: Neil Deason Cc: Jonathan Rosenberg , "'David Daiker'" , "'gethin@ubiquity.net'" , "'Joe.Pizzimenti@wcom.com'" , "'albee@miel.mot.com'" , "'sip@lists.bell-labs.com'" Subject: Re: [SIP] Stateless Proxy References: <39BCBBD5.A0B0E01B@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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Neil Deason wrote: > > Jonathan Rosenberg wrote: > > > > Actually, turns out that you can send a response and be stateless, but > > ONLY if you don't send a provisional response first. > > > > Here's how it goes. The "stateless" server receives a request, and sends > > some response. It then forgets the transaction. The response is lost, but > > thats OK. Because the client never got a 1xx, it resends the request. To the > > stateless server, this is a brand new request, and it regenerates and > > resends the > > response. Voila - reliability. Any ACKs it gets would just be dropped. > > Any ACKs it gets would be dropped? If the stateless > server has no concept of transactions that it previously > responded to this wouldn't this in effect mean all ACKs > get dropped. Not necessarily. As long as the stateless server is able to recognize that it has previously rejected the corresponding INVITE things should work. This could be achieved in different ways, e.g. 1. by the same logic that caused the server to reject the INVITE in the first place (e.g. on basis of the request url). So if the server knows that it rejects all requests destined for sip:devnull@example.com, it can safely throw away ACKs destined for that address. 2. If the server inserted a Contact header identifying itself (allowed for 3xx responses), the ACK should be destined for the stateless server itself, and can be safely discarded. Basically, in this case state is not per-transaction, but per-server in some implementation dependent way. The point is that it ends up behaving as if it was transaction stateful. I agree it's not really recommendable, though. I think that might break the odd thing, like > basic call setup for example. If you really, really > wanted to do this sort of thing I would say you need to > route on all ACKs and make sorting things out after your > poor implementation somebody elses problem. Not at all to > be recommended. If you want to send a response become > stateful, after all the spec states in 12.3 that: > > "A stateless proxy forwards every request it receives > downstream, and every response it receives upstream." > > 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 -- 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 Mon Sep 11 07:56: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 HAA29948 for ; Mon, 11 Sep 2000 07:56: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 0ACD14436C; Mon, 11 Sep 2000 06:55:41 -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 4C2B944346 for ; Mon, 11 Sep 2000 06:55:38 -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 e8BBtRp24105; Mon, 11 Sep 2000 13:55:27 +0200 (MEST) Received: from ericsson.fi (E0080C7FA22D6.lmf.ericsson.se [131.160.30.48]) by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id OAA10622; Mon, 11 Sep 2000 14:55:26 +0300 (EET DST) Message-ID: <39BCC7C7.4B5278B1@ericsson.fi> Date: Mon, 11 Sep 2000 14:53:44 +0300 From: Hisham Khartabil X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Neil Deason Cc: Jonathan Rosenberg , "'David Daiker'" , "'gethin@ubiquity.net'" , "'Joe.Pizzimenti@wcom.com'" , "'albee@miel.mot.com'" , "'sip@lists.bell-labs.com'" Subject: Re: [SIP] Stateless Proxy References: <39BCBBD5.A0B0E01B@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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit I agree that a stateless proxy should not generate responses. I also think it should not have registrar search capabilities. It just forwards requests (including ACKs). The question here is what would a stateless proxy do when it recieves a request with the host part of the request-uri indicating its domain? Forwarding the request will cause loops. If searching a registrar or generating responses is not the behaviour of a stateless proxy, do we drop the request? how would the client be informed? should we just rely on retransmision timeout? (not very nice since this does not inform the caller that his request is failing because the proxy he is trying to contact is stateless) regards, Hisham Neil Deason wrote: > Jonathan Rosenberg wrote: > > > > Actually, turns out that you can send a response and be stateless, but > > ONLY if you don't send a provisional response first. > > > > Here's how it goes. The "stateless" server receives a request, and sends > > some response. It then forgets the transaction. The response is lost, but > > thats OK. Because the client never got a 1xx, it resends the request. To the > > stateless server, this is a brand new request, and it regenerates and > > resends the > > response. Voila - reliability. Any ACKs it gets would just be dropped. > > Any ACKs it gets would be dropped? If the stateless > server has no concept of transactions that it previously > responded to this wouldn't this in effect mean all ACKs > get dropped. I think that might break the odd thing, like > basic call setup for example. If you really, really > wanted to do this sort of thing I would say you need to > route on all ACKs and make sorting things out after your > poor implementation somebody elses problem. Not at all to > be recommended. If you want to send a response become > stateful, after all the spec states in 12.3 that: > > "A stateless proxy forwards every request it receives > downstream, and every response it receives upstream." > > 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 Sep 11 08:07: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 IAA00191 for ; Mon, 11 Sep 2000 08:07: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 98B494435E; Mon, 11 Sep 2000 07:06:54 -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 9C0BE44336 for ; Mon, 11 Sep 2000 07:06:51 -0400 (EDT) Received: from dynamicsoft.com (ip5.honxr1.ras.tele.dk [195.249.119.5]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id IAA02250; Mon, 11 Sep 2000 08:08:24 -0400 (EDT) Message-ID: <39BCCAC3.36974F10@dynamicsoft.com> Date: Mon, 11 Sep 2000 14:06:27 +0200 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: Hisham Khartabil Cc: Neil Deason , Jonathan Rosenberg , "'David Daiker'" , "'gethin@ubiquity.net'" , "'Joe.Pizzimenti@wcom.com'" , "'albee@miel.mot.com'" , "'sip@lists.bell-labs.com'" Subject: Re: [SIP] Stateless Proxy References: <39BCBBD5.A0B0E01B@ubiquity.net> <39BCC7C7.4B5278B1@ericsson.fi> 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Hisham Khartabil wrote: > > I agree that a stateless proxy should not generate responses. I also think it > should not have registrar search capabilities. It just forwards requests > (including ACKs). > > The question here is what would a stateless proxy do when it recieves a request > with the host part of the request-uri indicating its domain? Forwarding the > request will cause loops. If searching a registrar or generating responses is not > the behaviour of a stateless proxy, do we drop the request? how would the client > be informed? should we just rely on retransmision timeout? (not very nice since > this does not inform the caller that his request is failing because the proxy he > is trying to contact is stateless) The proxy should respond with an error, in this case presumably a 404. In this case the "stateless proxy" acts as a UAS and this would ordinarily be done in a transaction stateful fashion. The point here is that "proxy", "uac", "uas", etc are logical roles and a SIP entitiy may be all of them at the same time for different transactions. This must be the ultimate FAQ. Go check the list. Anders > > regards, > Hisham > > Neil Deason wrote: > > > Jonathan Rosenberg wrote: > > > > > > Actually, turns out that you can send a response and be stateless, but > > > ONLY if you don't send a provisional response first. > > > > > > Here's how it goes. The "stateless" server receives a request, and sends > > > some response. It then forgets the transaction. The response is lost, but > > > thats OK. Because the client never got a 1xx, it resends the request. To the > > > stateless server, this is a brand new request, and it regenerates and > > > resends the > > > response. Voila - reliability. Any ACKs it gets would just be dropped. > > > > Any ACKs it gets would be dropped? If the stateless > > server has no concept of transactions that it previously > > responded to this wouldn't this in effect mean all ACKs > > get dropped. I think that might break the odd thing, like > > basic call setup for example. If you really, really > > wanted to do this sort of thing I would say you need to > > route on all ACKs and make sorting things out after your > > poor implementation somebody elses problem. Not at all to > > be recommended. If you want to send a response become > > stateful, after all the spec states in 12.3 that: > > > > "A stateless proxy forwards every request it receives > > downstream, and every response it receives upstream." > > > > 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 -- 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 Mon Sep 11 08:15: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 IAA00314 for ; Mon, 11 Sep 2000 08:15: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 F0FE34437B; Mon, 11 Sep 2000 07:13:17 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id A424444371 for ; Mon, 11 Sep 2000 07:12:54 -0400 (EDT) Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id NAA18605; Mon, 11 Sep 2000 13:10:42 +0100 (BST) Message-ID: <39BCCBC1.633655F0@ubiquity.net> Date: Mon, 11 Sep 2000 13:10:41 +0100 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: Anders Kristensen Cc: "'sip@lists.bell-labs.com'" Subject: Re: [SIP] Stateless Proxy References: <39BCBBD5.A0B0E01B@ubiquity.net> <39BCC6ED.FE578156@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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Hi Anders. Good to hear from you. Anders Kristensen wrote: > > Neil Deason wrote: > > > > Jonathan Rosenberg wrote: > > > > > > Actually, turns out that you can send a response and be stateless, but > > > ONLY if you don't send a provisional response first. > > > > > > Here's how it goes. The "stateless" server receives a request, and sends > > > some response. It then forgets the transaction. The response is lost, but > > > thats OK. Because the client never got a 1xx, it resends the request. To the > > > stateless server, this is a brand new request, and it regenerates and > > > resends the > > > response. Voila - reliability. Any ACKs it gets would just be dropped. > > > > Any ACKs it gets would be dropped? If the stateless > > server has no concept of transactions that it previously > > responded to this wouldn't this in effect mean all ACKs > > get dropped. > > Not necessarily. As long as the stateless server is able to recognize > that it has previously rejected the corresponding INVITE things should > work. This could be achieved in different ways, e.g. > > 1. by the same logic that caused the server to reject the INVITE in the > first place (e.g. on basis of the request url). So if the server knows > that it rejects all requests destined for sip:devnull@example.com, it > can safely throw away ACKs destined for that address. The same logic may not be applicable: A "stateless" server gets an INVITE which is illegaly formatted and responds 400 Bad Message. The ensuing ACK is a legal message. Or the Server gets an INVITE with a Max-Forwards containing zero and responds 404, the resulting ACK does not have Max-Forwards set. > 2. If the server inserted a Contact header identifying itself (allowed > for 3xx responses), the ACK should be destined for the stateless server > itself, and can be safely discarded. > > Basically, in this case state is not per-transaction, but per-server in > some implementation dependent way. The point is that it ends up behaving > as if it was transaction stateful. I agree it's not really > recommendable, though. Yeah, I think we are looking at ways to hack state into stateless operation when there is no justification. 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 Sep 11 08:57: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 IAA01254 for ; Mon, 11 Sep 2000 08:57: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 BB06544336; Mon, 11 Sep 2000 07:57:38 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from kevlar.softarmor.com (dwillis1.directlink.net [63.64.250.82]) by lists.bell-labs.com (Postfix) with ESMTP id 36B2544336 for ; Sun, 10 Sep 2000 14:14:06 -0400 (EDT) Received: from cowboys (IDENT:root@localhost [127.0.0.1]) by kevlar.softarmor.com (8.9.3/8.9.3) with SMTP id BAA25006; Mon, 11 Sep 2000 01:17:57 -0500 From: "Dean Willis" To: "IETF SIP" Cc: Date: Sun, 10 Sep 2000 15:11:04 -0400 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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: [SIP] Final Minutes of SIP WG, IETF 48 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 8bit The following are the final minutes of the SIP WG meetings at IETF 48. A better-formatted HTML version is available at: http://www.softarmor.com/sipwg/meets/IETF48/minutes/minutes.htm Minutes of SIP WG at IETF48 (Final) Edited by Dean Willis, 9/2/2000 Monday Session _____________ Agenda Bashing and Startup Scott Bradner reviewed IPR notice. Karen O'Donahue volunteered to take notes. Proposed agenda review, no discussion. Status of Working Group Efforts -- led by Jonathan Rosenberg Guidelines for Authors proceeding as expected. There was consensus to make it a BCP. No milestones set yet. The WG will continue to evolve the document with Jonathan Rosenberg acting as editor, and list suggestions and discussion are welcome. Caller Preferences proceeding, some discussion on removal, agreement to proceed to last call. Info draft in IESG review, publication expected (Note: Approved 8/21/2000) Reliability of Provisional Messages submitted to IESG on July 10. Supported/Server features in IESG agenda for consideration. Open List Issues -- Rosenberg -- Multiple transport parameters (Transports:). Could be a new parameter, or could be lisetd in the Contact: field with multiple Contact: headers. Discussion ensued, with both SRV (poor for negotiation) and SLP (possible for interdomain) mentioned. Henning summarized consensus that the number of transports is relatively small and the existing mechanism seems to work for now. How to handle OPTIONS and REGISTERS if max-forwards-0? Suggestion made that OPTIONS return 483, REGISTER be silently discarded. lennox objected to special behaviors for different methods. Henning asserted that max-forwards is really for debugging, and the handling isn't all that critical. Additional Detail on error Messages (Dave's Error Messages): Sparks suggest use of Refer (to, by) headers. Dave Oran prefers new failure-info header. Olson and others argues against overloading Contact. Henning argued need for explicit header. General consensus resulted on basic Dave mechanism with new explicit header. Dave Oran is expected to submit an Internet Draft on the discussed mechanism. Mandatory UDP: Some hot debate, no real conclusion. Lawrence Conroy argued need for a simple TCP-only system, and Jonathan Lennox noted that making UDP mandatory has security implications for systems that are trying to use TLS. If an implementation wishes to define policy such that TLS is required for security, but is required to support UDP due to this change in SIP, then we have a requirements conflict that has implications for security DTMF discussion was deferred to Session 2. Embedded Images: Much discussion on issues of size, direct vs. indirect embedding and relating content to messaging. Henning Schulzzrinne, Adam Roach, Sean Olson, and Scott Petrack made points. General consensus seemed to be to stay with 2543 approach and to prefer indirect reference where feasible. There seemed to be a consensus on use of standard MIME syntax, as this solves many of the discussion points. Case Sensitivity of URLS: (URI Comparison) general consensus for documented approach. Rohan Mahy suggested some sort of locally extended flexibility be considered, that in some application specific cases it might be necessary to use case-sensitive comparison. Session-Timer: Several changes reveiwed. Jonathan Lennox asked if it is legitmate for a Require: header to be inserted by a proxy. Multiple Outstanding Requests:Question: is it valid to have this situation? COMET and PRACK are examples where it is reasonable. Group consensus to allow it. Jonathan added the note that, for INVITE, only the most recent message matters as far as SDP is concerned. Christian Huitema warned that care must be taken in the maintenance of the state machine. Someone commented that in addressing the question, we should decide whether the intent is pipelining or asynchrony. General discussion followed, with no consensus recorded. Henning noted that the outcome must be as if requests had been received and processed in CSEQ order.   Context and Architecture for SIP-T -- Aparna Vemuri -- Purpose: feature transparency. Issues include: SIP MIME type negotiation - standard 415 (Ed: Huh?) Want to be able to tell a UAS to ignore certain MIME types. This clearly works for simple rejection. There are challenges when some of the body is mandatory, rest is optional. Presenter proposed use of content-disposition header. ISUP repetition problem: not all ISUP parameters are needed; many will contain information from origination side. The cleanup problem appears to be interesting -- Tom Taylor noted that there appears to be no "automatic solution".  Discussion of Content-Disposition: Lyndon Ong asked whether usage is mandatory. Jonathan Rosenberg responded that the current consensus is that this is optional, and reminded that SIP-T is in all respects SIP, not a separate protocol. Changes in DCS -- Bill Marshall -- All six drafts now in compliance with rfc2026. Manyfolks: The draft now includes discussion of case where UAS wants preconditions, but UAC didn't indicate support for it in the original INVITE. Privacy: 1) Needed to add proxy-require. 2) Removed authentication ?? sip security task force will handle. 3) OSPS removed. 4) Editorial changes to align with Guidelines. State: 1) Usage of Supported/Require added . 2 )Interaction with Hide. If Via headers hidden, then state headers need to be hidden -> resulting in Proxy-Require. 3) will change syntax to include port number. There appears to be an open issue in the interaction between Route/Record Route and end to end encryption. Call Authorization: only minor editorial changes Architectural Draft: Much larger in size than original, and now intended for publication on informational rather than standards track. Proxy-Proxy: 1) DCS Specific extensions tracing of obsence and harassing calls resource coordination for packetcable call transfer and three way calling. 2. OSPS, Billing-Info, Require and Proxy-Require used. 3) Next steps: * design complete, * maybe issues for inter-domain operation, * 4 documents for proposed. Consensus was achieved on adding four proposed drafts as wg items. Informational draft will be on hold until proposed documents are complete. This document will provide the basis for IANA registration of Require: DCS. Brief discussion of which of the DCS items would be WG work items. Comment that the SDP in draft-manyfolks-... might be an MMUSIC work item. An AD (Scott bradner) agreed to leave it with SIP. There was consenus to accept draft-manyfolks-, privacy, state, and call authorization as WG work items. Update on rfc2543bis -- Henning Schulzrinne -- Nothing that is not almost completely backwards compatible. Not SIP/2.1 -- this is a clarification, is more indicative of the current state of the art than is RFC2543, and implementors are urged by the author to track this draft. Lots of clarifications:  * ACK Forwarding * consistencies between tables and texts * e-e vs. h-h distinction has been deprecated, different table which describes what proxies are allowed to do * headers tentatively added (Call-Info, Reply-To) * separate call and transaction state machines * cancel/invite are separable (will need to add note on need for timer in cancel, since you may not get a 487) * clearer distinction between loops and spirals in discussion of loop detection * There has been discussion of possibly "splitting the spec in half" -- into framework and methods drafts, possibly to help with the IMPP implementations that may not need all of the SIP methods. * Some features need to be removed as too immature to advance to Draft Standard, notably Via hiding and use of PGP. MIB Draft -- Dave Walker Partition of MIB: SIP common, UA, Server (proxy and redirect), Registrar Support modules: Added support for multiple instances in the same system and notification throttling Discussion included whether to have security objects, and questions with respect to the transaction table. Wednesday Session _______________ Message Waiting Indicator -- Rohan Mahy -- Several issues were raised in discussion: 1) Should compare and contrast with HTTP and poll models such as POP and with SNMP, asnwer "why these are not suitable and SIP-MWI is". 2) A MWI is really just a presence information bit, it might be more appropriate to just use the presence mechanisms, 3) the alerting mechanism should be designed generically rather than specifically as a voice-mail function. SIP-H.323 requirements -- Radhika Roy -- Point made -- this interworking is for basic call, not extra signaling like Q.SIG. Also, IETF work should not address purely operational issues. Call Flows -- Johnston -- Several changes and corrections have been made.Multiproxy and transfer additions needed. Caveat: this is not a complete debug list, we probably need to do some more work in that respect. OSP Token -- Johnston and Thomas -- consensus was to include it as a header question: can you include a reference to the token instead of the actual token? Note: Proxies may read or insert but not modify tokens. question: maybe recommend tcp since the tokens are large DTMF -- Skip Cave and Bert Culpepper -- Skip proposes that there are two problems - dtmf transport, readily covered by RTP, and key input, which is a different problem. This is supported by a historical analysis of the deployment of DTMF applications. Discussion centered on solving the user input problem. Donovan proposed using SUBSCRIBE/NOTIFY mechanisms to establish a signaling relationship for user input. Question: do app servers need access to the RTP stream? No conclusion, Lawrence Conroy noted some concern with signbal loading in mobile applications, and specif concern with SIP re -INVITES. Emergency Services -- Henning Schulzrinne -- Discussion centered on the applicability of SLP, with some contention.. Brian Rosen's note indicate that there was a consensus indicating that SLP should be usable. Issues, however, extend beyond SIP -- for example, emergency services for Web users? Appliance Framework -- Stan Moyer -- No discussion allowed by chairs due to time constraints. AAA Requirements -- Calhoun, etc. -- Comments:Must take into account discussions in the AAA group. Problem space must include use of services other than Internet Access logon. The authors mentioned that other users of SIP are keen to use the output of the IETF AAA WG, namely DIAMETER or whatever DIAMETER becomes after the AAA WG is done with it. 3GPP and 3GPP2 have selected DIAMETER as their AAA protocol, and that MWIF is leaning in that direction. AAA WG has requested that SIP requirements be brought forth, and absent any such have not included SIP within scope. We need to have discussions of the appropriate requirements on the SIP mailing list. 3rd Party Call Control with SDP preconditions -- Gonzalo Camarillo No comments, two open issues will be taken to the list. Composite Capabilities and Preference Profiles (CC/PP) exchange -- Iizuka -- Comments: This draft proposes extending CC/PPex, proposed by W3C to allow certain push services to know in advance the capabilities and preferences of certain endpoints. Several participants in the discussion feel that this is similar to or perhaps overlaps the caller preferences problem. (Ed: actually, it's the flip side of the same problem -- one might call it "callED preferences"). Many present felt that SIP may not be the right answer to this question -- or maybe we haven't asked the right question yet. Other possibilites include SLP, CONNEG, and other capability negotiation frameworks. Christian Huitema remarked that this approach raises the question of whether the Guidelines draft should include a direction to authors with respect to the need for atomicity in extensions.. TIPHON work on SIP -- Paul Sijben -- No discussion due to time SIP Firewall Policy mechanisms -- Jon Peterson -- No discussion due to time Call Control and Transfer -- Robert Sparks -- Refer is not just for INVITES anymore. The Refer header has apparent utility when used within messages defined by other SIP methods. Also, generalizing method to point to an arbitrary URL has interesting implications, given the parameterization of SIP state information such as Call-ID possible in a URL. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Sep 11 10: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 KAA02947 for ; Mon, 11 Sep 2000 10: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 7807044368; Mon, 11 Sep 2000 09:11:40 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from blanc.cisco.com (blanc.cisco.com [161.44.3.203]) by lists.bell-labs.com (Postfix) with ESMTP id F418A4435A for ; Mon, 11 Sep 2000 09:11:36 -0400 (EDT) Received: (ddaiker@localhost) by blanc.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) id KAA22409; Mon, 11 Sep 2000 10:11:13 -0400 (EDT) From: David Daiker Message-Id: <200009111411.KAA22409@blanc.cisco.com> Subject: Re: [SIP] Stateless Proxy To: ndeason@ubiquity.net (Neil Deason) Date: Mon, 11 Sep 2000 10:11:13 -0400 (EDT) Cc: jdrosen@dynamicsoft.com (Jonathan Rosenberg), ddaiker@cisco.com ('David Daiker'), gethin@ubiquity.net ('gethin@ubiquity.net'), Joe.Pizzimenti@wcom.com ('Joe.Pizzimenti@wcom.com'), albee@miel.mot.com ('albee@miel.mot.com'), sip@lists.bell-labs.com ('sip@lists.bell-labs.com') In-Reply-To: <39BCBBD5.A0B0E01B@ubiquity.net> from "Neil Deason" at Sep 11, 2000 12:02:45 PM 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Neil, a couple more ways of accomplishing this statelessly when the stateless proxy creates the 'To:' tag in the final response, it includes its own id that it recognizes in the ACK, alternatively, if the server is configured to always redirect INVITEs, because it fronts a registrar or other location service, it could drop all ACKs without causing problems. david > Jonathan Rosenberg wrote: > > > > Actually, turns out that you can send a response and be stateless, but > > ONLY if you don't send a provisional response first. > > > > Here's how it goes. The "stateless" server receives a request, and sends > > some response. It then forgets the transaction. The response is lost, but > > thats OK. Because the client never got a 1xx, it resends the request. To the > > stateless server, this is a brand new request, and it regenerates and > > resends the > > response. Voila - reliability. Any ACKs it gets would just be dropped. > > Any ACKs it gets would be dropped? If the stateless > server has no concept of transactions that it previously > responded to this wouldn't this in effect mean all ACKs > get dropped. I think that might break the odd thing, like > basic call setup for example. If you really, really > wanted to do this sort of thing I would say you need to > route on all ACKs and make sorting things out after your > poor implementation somebody elses problem. Not at all to > be recommended. If you want to send a response become > stateful, after all the spec states in 12.3 that: > > "A stateless proxy forwards every request it receives > downstream, and every response it receives upstream." > > 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 Sep 11 10:26: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 KAA03393 for ; Mon, 11 Sep 2000 10:26: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 0663E4436E; Mon, 11 Sep 2000 09:26:51 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id 46A744435A for ; Mon, 11 Sep 2000 09:26:45 -0400 (EDT) Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id PAA13962; Mon, 11 Sep 2000 15:24:27 +0100 (BST) Message-ID: <39BCEB1A.6D89E3B@ubiquity.net> Date: Mon, 11 Sep 2000 15:24:26 +0100 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: David Daiker Cc: Jonathan Rosenberg , "'gethin@ubiquity.net'" , "'Joe.Pizzimenti@wcom.com'" , "'albee@miel.mot.com'" , "'sip@lists.bell-labs.com'" Subject: Re: [SIP] Stateless Proxy References: <200009111411.KAA22409@blanc.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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit David Daiker wrote: > > Neil, > > a couple more ways of accomplishing this statelessly > > when the stateless proxy creates the 'To:' tag in the final response, > it includes its own id that it recognizes in the ACK, In a re-INVITE case you couldn't do this because a tag would already exist in the To: header. > alternatively, if the server is configured to always redirect INVITEs, > because it fronts a registrar or other location service, > it could drop all ACKs without causing problems. Or you could just be sensible and use a Redirect Server. I see no good reason for wanting to do an ugly hack like this. 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 Sep 11 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 KAA04061 for ; Mon, 11 Sep 2000 10:57: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 EF34F44378; Mon, 11 Sep 2000 09:56:23 -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 E45CD4435A for ; Mon, 11 Sep 2000 09:56:19 -0400 (EDT) Received: from antd.nist.gov (IDENT:mranga@herbivore.ncsl.nist.gov [129.6.55.182]) by is1-55.antd.nist.gov (8.9.3/8.9.3) with ESMTP id KAA21799 for ; Mon, 11 Sep 2000 10:52:05 -0400 (EDT) Message-ID: <39BCF347.CF0FDF5D@antd.nist.gov> Date: Mon, 11 Sep 2000 10:59:20 -0400 From: "M.Ranganathan" Reply-To: mranga@nist.gov Organization: NIST X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 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] How to compare hosts for equality? Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Hello! I have another newbie question. I hope I have not missed the obvious in the SIP document. There are a few SIP headers where either a host name or an address is allowed. When needs to determine whether they are referring to the same host, does one have to do a DNS lookup if the host name and not the address is specified in the request header? If so, a DNS lookup can return more than one address per host name so which one shall I pick? If it is the responsibility of the client to ensure consistency (i.e. always use either name or address so the server does not have to do name lookups) then that makes life easier. I appreciate your help in resolving my questions and thank you in advance for your replies., Ranga. --- M.Ranganathan NIST Advanced Networking Technologies Group National Institute of Standards and Technology 100 Bureau Drive, Mail Stop 8920 Gaithersburg , MD 20899 Tel: 301 975 3664 Fax 301 590 0932 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Sep 11 11:07: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 LAA04379 for ; Mon, 11 Sep 2000 11:07: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 2BE2A44346; Mon, 11 Sep 2000 10:07:15 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from blanc.cisco.com (blanc.cisco.com [161.44.3.203]) by lists.bell-labs.com (Postfix) with ESMTP id 0A4BE4433B for ; Mon, 11 Sep 2000 10:07:12 -0400 (EDT) Received: (ddaiker@localhost) by blanc.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) id LAA24657; Mon, 11 Sep 2000 11:06:50 -0400 (EDT) From: David Daiker Message-Id: <200009111506.LAA24657@blanc.cisco.com> Subject: Re: [SIP] Stateless Proxy To: ndeason@ubiquity.net (Neil Deason) Date: Mon, 11 Sep 2000 11:06:49 -0400 (EDT) Cc: ddaiker@cisco.com (David Daiker), jdrosen@dynamicsoft.com (Jonathan Rosenberg), gethin@ubiquity.net ('gethin@ubiquity.net'), Joe.Pizzimenti@wcom.com ('Joe.Pizzimenti@wcom.com'), albee@miel.mot.com ('albee@miel.mot.com'), sip@lists.bell-labs.com ('sip@lists.bell-labs.com') In-Reply-To: <39BCEB1A.6D89E3B@ubiquity.net> from "Neil Deason" at Sep 11, 2000 03:24:26 PM 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit > > David Daiker wrote: > > > > Neil, > > > > a couple more ways of accomplishing this statelessly > > > > when the stateless proxy creates the 'To:' tag in the final response, > > it includes its own id that it recognizes in the ACK, > > In a re-INVITE case you couldn't do this because a tag > would already exist in the To: header. I think sending a spurious ACK into the network is preferable to repeatedly dropping the original request > > alternatively, if the server is configured to always redirect INVITEs, > > because it fronts a registrar or other location service, > > it could drop all ACKs without causing problems. > > Or you could just be sensible and use a Redirect Server. > I see no good reason for wanting to do an ugly hack like > this. yeah, that's what I'm saying, a stateless redirect server, I thought someone was asserting it wasn't possible, it is, imo, nothing ugly about it. david _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Sep 11 11:26: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 LAA04792 for ; Mon, 11 Sep 2000 11:26: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 7CA0B4436D; Mon, 11 Sep 2000 10:26:42 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id 72F824433B for ; Mon, 11 Sep 2000 10:26:37 -0400 (EDT) Received: from gethin by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id QAA07986; Mon, 11 Sep 2000 16:24:33 +0100 (BST) From: Gethin Liddell Organization: Ubiquity Software Corp. To: mranga@nist.gov, "M.Ranganathan" , sip@lists.bell-labs.com Subject: Re: [SIP] How to compare hosts for equality? Date: Mon, 11 Sep 2000 16:15:53 +0100 X-Mailer: KMail [version 1.0.29.2] Content-Type: text/plain References: <39BCF347.CF0FDF5D@antd.nist.gov> In-Reply-To: <39BCF347.CF0FDF5D@antd.nist.gov> MIME-Version: 1.0 Message-Id: <00091116174300.21159@gethin> Content-Transfer-Encoding: 8bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 8bit On Mon, 11 Sep 2000, M.Ranganathan wrote: > Hello! > > I have another newbie question. I hope I have not missed the obvious in > the SIP document. look at section 2.1 SIP URL comparison. that describes how to equate host name within the sip url and the same can be applied for any host. -- 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 Mon Sep 11 11:37:29 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA05103 for ; Mon, 11 Sep 2000 11:37: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 5D0F64437D; Mon, 11 Sep 2000 10:37:09 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from bounty.cisco.com (bounty.cisco.com [161.44.3.204]) by lists.bell-labs.com (Postfix) with ESMTP id 47E1444355 for ; Mon, 11 Sep 2000 10:37:06 -0400 (EDT) Received: from cisco.com (rtp-xdm1.cisco.com [161.44.3.80]) by bounty.cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id LAA20628; Mon, 11 Sep 2000 11:36:47 -0400 (EDT) Message-ID: <39BCFBF9.D8357DE4@cisco.com> Date: Mon, 11 Sep 2000 11:36:25 -0400 From: Shail Bhatnagar X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Neil Deason Cc: "'sip@lists.bell-labs.com'" Subject: Re: [SIP] Stateless Proxy References: <200009111411.KAA22409@blanc.cisco.com> <39BCEB1A.6D89E3B@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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit I tend to think that the new bis version almost implies that : 1) An ACK without Route header is for the proxy and should be dropped. (Stop response retx timer in stateful mode) 2) An ACK with Route header needs to be forwarded based on Route header. Of course, to be sure about #1, stateful behavior helps. Shail Neil Deason wrote: > > David Daiker wrote: > > > > Neil, > > > > a couple more ways of accomplishing this statelessly > > > > when the stateless proxy creates the 'To:' tag in the final response, > > it includes its own id that it recognizes in the ACK, > > In a re-INVITE case you couldn't do this because a tag > would already exist in the To: header. > > > alternatively, if the server is configured to always redirect INVITEs, > > because it fronts a registrar or other location service, > > it could drop all ACKs without causing problems. > > Or you could just be sensible and use a Redirect Server. > I see no good reason for wanting to do an ugly hack like > this. > > 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 -- Best regards, Shail _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Sep 11 12:07: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 MAA05703 for ; Mon, 11 Sep 2000 12: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 2806A44342; Mon, 11 Sep 2000 11:07:07 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id 7011E4433B for ; Mon, 11 Sep 2000 11:07:02 -0400 (EDT) Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id RAA20467; Mon, 11 Sep 2000 17:05:07 +0100 (BST) Message-ID: <39BD02B3.D32C539B@ubiquity.net> Date: Mon, 11 Sep 2000 17:05:07 +0100 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: Shail Bhatnagar Cc: "'sip@lists.bell-labs.com'" Subject: Re: [SIP] Stateless Proxy References: <200009111411.KAA22409@blanc.cisco.com> <39BCEB1A.6D89E3B@ubiquity.net> <39BCFBF9.D8357DE4@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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Shail Bhatnagar wrote: > > I tend to think that the new bis version almost implies that : > > 1) An ACK without Route header is for the proxy and should be dropped. > (Stop response retx timer in stateful mode) What changes are you thinking of? I thought that a UAS MUST add a Contact to a 2xx reponse for INVITE but it is only a MAY as to whether the UAC sends the ACK directly there. Therefore an ACK without a Route may still need to be sent on by a proxy. Cheers, Neil. -- Ubiquity Software Corporation, UK http://www.ubiquity.net > 2) An ACK with Route header needs to be forwarded based on Route > header. > > Of course, to be sure about #1, stateful behavior helps. > > Shail _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Sep 11 13:17: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 NAA06725 for ; Mon, 11 Sep 2000 13:17: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 3BE7244356; Mon, 11 Sep 2000 12:16:49 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from md3.vsnl.net.in (md3.vsnl.net.in [202.54.6.35]) by lists.bell-labs.com (Postfix) with ESMTP id 687494433B for ; Mon, 11 Sep 2000 12:16:43 -0400 (EDT) Received: from jana ([203.197.129.84]) by md3.vsnl.net.in (8.9.3/8.9.3) with SMTP id WAA04801 for ; Mon, 11 Sep 2000 22:41:17 +0530 (IST) Message-ID: <00bf01c01c13$d6ed34c0$38c9a8c0@labs> From: "Pathangi N Janardhanan" To: Date: Mon, 11 Sep 2000 22:45:08 +0530 Organization: HCL Technologies India Ltd. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Subject: [SIP] A doubt on registeration ? Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Hi, The following is from the BIS draft: "If the registration is changed while a user agent or proxy server processes an invitation, the new information SHOULD be used. This allows a service known as "directed pick-up". " A proxy server has already queried the location server and has progressed the call. After this if the user hearing his phone ringing, sent a new REGISTER request, how would this be indicated to the proxy? Is this through some implementation dependent interface between the location server and the proxy? Thanks Jana ----- Pathangi N Janardhanan HCL Technologies Ltd., D-12 & 12-B, 3rd South Street, SIDCO Industrial Estate, Ambattur Chennai - 600 058 India Phone Off : + 91 44 6230711/6230712 ext. 2535 Phone Res: +91 44 3743690 Fax : +91 44 6244213 e-mail : janar@netlab.hcltech.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 Sep 11 21:53: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 VAA11603 for ; Mon, 11 Sep 2000 21:53: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 603064434C; Mon, 11 Sep 2000 20:53:42 -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 2DB104433B for ; Mon, 11 Sep 2000 20:53: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 VAA10475; Mon, 11 Sep 2000 21:55:26 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Mon, 11 Sep 2000 21:50:38 -0400 Message-ID: From: Jonathan Rosenberg To: "'Blanchard Jacqueline'" , "'sip@lists.bell-labs.com'" Subject: RE: [SIP] Keep-Alive mechanism : REGISTER Date: Mon, 11 Sep 2000 21:50:28 -0400 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com > -----Original Message----- > From: Blanchard Jacqueline > [mailto:Jacqueline.Blanchard@SRIT.siemens.fr] > Sent: Monday, September 11, 2000 7:37 AM > To: 'sip@lists.bell-labs.com' > Subject: [SIP] Keep-Alive mechanism : REGISTER > > > > Hi, > > What is the keepalive mechanism I should use between a > User Agent and > a Proxy, just to know in my proxy that the User Agent > is still there and has > not logoff. > Do I need to send periodic REGISTER ? Yes. -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 Sep 12 04:23: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 EAA27540 for ; Tue, 12 Sep 2000 04:23: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 826BD44363; Tue, 12 Sep 2000 03:22:49 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id D2FFA4433B for ; Tue, 12 Sep 2000 03:22:45 -0400 (EDT) Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id JAA15413; Tue, 12 Sep 2000 09:20:39 +0100 (BST) From: "Jo Hornsby" To: "Pathangi N Janardhanan" , Subject: RE: [SIP] A doubt on registeration ? Date: Tue, 12 Sep 2000 09:20:38 +0100 Message-ID: <001001c01c92$55733370$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: <00bf01c01c13$d6ed34c0$38c9a8c0@labs> Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit > "If the registration is changed while a user agent or proxy > server processes an invitation, the new information SHOULD > be used. > > This allows a service known as "directed pick-up". " > > A proxy server has already queried the location server and > has progressed the call. After this if the user hearing his > phone ringing, sent a new REGISTER request, how would > this be indicated to the proxy? Is this through some > implementation dependent interface between the location server > and the proxy? Yes. Note that the interface to a Location Server is not well specified in any case (look to the definition of "Location Service" in Section 1.3 ("Definitions")). 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 Tue Sep 12 07: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 HAA29749 for ; Tue, 12 Sep 2000 07: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 4ABB24433E; Tue, 12 Sep 2000 06:24:48 -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 EB17C4433B for ; Mon, 11 Sep 2000 19:24:20 -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 RAA13063 for ; Mon, 11 Sep 2000 17:25:41 -0700 Message-ID: <39BD7805.846A6012@mobilerain.com> Date: Mon, 11 Sep 2000 17:25:41 -0700 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: IETF SIP Subject: [SIP] Content Length Question References: Content-Type: multipart/mixed; boundary="------------EE9F510F46FDEE8324080ADB" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com This is a multi-part message in MIME format. --------------EE9F510F46FDEE8324080ADB Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Greetings: I tried the FAQ but could not find answers to my questions: a. Where is the grammar for: Content-Length: ... <-- note the three "." defined? I tried the [draft-ietf-sip-rfc2543bis-02] but could not find the entry. b. What is the exact meaning when 3 periods appear as Content-Length? I tried checking the HTTP 1.1 spec as well but could not find the reference. Information on the above is appreciated. Regards, Bobby.Sardana@mobilerain.com --------------EE9F510F46FDEE8324080ADB 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 --------------EE9F510F46FDEE8324080ADB-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Sep 12 08:17: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 IAA01309 for ; Tue, 12 Sep 2000 08:17: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 5F40A44358; Tue, 12 Sep 2000 07:17:38 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from roma.axis.se (roma.axis.se [193.13.178.2]) by lists.bell-labs.com (Postfix) with ESMTP id 7CDF44435B for ; Tue, 12 Sep 2000 06:45:03 -0400 (EDT) Received: from klatt.axis.se (klatt.axis.se [193.13.178.133]) by roma.axis.se (8.9.3/8.9.3) with ESMTP id NAA29256; Tue, 12 Sep 2000 13:43:40 +0200 (MEST) Received: by klatt.axis.se with Internet Mail Service (5.5.2650.21) id ; Tue, 12 Sep 2000 13:43:38 +0200 Message-ID: <151F3D2AE9F0D3119E480004ACB8EA370186917A@cluster01.axis.se> From: Peter Kjellerstedt To: "'Bobby Sardana'" Cc: IETF SIP Subject: RE: [SIP] Content Length Question Date: Tue, 12 Sep 2000 13:43:59 +0200 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com > -----Original Message----- > From: Bobby Sardana [mailto:bobby.sardana@mobilerain.com] > Sent: 12 September 2000 02:26 > To: IETF SIP > Subject: [SIP] Content Length Question > > Greetings: > > I tried the FAQ but could not find answers to my questions: > > a. Where is the grammar for: > Content-Length: ... <-- note the three "." defined? > I tried the > [draft-ietf-sip-rfc2543bis-02] but could not find the entry. > > b. What is the exact meaning when 3 periods appear as > Content-Length? I tried > checking the HTTP 1.1 spec as well but could not find the reference. > > Information on the above is appreciated. > > Regards, > > Bobby.Sardana@mobilerain.com I suppose this is taken from one of the examples of SIP messages. In that case it is not real SIP-syntax, but rather used to mark that "here should be the length of the content, but we did not calculate it for the example". Hope this was the information you were looking for, //Peter _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Sep 12 08:25: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 IAA01512 for ; Tue, 12 Sep 2000 08:25: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 86FF444376; Tue, 12 Sep 2000 07:25:09 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id A6FEA4436B for ; Tue, 12 Sep 2000 07:25:01 -0400 (EDT) Received: from gethin by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id NAA11762; Tue, 12 Sep 2000 13:21:59 +0100 (BST) From: Gethin Liddell Organization: Ubiquity Software Corp. To: Peter Kjellerstedt , "'Bobby Sardana'" Subject: RE: [SIP] Content Length Question Date: Tue, 12 Sep 2000 13:11:53 +0100 X-Mailer: KMail [version 1.0.29.2] Content-Type: text/plain Cc: IETF SIP References: <151F3D2AE9F0D3119E480004ACB8EA370186917A@cluster01.axis.se> In-Reply-To: <151F3D2AE9F0D3119E480004ACB8EA370186917A@cluster01.axis.se> MIME-Version: 1.0 Message-Id: <00091213150200.25096@gethin> Content-Transfer-Encoding: 8bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 8bit On Tue, 12 Sep 2000, Peter Kjellerstedt wrote: > > > > I tried the FAQ but could not find answers to my questions: > > > > a. Where is the grammar for: > > Content-Length: ... <-- note the three "." defined? > > I tried the > > [draft-ietf-sip-rfc2543bis-02] but could not find the entry. did you try section 6.18: Content-Length ? > > > > b. What is the exact meaning when 3 periods appear as > > Content-Length? I tried > > checking the HTTP 1.1 spec as well but could not find the reference. just means that content length meaning is obvious and you should assume the correct content-length is present in a real message.l saves henning from counting the number of characters in the payload just to put in the call flows. -- 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 Tue Sep 12 09:27: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 JAA02860 for ; Tue, 12 Sep 2000 09:27: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 099804436F; Tue, 12 Sep 2000 08:26:43 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mailctr.marben.fr (mailctr.marben.fr [193.105.113.5]) by lists.bell-labs.com (Postfix) with ESMTP id 0E7B044350 for ; Tue, 12 Sep 2000 08:06:38 -0400 (EDT) Received: from copernic.marben.fr by mailctr.marben.fr with ESMTP (8.9.3/1.2-eef) id OAA20564; Tue, 12 Sep 2000 14:06:44 GMT Received: from pipo by copernic.marben.fr with SMTP (8.9.3/1.2-eef) id NAA19131; Tue, 12 Sep 2000 13:03:41 GMT Message-ID: <001c01c01cba$4445e520$5a040237@it.atosgroup.com> From: =?iso-8859-1?Q?G=E9rard_GONNET?= To: Cc: , "SEVESTRE Thibaut" Date: Tue, 12 Sep 2000 15:06:29 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0019_01C01CCB.077AC8C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Subject: [SIP] SIP syntax in 2543-bis-01 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com This is a multi-part message in MIME format. ------=_NextPart_000_0019_01C01CCB.077AC8C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The syntax in the draft 2543bis-01, page 18, resulting from a = modification of the former release, can produce some ambiguous = interpretation. This concern the element, described as : . (was described in the former release as , notice that the element is not optional). From the C appendix, "Summary of Augmented BNF" page 116 of the = reference draft, specifying "Square brakets enclose optional elements; = "[foo bar]" is equivalent to "*1(foo bar)",we deduce that the = element is constituted with : - a first optional element, whose content (when present) is a or = a . - a second optional element, whose content (when present) is <":"> = followed by a . This rule makes possible to reduce the content of a to a = <":" password> element only, thanks to the declaration of the = element as optional... (ok, the semantic seems strange, but we are = "parsing" the syntax). Using the SIP-URL description of the SIP-URL syntax : , we can produce a SIP-URL element looking like this : , which seems to be erroneous. To avoid such situation, I would suggest to describe the = element with the following syntax : . This syntax describes now the element as formed with a = mandatory or child element, optionaly = followed by a <":" password> element. Introducing this rule into the SIP-URL syntax produces : the = element (optional), if present in the , must be constituted = with at least a or a child element, = optionaly followed by a <":" password> element, followed with "@" fixed = element, wich seems to be a non ambiguous syntax. ------=_NextPart_000_0019_01C01CCB.077AC8C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
The <SIP-URL> syntax in = the draft=20 2543bis-01, page 18, resulting from a modification of the former=20 release, can produce some ambiguous interpretation.
This concern the = <userinfo>=20 element, described as :
<user-info =3D [user | = telephone-subscriber]=20 [":" password]>.
(was described in the former = release=20 as <user-info =3D user [":" password]>, notice that = the=20 <user> element is not optional).
From the C appendix, "Summary of = Augmented BNF"=20 page 116 of the reference draft, specifying "Square brakets = enclose=20 optional elements; "[foo bar]" is equivalent to "*1(foo bar)",we = deduce=20 that the <user-info> element is constituted = with=20 :
- a first optional element, = whose content=20 (when present) is a <user> or a=20 <telephone-subscriber>.
- a second optional element, whose=20 content (when present) is <":"> followed by a=20 <password>.
This rule makes possible to reduce = the content=20 of a <user-info> to a <":" password> = element=20 only, thanks to the declaration of the <user> = element as=20 optional... (ok, the semantic seems strange, but we = are "parsing" the=20 syntax).
Using the SIP-URL description of the = SIP-URL syntax=20 :
<SIP-URL =3D "sip:"[userinfo = "@"] hostport=20 url-parameters [headers]>,
we can produce a SIP-URL = element=20 looking like this :
<sip::a_password@hostport = url-parameters=20 [headers]>,
which seems to be = erroneous.
To avoid such situation, I would = suggest to=20 describe the <user-info> element with the following = syntax=20 :
<user-info =3D (user |=20 telephone-subscriber) [":" password]>.
This = syntax describes=20 now the <user-info> element as formed with a = mandatory=20 <user> or <telephone-subscriber> child = element,=20 optionaly followed by a <":" password>=20 element.
Introducing = this rule into=20 the SIP-URL syntax produces : the <user-info> = element=20 (optional), if present in the <SIP-URL>, must be = constituted=20 with at least a <user> or a = <telephone-subscriber>=20 child element, optionaly followed by a <":" password>=20 element, followed with "@" fixed element, wich seems to be = a non=20 ambiguous syntax.
------=_NextPart_000_0019_01C01CCB.077AC8C0-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Sep 12 09:29: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 JAA02905 for ; Tue, 12 Sep 2000 09:29: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 753CB4435B; Tue, 12 Sep 2000 08:27:19 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id A411144350 for ; Tue, 12 Sep 2000 08:07:14 -0400 (EDT) Received: from phoffer by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id OAA26222; Tue, 12 Sep 2000 14:05:24 +0100 (BST) Message-ID: <00ff01c01cba$1b218410$5334c3c1@ubiquity.co.uk> From: "Phil Hoffer" To: Subject: Re: [SIP] Final Minutes of SIP WG, IETF 48 Date: Tue, 12 Sep 2000 14:05:20 +0100 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Dean Willis wrote : The following are the final minutes of the SIP WG meetings at IETF 48. > Lots of clarifications: > * Some features need to be removed as too immature to advance to Draft > Standard, notably Via hiding and use of PGP. Hi, Is it possible to clarify which aspects of the use of PGP within SIP are likely to be removed? a) PGP for Authentication b) PGP for Encryption c) both Thanks In Advance Phil Hoffer 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 Sep 12 14:46: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 OAA11883 for ; Tue, 12 Sep 2000 14:46: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 287704437A; Tue, 12 Sep 2000 13:44:35 -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 765E74433D for ; Tue, 12 Sep 2000 13:44:31 -0400 (EDT) Received: from dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id OAA15701 for ; Tue, 12 Sep 2000 14:46:13 -0400 (EDT) Message-ID: <39BE79A5.BF57C58@dynamicsoft.com> Date: Tue, 12 Sep 2000 14:44:53 -0400 From: Igor Slepchin Organization: dynamicsoft Inc. X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en,ru MIME-Version: 1.0 To: sip@lists.bell-labs.com Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Subject: [SIP] DNS SRV records in stateless mode Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit The 2543bis draft is silent about using SRV records in stateless mode and I think the subject may be worth some discussion. As far as I can tell, the best approach seems to be to just use the highest priority SRV records for the protocols supported that doesn't result in the immediate failure. That is, if the first SRV record turns out to be for TCP and the connection to the specified host fails, the next SRV record should be tried. However, ICMP errors cannot be detected in stateless mode so the search automatically stops on the first UDP record (recycling connected UDP socket across requests would help detecting ICMP errors). Note that using the standard algorithm described in 1.4.2 and RFC2782 in stateless mode is problematic since this will likely result in retransmissions of the request to be sent to different next hops. This is certainly undesirable even though probably not catastrophic since all such requests are likely to be eventually forwarded to the downstream proxy or UA so the retransmissions will be detected as merged requests there. Another possible approach is to use only A records in stateless mode. However, I don't think this has any advantages over the first approach described; besides, some domains may not even have a SIP server at the address listen in the A record. Any comments? --- 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 Sep 13 00:01: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 AAA19093 for ; Wed, 13 Sep 2000 00:01: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 6030E44380; Tue, 12 Sep 2000 23:01:34 -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 2B64744370 for ; Tue, 12 Sep 2000 23:01:31 -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 XAA19174; Tue, 12 Sep 2000 23:59:30 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Tue, 12 Sep 2000 23:54:40 -0400 Message-ID: From: Jonathan Rosenberg To: "'Neil Deason'" , "'Shail Bhatnagar'" Cc: "'sip@lists.bell-labs.com'" Subject: RE: [SIP] Stateless Proxy Date: Tue, 12 Sep 2000 23:54:39 -0400 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Neil wrote: > Shail Bhatnagar wrote: > > > > I tend to think that the new bis version almost implies that : > > > > 1) An ACK without Route header is for the proxy and should > be dropped. > > (Stop response retx timer in stateful mode) > > What changes are you thinking of? I thought that a UAS MUST > add a Contact to a 2xx reponse for INVITE but it is only a > MAY as to whether the UAC sends the ACK directly there. > Therefore an ACK without a Route may still need to be > sent on by a proxy. Thats not my understanding, nor my reading of the bis draft. Section 6.13 says: >INVITE and OPTIONS 2xx responses: A user agent server sending a definitive, positive >response (2xx) MUST insert a Contact response header field indicating the SIP address under >which it is reachable most directly for future SIP requests, such as ACK, within the same >Call-ID.TheContact header field contains the address of the server itself or that of a > proxy, e.g., if the host is behind a firewall.The value of this Contact header is copied > into the Request-URI of subsequent requests for this call if the response did not also > contain a Record-Route header. If the response also contains a Record-Route >header field, the address in the Contact header field is added as the last item in the > Route header field. See Section 6.34 for details. and then later, section 6.34.2 says: > Once a proxy P inserts a Record-Route header in a request from UA A to UA B , all > subsequent requests from A to B and from B to A visit P . Thus, although no explicit strength is assigned, it was my understanding that text of the form "the proxy inserts X" or "the UA copies A to B" was effectively MUST. Hisham wrote: >The question here is what would a stateless proxy do when it recieves a request >with the host part of the request-uri indicating its domain? Forwarding the >request will cause loops. No. Lets not forget that routing is one of the primary jobs of a proxy, and that said routing can be accomplished in many ways. Consider, for example, a very large enterprise network, example.com. All calls for example.com get routed to a proxy server farm. This farm has a bunch of servers that look at the incoming request URI; assuming it matches their domain (example.com), they look up the R-URI in a corporate database, and determine the department handling that user. They then forward the request there. These proxies are ideal candidates for stateless. Note, however, that they DO operate in a mode where their domain matches the domain in the request URI. I also see no reason why if a registration results in a single contact, the proxy cannot then assume a stateless role when it proxies. Remember - these roles are LOGICAL, and the decision on which to be can be made at a late point in the processing of the transaction. As such, a proxy could decide to be stateful only if the registration returns multiple contacts, stateless otherwise. -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 Sep 13 04:36: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 EAA03178 for ; Wed, 13 Sep 2000 04:36: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 62D2844383; Wed, 13 Sep 2000 03:36:19 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id 48B2F44370 for ; Wed, 13 Sep 2000 03:36:15 -0400 (EDT) Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id JAA29869; Wed, 13 Sep 2000 09:34:23 +0100 (BST) Message-ID: <39BF3C10.122D5126@ubiquity.net> Date: Wed, 13 Sep 2000 09:34:25 +0100 From: James Undery X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Igor Slepchin Cc: sip@lists.bell-labs.com Subject: Re: [SIP] DNS SRV records in stateless mode References: <39BE79A5.BF57C58@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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Igor Slepchin wrote: > The 2543bis draft is silent about using SRV records in stateless mode > and I think the subject may be worth some discussion. > > As far as I can tell, the best approach seems to be to just use the > highest priority SRV records for the protocols supported that doesn't > result in the immediate failure. That is, if the first SRV record turns > out to be for TCP and the connection to the specified host fails, the > next SRV record should be tried. However, ICMP errors cannot be detected > in stateless mode so the search automatically stops on the first UDP > record (recycling connected UDP socket across requests would help > detecting ICMP errors). > > Note that using the standard algorithm described in 1.4.2 and RFC2782 in > stateless mode is problematic since this will likely result in > retransmissions of the request to be sent to different next hops. This > is certainly undesirable even though probably not catastrophic since all > such requests are likely to be eventually forwarded to the downstream > proxy or UA so the retransmissions will be detected as merged requests > there. > When using SRV records you have to choose the transport protocol as well as the service. So the TCP/UDP issue isn't a problem, the problem comes when the returned record contains multiple entries with the same priority, the proper method of using SRV requires that the weightings are used to randomly select an address. As soon as you select a random address a stateless proxy is doing the wrong thing, if you always select a server based on some deterministic heuristic you have broken the SRV lookups. On the subject of stateless proxies I am of the opinion that a true 'stateless proxy' is an oxymoron, for it to be useful it needs some state, the challenge is how much to make it useful and how little to make it fast. > > Another possible approach is to use only A records in stateless mode. > However, I don't think this has any advantages over the first approach > described; besides, some domains may not even have a SIP server at the > address listen in the A record. > I think the server location section of the bis draft would be better made a 'MAY' as it severely limits a proxy's discretion in routing matters. As the main purpose of a proxy is routing it seems unusual to fix this as a 'SHOULD' as the proxy itself may know better, before falling back on SRV. I am not in favour of specifying this in the bis draft as I believe it is an implementation issue outside of the scope of the proposed standard. 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 Sep 13 04:41: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 EAA03212 for ; Wed, 13 Sep 2000 04:41: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 3E9A244390; Wed, 13 Sep 2000 03:41:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id 2123644389 for ; Wed, 13 Sep 2000 03:40:57 -0400 (EDT) Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id JAA02190; Wed, 13 Sep 2000 09:39:11 +0100 (BST) Message-ID: <39BF3D2E.BF66EB9C@ubiquity.net> Date: Wed, 13 Sep 2000 09:39:10 +0100 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] Stateless 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > Neil wrote: > > Shail Bhatnagar wrote: > > > > > > I tend to think that the new bis version almost implies that : > > > > > > 1) An ACK without Route header is for the proxy and should > > be dropped. > > > (Stop response retx timer in stateful mode) > > > > What changes are you thinking of? I thought that a UAS MUST > > add a Contact to a 2xx reponse for INVITE but it is only a > > MAY as to whether the UAC sends the ACK directly there. > > Therefore an ACK without a Route may still need to be > > sent on by a proxy. > > Thats not my understanding, nor my reading of the bis draft. Section 6.13 > says: > > >INVITE and OPTIONS 2xx responses: A user agent server sending a definitive, > positive > >response (2xx) MUST insert a Contact response header field indicating the > SIP address under > >which it is reachable most directly for future SIP requests, such as ACK, > within the same > >Call-ID.TheContact header field contains the address of the server itself > or that of a > > proxy, e.g., if the host is behind a firewall.The value of this Contact > header is copied > > into the Request-URI of subsequent requests for this call if the response > did not also > > contain a Record-Route header. If the response also contains a > Record-Route > >header field, the address in the Contact header field is added as the last > item in the > > Route header field. See Section 6.34 for details. > > and then later, section 6.34.2 says: > > > Once a proxy P inserts a Record-Route header in a request from UA A to UA > B , all > > subsequent requests from A to B and from B to A visit P . > > Thus, although no explicit strength is assigned, it was my understanding > that text of the form "the proxy inserts X" or "the UA copies A to B" was > effectively MUST. If this is the intention the text in 11.3 needs to be updated ... "The Request-URI of the ACK or BYE request MAY be set to whatever address was found in the Contact header field in the 200 (OK) response, if present. Alternately, a UAC may copy the address from the To header field into the Request-URI." I would still question the assertion that an ACK without a Route never needs to be routed on by a Proxy. For example when a UA is configured to always use a Proxy for every outbound request. 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 Wed Sep 13 04:48:22 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA03241 for ; Wed, 13 Sep 2000 04:48:22 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C315344396; Wed, 13 Sep 2000 03:47:33 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id 2EF5C44393 for ; Wed, 13 Sep 2000 03:47:29 -0400 (EDT) Received: from gethin by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id JAA06184; Wed, 13 Sep 2000 09:45:47 +0100 (BST) From: Gethin Liddell Organization: Ubiquity Software Corp. To: Igor Slepchin , sip@lists.bell-labs.com Subject: Re: [SIP] DNS SRV records in stateless mode Date: Wed, 13 Sep 2000 09:06:12 +0100 X-Mailer: KMail [version 1.0.29.2] Content-Type: text/plain References: <39BE79A5.BF57C58@dynamicsoft.com> In-Reply-To: <39BE79A5.BF57C58@dynamicsoft.com> MIME-Version: 1.0 Message-Id: <00091309384100.27142@gethin> Content-Transfer-Encoding: 8bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 8bit Hi, Igor On Tue, 12 Sep 2000, Igor Slepchin wrote: > The 2543bis draft is silent about using SRV records in stateless mode > and I think the subject may be worth some discussion. > > As far as I can tell, the best approach seems to be to just use the > highest priority SRV records for the protocols supported that doesn't > result in the immediate failure. That is, if the first SRV record turns > out to be for TCP and the connection to the specified host fails, the > next SRV record should be tried. um, stateless proxies don't do tcp. so when you do the SRV lookup, you would only sepcify udp so this problem does not occur. > However, ICMP errors cannot be detected > in stateless mode so the search automatically stops on the first UDP > record (recycling connected UDP socket across requests would help > detecting ICMP errors). agreed, and i do believe that the only real thing that statless servers can do here is ignore ICMP. > Note that using the standard algorithm described in 1.4.2 and RFC2782 in > stateless mode is problematic since this will likely result in > retransmissions of the request to be sent to different next hops. This > is certainly undesirable even though probably not catastrophic since all > such requests are likely to be eventually forwarded to the downstream > proxy or UA so the retransmissions will be detected as merged requests > there. this error could provide big problems, if not with the routing then maybe with a user getting billed twice etc... > > Another possible approach is to use only A records in stateless mode. > However, I don't think this has any advantages over the first approach > described; besides, some domains may not even have a SIP server at the > address listen in the A record. > > Any comments? I think it is fair to say that a statless proxy first of all does SRV for sip and udp (in the case of non IP address and port 5060). if this fails then an A record look up is done. In each case the first record should be used if possible. if both fail, then nothing is done. Although there was some discussion recently on returning final responses in the statless mode which we may need to consider. thoughts and opinions? gethin -- 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 Sep 13 04:50: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 EAA03285 for ; Wed, 13 Sep 2000 04:50: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 71BCA4439F; Wed, 13 Sep 2000 03:49:36 -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 1BB764439C for ; Wed, 13 Sep 2000 03:49:32 -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 LAA02663 for ; Wed, 13 Sep 2000 11:52:09 +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: Date: Wed, 13 Sep 2000 11:49:07 +0200 X-MIMETrack: Serialize by Router on ILNimo/Vocaltec_Comm(Release 5.0.3 (Intl)|21 March 2000) at 09/13/2000 11:49:08 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [SIP] SIP meetings Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com I am interested in participating in SIP meetings, conferences, or working groups. I noticed on the SIP homepage that there was a meeting at IETF 48 in July-August, but I can't find any mention of upcoming meetings. Does anyone know where can I find such information? Joshua Fox Surf and Call Network Services VocalTec _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Sep 13 05:15: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 FAA03383 for ; Wed, 13 Sep 2000 05:15:53 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3D1E144389; Wed, 13 Sep 2000 04:15:38 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id 1770644370 for ; Wed, 13 Sep 2000 04:15:28 -0400 (EDT) Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id KAA19856; Wed, 13 Sep 2000 10:13:12 +0100 (BST) Message-ID: <39BF4528.3E5F6DC5@ubiquity.net> Date: Wed, 13 Sep 2000 10:13:12 +0100 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: Joshua_Fox@vocaltec.com Cc: sip@lists.bell-labs.com Subject: Re: [SIP] SIP meetings 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit As an IETF WG there will be a SIP meeting as part of the IETF meetings ( see http://www.ietf.org ). There is also an increasing number of SIP conferences, events etc. For announcements check out: Henning's SIP page http://www.cs.columbia.edu/~hgs/sip/ Dean Willis's SIP WG Home Page http://www.softarmor.com/sipwg/ The SIP Center (particularly the Diary link) http://www.sipcenter.com/ The SIP Forum http://www.sipforum.org hth, Neil -- Ubiquity Software Corporation, UK http://www.ubiquity.net Joshua_Fox@vocaltec.com wrote: > > I am interested in participating in SIP meetings, conferences, or working > groups. I noticed on the SIP homepage that there was a meeting at IETF 48 > in July-August, but I can't find any mention of upcoming meetings. Does > anyone know where can I find such information? > > Joshua Fox > Surf and Call Network Services > VocalTec _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Sep 13 09:14: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 JAA07318 for ; Wed, 13 Sep 2000 09:14: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 D621644360; Wed, 13 Sep 2000 08:13:51 -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 2276644370 for ; Tue, 12 Sep 2000 18:28:57 -0400 (EDT) Received: from vovida.com ([209.237.8.113]) by pigeon.vovida.com (Netscape Messaging Server 4.15) with ESMTP id G0SRQ000.FML; Tue, 12 Sep 2000 16:25:12 -0700 Message-ID: <39BEBC35.5BEC9412@vovida.com> Date: Tue, 12 Sep 2000 16:28:54 -0700 From: Krishan Veer 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 Cc: rsparks@dynamicsoft.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] Handle'n of NOT A KNOWN SIP Header Messages Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Hi Everyone! How to Handle NOT A KNOWN SIP Header Messages, My understanding if the header is of Unknown type but Message has valid sip grammar body the proxy should forward it on ? is there any special way of handle'n these messages like these messages should be treated as Request only.? I didn't find anything on this topic in archive & rfc , Any pointers will be helpful Thanks veer _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Sep 13 10: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 KAA08519 for ; Wed, 13 Sep 2000 10:01: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 B793F44384; Wed, 13 Sep 2000 09:00:50 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mailwall.ttimail.com (mailwall.ttimail.com [216.86.19.5]) by lists.bell-labs.com (Postfix) with ESMTP id 583EA44370 for ; Wed, 13 Sep 2000 09:00:47 -0400 (EDT) Received: from mailwall.ttiworld.com [127.0.0.1] by mailwall.ttimail.com (SMTPD32-6.04) id A888E1E0112; Wed, 13 Sep 2000 09:00:40 -0500 Received: by mailhost.ttiworld.com with Internet Mail Service (5.5.2650.21) id ; Wed, 13 Sep 2000 09:00:36 -0500 Message-ID: <69DEAC407D3B6A48AA71F5D09966F7DB1B0079@mailhost.ttiworld.com> From: Kevin Summers To: Krishan Veer , sip@lists.bell-labs.com Cc: rsparks@dynamicsoft.com Subject: RE: [SIP] Handle'n of NOT A KNOWN SIP Header Messages Date: Wed, 13 Sep 2000 09:00:30 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Assuming that you mean an unknown SIP header (not a header _message_ ). Page 34, section 6 (Header definition) of RFC 2543bis-01: "...a server must ignore header fields not defined in this specification that it does not understand. A proxy must not move or modify header fields not defined in this specification that it does not understand." Hth, Kevin -----Original Message----- From: Krishan Veer [mailto:kveer@vovida.com] Sent: Tuesday, September 12, 2000 6:29 PM To: sip@lists.bell-labs.com Cc: rsparks@dynamicsoft.com Subject: [SIP] Handle'n of NOT A KNOWN SIP Header Messages Hi Everyone! How to Handle NOT A KNOWN SIP Header Messages, My understanding if the header is of Unknown type but Message has valid sip grammar body the proxy should forward it on ? is there any special way of handle'n these messages like these messages should be treated as Request only.? I didn't find anything on this topic in archive & rfc , Any pointers will be helpful Than veer _______________________________________________ SIP mailing list SIP@lists.bell-labs.com 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 Sep 13 12: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 MAA11558 for ; Wed, 13 Sep 2000 12:21: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 3BB1D4434C; Wed, 13 Sep 2000 11:20:16 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from bounty.cisco.com (bounty.cisco.com [161.44.3.204]) by lists.bell-labs.com (Postfix) with ESMTP id A607E44336 for ; Wed, 13 Sep 2000 11:20:12 -0400 (EDT) Received: from cisco.com (rtp-xdm1.cisco.com [161.44.3.80]) by bounty.cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id MAA22959; Wed, 13 Sep 2000 12:19:46 -0400 (EDT) Message-ID: <39BFA90C.22603627@cisco.com> Date: Wed, 13 Sep 2000 12:19:24 -0400 From: Shail Bhatnagar X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Neil Deason Cc: Jonathan Rosenberg , "'sip@lists.bell-labs.com'" Subject: Re: [SIP] Stateless Proxy References: <39BF3D2E.BF66EB9C@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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Neil Deason wrote: > I would still question the assertion that an ACK > without a Route never needs to be routed on by > a Proxy. For example when a UA is configured to > always use a Proxy for every outbound request. > Neil, I am hazy about this aspect and I don't think spec is very clear on this. The unanswered questions in my mind are (when the user agent uses a local proxy for every outbound request) : (a) If 200 response to INVITE did not have a Record-Route, can the user agent send ACK directly to the other user agent ( Contact ofcourse is mandatory) or should it send it to its proxy and put a Route header containing the Contact of the other user agent ?? (b) 200 response to INVITE does have Record-Route and the user agent uses the algorithm outlined in the spec to formulate an ACK. Should it still send it unconditionally to its local proxy ? _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Sep 13 14:20: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 OAA15416 for ; Wed, 13 Sep 2000 14:20: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 EB42944346; Wed, 13 Sep 2000 13:20: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 3DCC044336 for ; Wed, 13 Sep 2000 13:19:59 -0400 (EDT) Received: from dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id OAA23544; Wed, 13 Sep 2000 14:20:48 -0400 (EDT) Message-ID: <39BFC52D.9731C5A0@dynamicsoft.com> Date: Wed, 13 Sep 2000 14:19:25 -0400 From: Igor Slepchin Organization: dynamicsoft Inc. X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en,ru MIME-Version: 1.0 To: Gethin Liddell Cc: sip@lists.bell-labs.com Subject: Re: [SIP] DNS SRV records in stateless mode References: <39BE79A5.BF57C58@dynamicsoft.com> <00091309384100.27142@gethin> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Gethin Liddell wrote: > > um, stateless proxies don't do tcp. so when you do the SRV lookup, > you would only sepcify udp so this problem does not occur. That's correct. However, the proxy may decide to process a transaction statefully if there is a TCP SRV record for it so I wouldn't necessarily limit SRV request to UDP only. Of course, once the decision to process the request statefully has been made, the problem with handling retransmissions is gone. James Undery wrote: > > I think the server location section of the bis draft would be better made a > 'MAY' as it severely limits a proxy's discretion in routing matters. As the > main purpose of a proxy is routing it seems unusual to fix this as a > 'SHOULD' as the proxy itself may know better, before falling back on SRV. I > am not in favour of specifying this in the bis draft as I believe it is an > implementation issue outside of the scope of the proposed standard. The proxy is free to apply any logic it wants when making routing decisions (CPL, CGI, servlets, etc.). However, if it decides to make the routing decision based on DNS, it should follow the SRV algorithm described so I see no problems with keeping it as a SHOULD. > <...> if you always select a server based on some > deterministic heuristic you have broken the SRV lookups. We've only broken load balancing and failover pieces of it. The other important aspect of using SRV records - service specific host definition - is still used. The load balancing piece may be partially preserved if we require that stateless servers use a random but constant throughout the lifetime value for ordering SRV records. That is, each stateless server will always choose the same host for a domain but different stateless servers will end up using different hosts. Thus, the load balancing is done across multiple upstream hops. --- 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 Sep 13 21:05: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 VAA19888 for ; Wed, 13 Sep 2000 21:05: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 283BB4434C; Wed, 13 Sep 2000 20:04:56 -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 DCB9D44336 for ; Wed, 13 Sep 2000 20:04: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 VAA21291; Wed, 13 Sep 2000 21:04:33 -0400 (EDT) Message-ID: <39BF7179.1B259CE8@cs.columbia.edu> Date: Wed, 13 Sep 2000 08:22:17 -0400 From: Henning Schulzrinne X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Igor Slepchin Cc: sip@lists.bell-labs.com Subject: Re: [SIP] DNS SRV records in stateless mode References: <39BE79A5.BF57C58@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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Igor Slepchin wrote: > > The 2543bis draft is silent about using SRV records in stateless mode > and I think the subject may be worth some discussion. > > As far as I can tell, the best approach seems to be to just use the > highest priority SRV records for the protocols supported that doesn't > result in the immediate failure. That is, if the first SRV record turns > out to be for TCP and the connection to the specified host fails, the > next SRV record should be tried. However, ICMP errors cannot be detected > in stateless mode so the search automatically stops on the first UDP > record (recycling connected UDP socket across requests would help > detecting ICMP errors). Always, a randomly selected host among the highest-priority SRV record is used. Thus, even in the case, retransmissions may reach different destinations. However, that's completely up to the configuration of that domain. A domain that cares that this doesn't happen is well advised to not to list hosts with equal priority. I agree that keeping a cache of connected UDP sockets would be helpful, in case the upstream client retransmits. Also, some operating systems may allow detection of ICMP errors (and one could, albeit with significant pain, intercept ICMP via raw sockets on Unix-like operating systems and then keep a black list of invalid downstream servers.). The obvious problem is that having a single highest-priority UDP server makes failover for servers more difficult, as the stateless proxy will try the failed server again and again. Thus, randomization seems like a good thing. > > Note that using the standard algorithm described in 1.4.2 and RFC2782 in > stateless mode is problematic since this will likely result in > retransmissions of the request to be sent to different next hops. This > is certainly undesirable even though probably not catastrophic since all > such requests are likely to be eventually forwarded to the downstream > proxy or UA so the retransmissions will be detected as merged requests > there. > > Another possible approach is to use only A records in stateless mode. > However, I don't think this has any advantages over the first approach > described; besides, some domains may not even have a SIP server at the > address listen in the A record. Using A records would be highly undesirable. In addition, it would be hard to determine which protocol to use. > > Any comments? > > --- > Igor Slepchin > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > 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 Sep 13 23:49: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 XAA23278 for ; Wed, 13 Sep 2000 23:49: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 628984434C; Wed, 13 Sep 2000 22:49:07 -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 8882044336 for ; Wed, 13 Sep 2000 19:17:27 -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 UAA18727; Wed, 13 Sep 2000 20:17:07 -0400 (EDT) Message-ID: <39C01903.3A25CC21@cs.columbia.edu> Date: Wed, 13 Sep 2000 20:17:07 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Neil Deason Cc: Jonathan Rosenberg , "'sip@lists.bell-labs.com'" Subject: Re: [SIP] Stateless Proxy References: <39BF3D2E.BF66EB9C@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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Neil Deason wrote: > > > Thus, although no explicit strength is assigned, it was my understanding > > that text of the form "the proxy inserts X" or "the UA copies A to B" was > > effectively MUST. > > If this is the intention the text in 11.3 needs > to be updated ... > > "The Request-URI of the ACK or BYE request MAY be set to > whatever address was found in the Contact header field in > the 200 (OK) response, if present. Alternately, a UAC may > copy the address from the To header field into the > Request-URI." Would things be simplified if the spec just said "MUST copy from Contact"? I've lost the reason why the flexibility might be needed. > > I would still question the assertion that an ACK > without a Route never needs to be routed on by > a Proxy. For example when a UA is configured to > always use a Proxy for every outbound request. There are two interpretations of the outbound proxy concept: (1) It's clearly needed to force routing for the first request in a transaction or call, since Record-Route isn't available. (2) It could be implied for each request, regardless of Record-Route. Isn't strictly necessary, since Route can do the job, but it seems easier to have outbound proxy mean "always use, even if it doesn't record-route". My impression is that most implementation always use it if configured. -- 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 Sep 13 23:50: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 XAA23293 for ; Wed, 13 Sep 2000 23:50: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 762E04435B; Wed, 13 Sep 2000 22:49: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 87E0D44336 for ; Wed, 13 Sep 2000 19:36: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 UAA19671; Wed, 13 Sep 2000 20:36:09 -0400 (EDT) Message-ID: <39C01D79.1AFBF66C@cs.columbia.edu> Date: Wed, 13 Sep 2000 20:36:09 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Igor Slepchin Cc: Gethin Liddell , sip@lists.bell-labs.com Subject: Re: [SIP] DNS SRV records in stateless mode References: <39BE79A5.BF57C58@dynamicsoft.com> <00091309384100.27142@gethin> <39BFC52D.9731C5A0@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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Igor Slepchin wrote: > > Gethin Liddell wrote: > > > > um, stateless proxies don't do tcp. so when you do the SRV lookup, > > you would only sepcify udp so this problem does not occur. > > That's correct. However, the proxy may decide to process a transaction > statefully if there is a TCP SRV record for it so I wouldn't necessarily > limit SRV request to UDP only. Of course, once the decision to process > the request statefully has been made, the problem with handling > retransmissions is gone. > > > The proxy is free to apply any logic it wants when making routing > decisions (CPL, CGI, servlets, etc.). However, if it decides to make the > routing decision based on DNS, it should follow the SRV algorithm > described so I see no problems with keeping it as a SHOULD. I agree. Since an implementation's decision of creatively reinterpreting the SRV logic could severely degrade the load balancing that a downstream server has in place, for example, this is not a private decision. If somebody gets lazy and always picks the first server from the load sharing pool, I want to at least be able to wave the spec at them. > > > <...> if you always select a server based on some > > deterministic heuristic you have broken the SRV lookups. > > We've only broken load balancing and failover pieces of it. The other > important aspect of using SRV records - service specific host definition > - is still used. The load balancing piece may be partially preserved if > we require that stateless servers use a random but constant throughout > the lifetime value for ordering SRV records. That is, each stateless > server will always choose the same host for a domain but different > stateless servers will end up using different hosts. Thus, the load > balancing is done across multiple upstream hops. If you want the true stateless reliability that allows fail-over in mid call, you need to synchronize whatever backend state anyway across servers, so I'm not sure that imposing this restriction is particularly useful. It is also very likely to be a brittle requirement which is hard to enforce, unlikely to be implemented universally and unlikely to be detected if not done correctly (since most tests are not going to use the load balancing feature). Thus, it seems dangerous to have servers rely on the fact that retransmissions will go to the same place. If you can't handle this state distribution, don't advertise multiple equal-priority hosts and use a "web director"-style approach. For billing records, it's pretty easy to create a handle that only depends on invariant aspects of the request and thus lends itself to easy reconciliation if two records appear with the same value, entered by different servers. If you want that across requests, use Record-Route. -- 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 Sep 13 23:52: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 XAA23309 for ; Wed, 13 Sep 2000 23:52: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 A631144364; Wed, 13 Sep 2000 22:49:16 -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 7551244336 for ; Wed, 13 Sep 2000 18:55:41 -0400 (EDT) Received: from vovida.com ([209.237.8.113]) by pigeon.vovida.com (Netscape Messaging Server 4.15) with ESMTP id G0UNMD00.DOW for ; Wed, 13 Sep 2000 16:51:49 -0700 Message-ID: <39C013FA.2BA464D4@vovida.com> Date: Wed, 13 Sep 2000 16:55:38 -0700 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 Call Control Transfer Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit I have a few questions about the details of the URL defined in the Refer-To and Referred-By headers. 1. Can I follow the specifications of RFC 1738 for URL to parse it 2. Can URL be a SIP-URL. 3. Can the URL be any of all the protocols listed or less ftp http gopher mailto news nntp telnet wais file prospero Thanks. Amit Choksi (Vovida Networks) _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Sep 14 00:49: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 AAA23778 for ; Thu, 14 Sep 2000 00:49: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 D5FE744358; Wed, 13 Sep 2000 23:48:25 -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 DCA6544346 for ; Wed, 13 Sep 2000 23:48: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 AAA27161; Thu, 14 Sep 2000 00:46:17 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Thu, 14 Sep 2000 00:41:25 -0400 Message-ID: From: Jonathan Rosenberg To: "'Henning Schulzrinne'" , "'Neil Deason'" Cc: Jonathan Rosenberg , "'sip@lists.bell-labs.com'" Subject: RE: [SIP] Stateless Proxy Date: Thu, 14 Sep 2000 00:41:24 -0400 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com > -----Original Message----- > From: Henning Schulzrinne [mailto:schulzrinne@cs.columbia.edu] > Sent: Wednesday, September 13, 2000 8:17 PM > To: Neil Deason > Cc: Jonathan Rosenberg; 'sip@lists.bell-labs.com' > Subject: Re: [SIP] Stateless Proxy > > > Neil Deason wrote: > > > > > > Thus, although no explicit strength is assigned, it was > my understanding > > > that text of the form "the proxy inserts X" or "the UA > copies A to B" was > > > effectively MUST. > > > > If this is the intention the text in 11.3 needs > > to be updated ... > > > > "The Request-URI of the ACK or BYE request MAY be set to > > whatever address was found in the Contact header field in > > the 200 (OK) response, if present. Alternately, a UAC may > > copy the address from the To header field into the > > Request-URI." > > Would things be simplified if the spec just said "MUST copy from > Contact"? I've lost the reason why the flexibility might be needed. > > > > > I would still question the assertion that an ACK > > without a Route never needs to be routed on by > > a Proxy. For example when a UA is configured to > > always use a Proxy for every outbound request. > > There are two interpretations of the outbound proxy concept: > > (1) It's clearly needed to force routing for the first request in a > transaction or call, since Record-Route isn't available. > > (2) It could be implied for each request, regardless of Record-Route. > Isn't strictly necessary, since Route can do the job, but it seems > easier to have outbound proxy mean "always use, even if it doesn't > record-route". My impression is that most implementation always use it > if configured. Actually, I thought that outbound proxy would apply only for requests which don't already have Route. The reason is that this gives the provider flexibility - if they want to see every request, they record-route. If they just need to see the first, then they don't. -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 Sep 14 01: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 BAA26478 for ; Thu, 14 Sep 2000 01: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 554E544364; Thu, 14 Sep 2000 00:24:45 -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 117C444346 for ; Thu, 14 Sep 2000 00:24: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 BAA27280; Thu, 14 Sep 2000 01:26:34 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Thu, 14 Sep 2000 01:21:42 -0400 Message-ID: From: Jonathan Rosenberg To: "'sip (E-mail)'" , "'sip-implementors@cs.columbia.edu'" Date: Thu, 14 Sep 2000 01:21:41 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] A warning to implementors Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Folks, In our tests in our labs of various SIP devices, we have been increasing discovering that people have introduced arbitrary length restrictions on various SIP fields. For example, we have discovered that one vendor limits the length of the branch ID to 16 bytes. If it gets more than that, it rejects the request. We ran into this when trying to test out the recent proposal for adding uniqueness to the branch ID. Very bad. I cannot emphasize enough the scope of this implementation error. It is a recipe for interoperability nightmares. Over time, people find additional uses and data types they would like to stick in various fields. Branch ID is one that is particularly nice, for example. As these field usages get larger, and press against these artificial barriers, you severely limit the growth of the protocol, and its overall interoperability. These problems are extremely hard to find and always come up years later. The SIP spec in no way whatsoever says that tokens and other assorted constructions are limited in length. If your implementation barfs on things like this, it is NON-COMPLIANT to rfc2543. Please, folks, fix these things. 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 Thu Sep 14 04:10: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 EAA07250 for ; Thu, 14 Sep 2000 04:10: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 244A444358; Thu, 14 Sep 2000 03:09:32 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from p-mail2.cnet.fr (unknown [192.144.74.32]) by lists.bell-labs.com (Postfix) with SMTP id 5A41444346 for ; Thu, 14 Sep 2000 03:09:28 -0400 (EDT) Received: by p-voyageur.issy.cnet.fr with Internet Mail Service (5.5.2448.0) id ; Thu, 14 Sep 2000 10:09:07 +0200 Message-ID: <98388C05D464D111B61800805F15041601A2DCF6@p-ibis.issy.cnet.fr> From: DAO TRUNG Tin FTRD/DAC/ISS To: sip@lists.bell-labs.com Date: Thu, 14 Sep 2000 10:09:00 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] creation of the SIP WG Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Hello everyone, Could someone tell me when the SIP WG was created ? Thanks, Tin DAO TRUNG &francetelecom.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 Sep 14 05:50:29 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA07806 for ; Thu, 14 Sep 2000 05: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 B6A0144358; Thu, 14 Sep 2000 04:50:13 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id 9CA4A44346 for ; Thu, 14 Sep 2000 04:49:51 -0400 (EDT) Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id KAA22602; Thu, 14 Sep 2000 10:46:47 +0100 (BST) From: "Jo Hornsby" To: "Jonathan Rosenberg" , "'Henning Schulzrinne'" , "'Neil Deason'" Cc: Subject: RE: [SIP] Stateless Proxy Date: Thu, 14 Sep 2000 10:46:47 +0100 Message-ID: <003301c01e30$b2bbf5e0$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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit > > > "The Request-URI of the ACK or BYE request MAY be set to > > > whatever address was found in the Contact header field in > > > the 200 (OK) response, if present. Alternately, a UAC may > > > copy the address from the To header field into the > > > Request-URI." > > > > Would things be simplified if the spec just said "MUST copy from > > Contact"? I've lost the reason why the flexibility might be needed. Seems right to me; the only exceptions are of course if Record-Route were present, and if there were no Contact (in which case I guess one uses To). > > > I would still question the assertion that an ACK > > > without a Route never needs to be routed on by > > > a Proxy. For example when a UA is configured to > > > always use a Proxy for every outbound request. > > > > There are two interpretations of the outbound proxy concept: > > > > (1) It's clearly needed to force routing for the first request in a > > transaction or call, since Record-Route isn't available. > > > > (2) It could be implied for each request, regardless of Record-Route. > > Isn't strictly necessary, since Route can do the job, but it seems > > easier to have outbound proxy mean "always use, even if it doesn't > > record-route". My impression is that most implementation always use it > > if configured. > > Actually, I thought that outbound proxy would apply only for > requests which don't already have Route. The reason is that this > gives the provider flexibility - if they want to see every request, > they record-route. If they just need to see the first, then they > don't. It might be helpful to have some clarification here in the spec; the current definition is: Outbound proxy: A proxy that is located near the originator of requests. It receives all outgoing requests from a particular UAC, ^^^ including those requests whose Request-URLs identify a host other than the outbound proxy. The outbound proxy sends these requests, after any local processing, to the address indicated in the request-URI. (All other proxy servers are simply referred as proxies, not inbound proxies.) I would also note Section 11.4: If a UAC does not support DNS resolution or the full Record-Route/Route mechanism, it MAY send all requests to a locally configured outbound proxy. In that case, that proxy behaves as described above. The UAC MUST, however, perform the mapping of Record-Route to Route header fields and MUST include all Route header fields, i.e., the UAC does not remove the first Route header field. Thus it's potentially a bit messy (although will work) if an outbound proxy decides to add itself in Record-Route, since re-INVITEs, or what have you, are likely to needlessly loop through the outbound proxy (okay -- so the proxy could be intelligent here). I think Henning's observation on most UACs using an outbound proxy for _every_ request is about right (after all, that is what the spec says); however, as Johnathan points out, just using it for initial request would seem to give the necessary flexibility. Of course, it's purely a client configuration issue, and everything will work regardless of the interpretation (unless an outbound proxy is doing some sort of firewall magic, and assumes that it doesn't need to Record-Route since it expects to always be in the path). Thoughts? - 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 Sep 14 05:55: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 FAA07836 for ; Thu, 14 Sep 2000 05:55: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 9DF4D4436F; Thu, 14 Sep 2000 04:54:27 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id 08B0844362 for ; Thu, 14 Sep 2000 04:54:05 -0400 (EDT) Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id KAA27231; Thu, 14 Sep 2000 10:50:44 +0100 (BST) From: "Jo Hornsby" To: "Shail Bhatnagar" , "Neil Deason" Cc: "Jonathan Rosenberg" , Subject: RE: [SIP] Stateless Proxy Date: Thu, 14 Sep 2000 10:50:43 +0100 Message-ID: <003401c01e31$3f916d60$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: <39BFA90C.22603627@cisco.com> Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit > Neil Deason wrote: > > > I would still question the assertion that an ACK > > without a Route never needs to be routed on by > > a Proxy. For example when a UA is configured to > > always use a Proxy for every outbound request. > > > > Neil, I am hazy about this aspect and I don't think spec is very > clear on this. The unanswered questions in my mind are (when > the user agent uses a local proxy for every outbound request) : > > (a) If 200 response to INVITE did not have a Record-Route, can > the user agent send ACK directly to the other user agent ( Contact > ofcourse is mandatory) or should it send it to its proxy and put > a Route header containing the Contact of the other user agent ?? No -- I don't think it should create a Route header containing the Contact address in; placing the Contact in the Request-URI should suffice. > (b) 200 response to INVITE does have Record-Route and the user > agent uses the algorithm outlined in the spec to formulate an ACK. > Should it still send it unconditionally to its local proxy ? That's the million dollar question. &:) But basically, it's not going to matter. [See my previous post.] 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 Sep 14 06:33: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 GAA08051 for ; Thu, 14 Sep 2000 06:33: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 C576944364; Thu, 14 Sep 2000 05:33:44 -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 5924544346 for ; Thu, 14 Sep 2000 05:33:41 -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, 14 Sep 2000 03:31:48 -0700 From: "Simon Barber" To: Date: Thu, 14 Sep 2000 03:34:42 -0700 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_007A_01C01DFC.B86A6B40" 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: <003301c01e30$b2bbf5e0$4e34c3c1@ubiquity.co.uk> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: [SIP] Outbound call routing Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com This is a multi-part message in MIME format. ------=_NextPart_000_007A_01C01DFC.B86A6B40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit This question may be due to my lack of understanding of request routing in SIP - if so please excuse me! Is it possible for a registration server to reply to a registration request, and insist that all future outbound requests be routed to a certain proxy? For instance, I want to implement a service that logs all my outgoing calls. To implement this service I must be able to monitor all outgoing call requests. If I am always at home, I will be using my usual outbound proxy, and this can implement the service. The problem occurs if I am away from home - using a SIP client in another network. This SIP client will use it's local outbound proxy, and hence requests will not pass through my outbound proxy. Simon ------=_NextPart_000_007A_01C01DFC.B86A6B40 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) 232-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: URL:http://www.firetalk.com EMAIL;PREF;INTERNET:simon@firetalk.com REV:20000908T025950Z END:VCARD ------=_NextPart_000_007A_01C01DFC.B86A6B40-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Sep 14 10:37: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 KAA13132 for ; Thu, 14 Sep 2000 10:37: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 4A11044351; Thu, 14 Sep 2000 09:37:24 -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 A06E944346 for ; Thu, 14 Sep 2000 09:13: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 KAA00413 for ; Thu, 14 Sep 2000 10:13:10 -0400 (EDT) Message-ID: <39C0DCF6.9DB3C765@cs.columbia.edu> Date: Thu, 14 Sep 2000 10:13:10 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.72 [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] SIP-related VON (and IPTS) presentations Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit I'd appreciate if you could send me pointers to your VON or IPTS presentations that are SIP-related, so that I can add them to the SIP talks & papers web page at http://www.cs.columbia.edu/sip/papers.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 Thu Sep 14 11:24: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 LAA17084 for ; Thu, 14 Sep 2000 11:24: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 6C7584435D; Thu, 14 Sep 2000 10:24:00 -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 D7E4A4435B for ; Thu, 14 Sep 2000 10:23:56 -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 for ; Thu, 14 Sep 2000 18:20:39 +0200 Received: by NT-MAIL with Internet Mail Service (5.5.2650.21) id ; Thu, 14 Sep 2000 18:21:07 +0200 Message-ID: From: Itamar Gilad To: "'SIP List'" Date: Thu, 14 Sep 2000 18:21:06 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="windows-1255" Subject: [SIP] Via header and case sensitivity Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com In the bakeoff SIP Torture Tests page (http://www.cs.columbia.edu/~hgs/sip/bakeoff/torture.html) under the "Illegal but shouldn't crash you" section the following test appears: "case-sensitive fields in the wrong case (E.g. Via: sip/2.0/udp)" I'm not sure why this is illegal. In 6.46.6 Via syntax is given as: Via = ( "Via" | "v") ":" 1#( sent-protocol sent-by *( ";" via-params ) [ comment ] ) ... sent-protocol = protocol-name "/" protocol-version "/" transport protocol-name = "SIP" | token protocol-version = token transport = "UDP" | "TCP" | token ... In C it says: "literal" Quotation marks surround literal text. Unless stated otherwise, the text is case-insensitive. So basically the protocol name 'sip' and the transport 'udp' should be OK. While we're on the subject, 2543bis-00 section 6.6 (Header Field format) specifies the following: "Unless otherwise noted, comparisons are case-sensitive. However, any parameters preceded by semi-colons are case-insensitive, while any quoted string literals are compared taken case into consideration." However this was removed from bis-01 and bis-02. So what is the default behavior for header values (quoted strings or otherwise) now? Thanks Itamar _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Sep 14 11:26: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 LAA17128 for ; Thu, 14 Sep 2000 11:26: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 BEF5E44376; Thu, 14 Sep 2000 10:24:45 -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 0CC4044370 for ; Thu, 14 Sep 2000 10:24: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 LAA00033; Thu, 14 Sep 2000 11:26:15 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Thu, 14 Sep 2000 11:21:22 -0400 Message-ID: From: Jonathan Rosenberg To: "'Simon Barber'" , "'sip@lists.bell-labs.com'" Subject: RE: [SIP] Outbound call routing Date: Thu, 14 Sep 2000 11:21:20 -0400 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com > -----Original Message----- > From: Simon Barber [mailto:simon@firetalk.com] > Sent: Thursday, September 14, 2000 6:35 AM > To: sip@lists.bell-labs.com > Subject: [SIP] Outbound call routing > > > This question may be due to my lack of understanding of > request routing in > SIP - if so please excuse me! > > Is it possible for a registration server to reply to a > registration request, > and insist that all future outbound requests be routed to a > certain proxy? No. > > For instance, I want to implement a service that logs all my > outgoing calls. > > To implement this service I must be able to monitor all outgoing call > requests. If I am always at home, I will be using my usual > outbound proxy, > and this can implement the service. The problem occurs if I > am away from > home - using a SIP client in another network. This SIP client > will use it's > local outbound proxy, and hence requests will not pass > through my outbound > proxy. This has come up as a subject of discussion a few times, primarily with wireless. If you, as a client, wish to force a request to route through your normal proxy, you can do so by inserting a Route header into the request, even though you have not previously gotten a record-route. This is most definitely a hack; I am not certain it will be completely interoperable since most proxies expect to see Route only if they previously record-routed. -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 Sep 14 11:35: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 LAA17258 for ; Thu, 14 Sep 2000 11:35: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 5798344385; Thu, 14 Sep 2000 10:33:12 -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 EE8024437C for ; Thu, 14 Sep 2000 10:33: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 LAA00135; Thu, 14 Sep 2000 11:33:56 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Thu, 14 Sep 2000 11:29:02 -0400 Message-ID: From: Jonathan Rosenberg To: "'Jo Hornsby'" , Jonathan Rosenberg , "'Henning Schulzrinne'" , "'Neil Deason'" Cc: "'sip@lists.bell-labs.com'" Subject: RE: [SIP] Stateless Proxy Date: Thu, 14 Sep 2000 11:29:00 -0400 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com > -----Original Message----- > From: Jo Hornsby [mailto:jhornsby@ubiquity.net] > > > > I would still question the assertion that an ACK > > > > without a Route never needs to be routed on by > > > > a Proxy. For example when a UA is configured to > > > > always use a Proxy for every outbound request. > > > > > > There are two interpretations of the outbound proxy concept: > > > > > > (1) It's clearly needed to force routing for the first > request in a > > > transaction or call, since Record-Route isn't available. > > > > > > (2) It could be implied for each request, regardless of > Record-Route. > > > Isn't strictly necessary, since Route can do the job, but it seems > > > easier to have outbound proxy mean "always use, even if it doesn't > > > record-route". My impression is that most implementation > always use it > > > if configured. > > > > Actually, I thought that outbound proxy would apply only for > > requests which don't already have Route. The reason is that this > > gives the provider flexibility - if they want to see every request, > > they record-route. If they just need to see the first, then they > > don't. > > It might be helpful to have some clarification here in the spec; > the current definition is: > Outbound proxy: A proxy that is located near the originator of > requests. It receives all outgoing requests from a particular UAC, > ^^^ > including those requests whose Request-URLs identify a host other > than the outbound proxy. The outbound proxy sends these requests, > after any local processing, to the address indicated in the > request-URI. (All other proxy servers are simply referred as > proxies, not inbound proxies.) Right - thats the current definition in the bis draft. RFC2543 offers no definition. The question is - is this current definition correct, or do we want to rather specify that the local outbound proxy is used ONLY if there is no specified route as a result of a previous Contact or Record-Route. > > I would also note Section 11.4: > If a UAC does not support DNS resolution or the full > Record-Route/Route mechanism, it MAY send all requests to a > locally configured outbound proxy. In that case, that proxy > behaves as described above. The UAC MUST, however, perform the > mapping of Record-Route to Route header fields and MUST include > all Route header fields, i.e., the UAC does not remove the first > Route header field. > > Thus it's potentially a bit messy (although will work) if an > outbound proxy decides to add itself in Record-Route, since > re-INVITEs, or what have you, are likely to needlessly loop > through the outbound proxy (okay -- so the proxy could be > intelligent here). Yuck; we really need consistent behaviors here. I'd rather specify that the local proxy needs to, or doesn't need to, add itself, but not both. > > I think Henning's observation on most UACs using an outbound > proxy for _every_ request is about right (after all, that is > what the spec says); however, as Johnathan points out, just > using it for initial request would seem to give the necessary > flexibility. Lets be clear - its what bis says right now. RFC2543 says nothing, and thus the need for discussion. My preference is to require the outbound proxy to record-route if it wants subsequent requests. -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 Sep 14 11:39: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 LAA17357 for ; Thu, 14 Sep 2000 11:39: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 165E244391; Thu, 14 Sep 2000 10: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 022224438A for ; Thu, 14 Sep 2000 10:36: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 LAA00210; Thu, 14 Sep 2000 11:37:54 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Thu, 14 Sep 2000 11:33:00 -0400 Message-ID: From: Jonathan Rosenberg To: "'DAO TRUNG Tin FTRD/DAC/ISS'" , "'sip@lists.bell-labs.com'" Subject: RE: [SIP] creation of the SIP WG Date: Thu, 14 Sep 2000 11:32:53 -0400 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com You can find info on the group at: http://www.cs.columbia.edu/~hgs/sip/ which indicates the answer is September of 1999. Prior to that, work on SIP occurred in the MMUSIC working group. -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: DAO TRUNG Tin FTRD/DAC/ISS > [mailto:tin.daotrung@rd.francetelecom.fr] > Sent: Thursday, September 14, 2000 4:09 AM > To: sip@lists.bell-labs.com > Subject: [SIP] creation of the SIP WG > > > Hello everyone, > > Could someone tell me when the SIP WG was created ? > > Thanks, > > Tin DAO TRUNG > &francetelecom.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 Sep 14 11:51: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 LAA17567 for ; Thu, 14 Sep 2000 11:51: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 AA9604436F; Thu, 14 Sep 2000 10:51:43 -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 89A3A4435B for ; Thu, 14 Sep 2000 10:51: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 LAA00391; Thu, 14 Sep 2000 11:53:04 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Thu, 14 Sep 2000 11:48:11 -0400 Message-ID: From: Jonathan Rosenberg To: "'Henning Schulzrinne'" , "'Igor Slepchin'" Cc: "'Gethin Liddell'" , "'sip@lists.bell-labs.com'" Subject: RE: [SIP] DNS SRV records in stateless mode Date: Thu, 14 Sep 2000 11:48:03 -0400 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com > -----Original Message----- > From: Henning Schulzrinne [mailto:schulzrinne@cs.columbia.edu] > Sent: Wednesday, September 13, 2000 8:36 PM > To: Igor Slepchin > Cc: Gethin Liddell; sip@lists.bell-labs.com > Subject: Re: [SIP] DNS SRV records in stateless mode > > > > <...> if you always select a server based on some > > > deterministic heuristic you have broken the SRV lookups. > > > > We've only broken load balancing and failover pieces of it. > The other > > important aspect of using SRV records - service specific > host definition > > - is still used. The load balancing piece may be partially > preserved if > > we require that stateless servers use a random but constant > throughout > > the lifetime value for ordering SRV records. That is, each stateless > > server will always choose the same host for a domain but different > > stateless servers will end up using different hosts. Thus, the load > > balancing is done across multiple upstream hops. > > If you want the true stateless reliability that allows > fail-over in mid > call, you need to synchronize whatever backend state anyway across > servers, so I'm not sure that imposing this restriction is > particularly > useful. It is also very likely to be a brittle requirement > which is hard > to enforce, unlikely to be implemented universally and unlikely to be > detected if not done correctly (since most tests are not going to use > the load balancing feature). Thus, it seems dangerous to have servers > rely on the fact that retransmissions will go to the same > place. If you > can't handle this state distribution, don't advertise multiple > equal-priority hosts and use a "web director"-style approach. This seems like a major burden. Basically, if I implement more than on SRV record with equal priority (which I will want for load balancing), I am forced to handle the case that any transaction can now be spread across multiple hosts. This is quite hard - forcing, as you say, back end state sharing for normal operation where otherwise it would only be needed in event of failure. I think it is not unreasonable to define the SRV "contract" that the particular SRV host used for the same transaction, in the case of a stateless proxy, remains unchanged for all requests in that transaction. Doing so is quite easy by making the randomization process depend on an invariant in the request; in particular, the transaction ID. So, I would compute a transaction ID by hashing to To, From, Call-ID, CSeq, top Via, R-URI, and then, if there are N equal priority records, choose one by using the top CEILING(log(N)) bits as a selector. The result is still significant randomization, but gives you the caching you asked for anyway, without any state. How about 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 Thu Sep 14 13:21: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 NAA19233 for ; Thu, 14 Sep 2000 13:21: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 B06824435B; Thu, 14 Sep 2000 12:21:09 -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 C907044359 for ; Thu, 14 Sep 2000 11:50:04 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Thu Sep 14 12:49:12 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 332C64437C; Thu, 14 Sep 2000 12:36:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from fox.bos.ascend.com (unknown [152.148.141.238]) by lists.bell-labs.com (Postfix) with ESMTP id AF88A44341 for ; Thu, 14 Sep 2000 12:36:02 -0400 (EDT) Received: by fox.bos.ascend.com with Internet Mail Service (5.5.2650.21) id ; Thu, 14 Sep 2000 12:35:48 -0400 Message-ID: From: "Prasad, Eshwara" To: "'SIP List'" Date: Thu, 14 Sep 2000 12:35:46 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="windows-1255" Subject: [SIP] INVITE with new SDP /higher CSeq Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Hi, Am quite new to SIP. The august draft doesnt say anything on how the user agent is notified after getting an INVITE from him with a higher CSeq and updated SDP parameters. Can anyone let me know hows the User Agent notified by the server for success and failure ? Thanks Prasad _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Sep 14 15:07: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 PAA22665 for ; Thu, 14 Sep 2000 15:07: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 AF23C44378; Thu, 14 Sep 2000 14:06: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 B6EEE4435E for ; Thu, 14 Sep 2000 12:36:04 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Thu Sep 14 13:35:15 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 31ECB4437C; Thu, 14 Sep 2000 13:22:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from fox.bos.ascend.com (unknown [152.148.141.238]) by lists.bell-labs.com (Postfix) with ESMTP id AD00744341 for ; Thu, 14 Sep 2000 13:22:04 -0400 (EDT) Received: by fox.bos.ascend.com with Internet Mail Service (5.5.2650.21) id ; Thu, 14 Sep 2000 13:21:50 -0400 Message-ID: From: "Prasad, Eshwara" To: "'sip@lists.bell-labs.com'" Date: Thu, 14 Sep 2000 13:21:48 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="windows-1255" Subject: [SIP] INVITE with new SDP /higher CSeq Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Hi, Am quite new to SIP. The august draft doesnt say anything on how the user agent is notified after getting a new INVITE from him with a higher CSeq and updated SDP parameters. Can anyone let me know hows the User Agent notified by the server for success and failure in this scenario? Thanks Prasad _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Sep 14 15:46: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 PAA23124 for ; Thu, 14 Sep 2000 15:46: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 2845344386; Thu, 14 Sep 2000 14:45:42 -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 A1A9C4433F for ; Thu, 14 Sep 2000 14:45:38 -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, 14 Sep 2000 12:43:45 -0700 From: "Simon Barber" To: Cc: "Jonathan Rosenberg" Subject: RE: [SIP] Outbound call routing Date: Thu, 14 Sep 2000 12:46:41 -0700 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_009C_01C01E49.D49033C0" 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com This is a multi-part message in MIME format. ------=_NextPart_000_009C_01C01E49.D49033C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit The issue is service transparency with user mobility. User mobility is supposed to be one of SIP's strengths. Solving the problem by having the client add Route to future requests requires a specific client. This does not fit in well with user mobility - the user should be able to log into any generic client, and still have his services work. He should not have to use a special client for his services to work. This is client mobility, not user mobility. A possible solution would be to add a header like record-route, but rather than scoping it to a call leg, scope it to a particular registration. There are many services that get broken by not being able to track outbound calls. Simon -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Thursday, September 14, 2000 8:21 AM To: 'Simon Barber'; 'sip@lists.bell-labs.com' Subject: RE: [SIP] Outbound call routing > -----Original Message----- > From: Simon Barber [mailto:simon@firetalk.com] > Sent: Thursday, September 14, 2000 6:35 AM > To: sip@lists.bell-labs.com > Subject: [SIP] Outbound call routing > > > This question may be due to my lack of understanding of > request routing in > SIP - if so please excuse me! > > Is it possible for a registration server to reply to a > registration request, > and insist that all future outbound requests be routed to a > certain proxy? No. > > For instance, I want to implement a service that logs all my > outgoing calls. > > To implement this service I must be able to monitor all outgoing call > requests. If I am always at home, I will be using my usual > outbound proxy, > and this can implement the service. The problem occurs if I > am away from > home - using a SIP client in another network. This SIP client > will use it's > local outbound proxy, and hence requests will not pass > through my outbound > proxy. This has come up as a subject of discussion a few times, primarily with wireless. If you, as a client, wish to force a request to route through your normal proxy, you can do so by inserting a Route header into the request, even though you have not previously gotten a record-route. This is most definitely a hack; I am not certain it will be completely interoperable since most proxies expect to see Route only if they previously record-routed. -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_009C_01C01E49.D49033C0 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_009C_01C01E49.D49033C0-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Sep 15 00:09: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 AAA01907 for ; Fri, 15 Sep 2000 00:09: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 057C14438D; Thu, 14 Sep 2000 23:07:51 -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 2479844370 for ; Thu, 14 Sep 2000 20:25:30 -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 VAA20931; Thu, 14 Sep 2000 21:25:23 -0400 (EDT) Message-ID: <39C17A82.FE7FDFB2@cs.columbia.edu> Date: Thu, 14 Sep 2000 21:25:22 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: "'Igor Slepchin'" , "'Gethin Liddell'" , "'sip@lists.bell-labs.com'" Subject: Re: [SIP] DNS SRV records in stateless mode 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > > This seems like a major burden. Basically, if I implement more than on SRV > record with equal priority (which I will want for load balancing), I am > forced to handle the case that any transaction can now be spread across > multiple hosts. This is quite hard - forcing, as you say, back end state > sharing for normal operation where otherwise it would only be needed in > event of failure. I'm still not sure what "normal" operations need this type of state. Billing was mentioned, but there, you need it anyway in case of failures and other strange cases. > I think it is not unreasonable to define the SRV > "contract" that the particular SRV host used for the same transaction, in > the case of a stateless proxy, remains unchanged for all requests in that > transaction. > > Doing so is quite easy by making the randomization process depend on an > invariant in the request; in particular, the transaction ID. So, I would > compute a transaction ID by hashing to To, From, Call-ID, CSeq, top Via, > R-URI, and then, if there are N equal priority records, choose one by using > the top CEILING(log(N)) bits as a selector. The result is still significant > randomization, but gives you the caching you asked for anyway, without any > state. If all you want is randomization, hashing just the Call-Id is probably easiest to implement and describe, since you'd rather want subsequent requests to go to the same place and I see no large load-sharing advantage in randomizing across requests. I have to admit that I'm still a bit concerned that a proxy would rely on this somewhat obscure aspect of correct upstream behavior. If anything like billing depends on it, it offers opportunities for "creative" upstream proxies to see if they can't "improve" the behavior by ignoring this little rule. If a bug in an outbound proxy creates double billing downstream, you're going to have a very hard time explaining this to the customer. ("Mrs. Daisy, unfortunately your ISP doesn't randomize properly, so you're being billed twice for every tenth call.") -- 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 Sep 15 01: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 BAA08755 for ; Fri, 15 Sep 2000 01: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 BD7304438B; Fri, 15 Sep 2000 00:55:45 -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 50DFB44358 for ; Fri, 15 Sep 2000 00:55: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 BAA05684; Fri, 15 Sep 2000 01:57:32 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Fri, 15 Sep 2000 01:52:38 -0400 Message-ID: From: Jonathan Rosenberg To: "'Henning Schulzrinne'" , Jonathan Rosenberg Cc: "'Igor Slepchin'" , "'Gethin Liddell'" , "'sip@lists.bell-labs.com'" Subject: RE: [SIP] DNS SRV records in stateless mode Date: Fri, 15 Sep 2000 01:52:27 -0400 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com > -----Original Message----- > From: Henning Schulzrinne [mailto:schulzrinne@cs.columbia.edu] > Sent: Thursday, September 14, 2000 9:25 PM > To: Jonathan Rosenberg > Cc: 'Igor Slepchin'; 'Gethin Liddell'; 'sip@lists.bell-labs.com' > Subject: Re: [SIP] DNS SRV records in stateless mode > > > Jonathan Rosenberg wrote: > > > > > > > This seems like a major burden. Basically, if I implement > more than on SRV > > record with equal priority (which I will want for load > balancing), I am > > forced to handle the case that any transaction can now be > spread across > > multiple hosts. This is quite hard - forcing, as you say, > back end state > > sharing for normal operation where otherwise it would only > be needed in > > event of failure. > > I'm still not sure what "normal" operations need this type of state. > Billing was mentioned, but there, you need it anyway in case > of failures > and other strange cases. I'm not talking about billing. What I mean is that if a stateless proxy randomizes for each request retransmission, you are going to see requests for the same transaction sprayed across many servers. Effectively, the stateless proxy has forked. Now, lets say stateless proxy A sends one request for the transaction to B, and then the next request for the same transaction to C. B and C both do their thing, and in all likelihood, forward to the same next hop proxy, D. D detects a merged request, and rejects one of them (say, the one from C), with a 400. To the other, B, it responds with a 300. Now, both B and C forward their respective responses upstream, resulting in a 300 forwarded to A in addition to a 400. A, being stateless, proxies both upstream. Now, the poor UA or proxy in front of A doesn't know which one to look at or ACK. All these extra messages and extra confusion are what I wish to avoid. I agree that a proxy should not count on requests always coming to the same proxy for billing. Thats a separate issue. > > > I think it is not unreasonable to define the SRV > > "contract" that the particular SRV host used for the same > transaction, in > > the case of a stateless proxy, remains unchanged for all > requests in that > > transaction. > > > > Doing so is quite easy by making the randomization process > depend on an > > invariant in the request; in particular, the transaction > ID. So, I would > > compute a transaction ID by hashing to To, From, Call-ID, > CSeq, top Via, > > R-URI, and then, if there are N equal priority records, > choose one by using > > the top CEILING(log(N)) bits as a selector. The result is > still significant > > randomization, but gives you the caching you asked for > anyway, without any > > state. > > If all you want is randomization, hashing just the Call-Id is probably > easiest to implement and describe, since you'd rather want subsequent > requests to go to the same place and I see no large load-sharing > advantage in randomizing across requests. OK. Thats fine. It seems that the finer the better, since we want to achieve the same behavior we would see from a stateful server, which would send all requests in the same transaction to the same next hop server, but otherwise be randomized across transactions. My proposed hash accomplishes exactly 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 Fri Sep 15 02:37: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 CAA15447 for ; Fri, 15 Sep 2000 02:37: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 36C2444360; Fri, 15 Sep 2000 01: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 02A5F44339 for ; Fri, 15 Sep 2000 01:36: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 CAA05888; Fri, 15 Sep 2000 02:38:52 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Fri, 15 Sep 2000 02:33:58 -0400 Message-ID: From: Jonathan Rosenberg To: "'Simon Barber'" , "'sip@lists.bell-labs.com'" Cc: Jonathan Rosenberg Subject: RE: [SIP] Outbound call routing Date: Fri, 15 Sep 2000 02:33:52 -0400 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com > -----Original Message----- > From: Simon Barber [mailto:simon@firetalk.com] > Sent: Thursday, September 14, 2000 3:47 PM > To: sip@lists.bell-labs.com > Cc: Jonathan Rosenberg > Subject: RE: [SIP] Outbound call routing > > > The issue is service transparency with user mobility. User mobility is > supposed to be one of SIP's strengths. > > Solving the problem by having the client add Route to future requests > requires a specific client. This does not fit in well with > user mobility - > the user should be able to log into any generic client, and > still have his > services work. He should not have to use a special client for > his services > to work. This is client mobility, not user mobility. Indeed, he should be able to log into any generic client, and have his services still work. That will happen without a hitch if the user is allowed to register directly with his normal registration server. The glitch is that, for some reason, the local domain has insisted that instead messaging pass through it via some dedicated proxy server. It is a subject of intense debate, apparently, about whether such a server is needed. > > A possible solution would be to add a header like > record-route, but rather > than scoping it to a call leg, scope it to a particular registration. I don't follow how this would work. Where does this new header come from? > > There are many services that get broken by not being able to > track outbound > calls. No disagreement; I think you definitely want to work through your normal registrar/proxy as you move around. -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 Sep 15 02:47: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 CAA15534 for ; Fri, 15 Sep 2000 02:47: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 708AC44393; Fri, 15 Sep 2000 01:46:49 -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 2913A4438B for ; Fri, 15 Sep 2000 01:46: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 CAA05920; Fri, 15 Sep 2000 02:48:33 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Fri, 15 Sep 2000 02:43:39 -0400 Message-ID: From: Jonathan Rosenberg To: "'Prasad, Eshwara'" , "'SIP List'" Subject: RE: [SIP] INVITE with new SDP /higher CSeq Date: Fri, 15 Sep 2000 02:43:33 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="windows-1255" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com > -----Original Message----- > From: Prasad, Eshwara [mailto:eprasad@lucent.com] > Sent: Thursday, September 14, 2000 12:36 PM > To: 'SIP List' > Subject: [SIP] INVITE with new SDP /higher CSeq > > > Hi, > > Am quite new to SIP. The august draft doesnt say anything > on how the user > agent is notified after getting an INVITE from him with a > higher CSeq and > updated SDP parameters. Can anyone let me know hows the User > Agent notified > by the server for success and failure ? I'm not sure I understand the question. If your question is about how the user interface works when a re-INVITE arrives that updates SDP, thats an implementation decision. If your question is about how the user agent client (UAC) that sent the re-invite is able to know that the recipient (the user agent server, UAS), received it, the answer is that re-invites use the same request/response/ACK sequence. So, the UAC will get a 200 OK if the updated SDP is received and is OK, 4xx, 5xx, or 6xx if it failed for some reason. -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 Sep 15 02: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 CAA15576 for ; Fri, 15 Sep 2000 02:53: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 B106A44369; Fri, 15 Sep 2000 01:52:57 -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 227D74433C for ; Fri, 15 Sep 2000 01:52:54 -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 e8F6qSZ05762; Fri, 15 Sep 2000 08:52:28 +0200 (MEST) Received: from ericsson.fi (E0080C7FA22D6.lmf.ericsson.se [131.160.30.48]) by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id JAA25295; Fri, 15 Sep 2000 09:52:28 +0300 (EET DST) Message-ID: <39C1C6BF.E1E2B2AF@ericsson.fi> Date: Fri, 15 Sep 2000 09:50:39 +0300 From: Hisham Khartabil X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Simon Barber Cc: sip@lists.bell-labs.com, Jonathan Rosenberg Subject: Re: [SIP] Outbound call routing 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit I think that a user initiating a transaction and not having to go half way across the world through his/her proxy is a feature, not a disadvantage. If you require a special service, then you need a special client (eg: a configureable client that allows you to specify the outbound proxy). Regards, Hisham Simon Barber wrote: > The issue is service transparency with user mobility. User mobility is > supposed to be one of SIP's strengths. > > Solving the problem by having the client add Route to future requests > requires a specific client. This does not fit in well with user mobility - > the user should be able to log into any generic client, and still have his > services work. He should not have to use a special client for his services > to work. This is client mobility, not user mobility. > > A possible solution would be to add a header like record-route, but rather > than scoping it to a call leg, scope it to a particular registration. > > There are many services that get broken by not being able to track outbound > calls. > > Simon > > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Thursday, September 14, 2000 8:21 AM > To: 'Simon Barber'; 'sip@lists.bell-labs.com' > Subject: RE: [SIP] Outbound call routing > > > -----Original Message----- > > From: Simon Barber [mailto:simon@firetalk.com] > > Sent: Thursday, September 14, 2000 6:35 AM > > To: sip@lists.bell-labs.com > > Subject: [SIP] Outbound call routing > > > > > > This question may be due to my lack of understanding of > > request routing in > > SIP - if so please excuse me! > > > > Is it possible for a registration server to reply to a > > registration request, > > and insist that all future outbound requests be routed to a > > certain proxy? > > No. > > > > > For instance, I want to implement a service that logs all my > > outgoing calls. > > > > To implement this service I must be able to monitor all outgoing call > > requests. If I am always at home, I will be using my usual > > outbound proxy, > > and this can implement the service. The problem occurs if I > > am away from > > home - using a SIP client in another network. This SIP client > > will use it's > > local outbound proxy, and hence requests will not pass > > through my outbound > > proxy. > > This has come up as a subject of discussion a few times, primarily with > wireless. > > If you, as a client, wish to force a request to route through your normal > proxy, you can do so by inserting a Route header into the request, even > though you have not previously gotten a record-route. This is most > definitely a hack; I am not certain it will be completely interoperable > since most proxies expect to see Route only if they previously > record-routed. > > -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 Sep 15 05:44:22 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA16843 for ; Fri, 15 Sep 2000 05:44: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 CC7614433C; Fri, 15 Sep 2000 04:44: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 A54B944338 for ; Fri, 15 Sep 2000 04:44:02 -0400 (EDT) Received: from cvis01.gpt.co.uk (unverified) by cvis29.marconicomms.com (Content Technologies SMTPRS 4.1.5) with ESMTP id ; Fri, 15 Sep 2000 10:32:51 +0100 Received: from marconicomms.com by cvis01.gpt.co.uk with SMTP (8.8.8+Sun/cvms-28) id KAA05144; Fri, 15 Sep 2000 10:32:51 +0100 (BST) Received: by marconicomms.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 8025695B.0034641D ; Fri, 15 Sep 2000 10:32:15 +0100 X-Lotus-FromDomain: MCMAIN@MCEXT From: "Wayne Cutler" To: Jonathan Rosenberg Cc: "'Simon Barber'" , "'sip@lists.bell-labs.com'" Message-ID: <8025695B.0033FAE2.00@marconicomms.com> Date: Fri, 15 Sep 2000 10:28:00 +0100 Subject: RE: [SIP] Outbound call routing 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com (I'm resending this since it didn't go to the list last time due to clumsy fingers). I believe that what Simon is asking for (please shout up if I'm misrepresenting you) is the abiltiy for the registrar/proxy to be able to explicitly assign an address to be used by the SIP user for all future requests during this registration. An analogue would be the h323 GK scenario where there may be a well know RAS (h323 registration) address which may be used by a h323 user to register with his "home" GK. For a succesful registration, the response provides a completely separate address to be used for h225 (call) signalling. The allocation of the h225 address is subject to local policy in the GK. In the SIP case, there doesn't seem to be a way (at least not one that's explicitly stated) for a Registrar to accept a registration request and tell the recipient an address that the registrar/proxy requires to be used for all future requests. Such a capability would be useful, I believe. Regards, Wayne. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Sep 15 11:03: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 LAA20684 for ; Fri, 15 Sep 2000 11:03: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 6AA034435B; Fri, 15 Sep 2000 10:03:23 -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 45B4944338 for ; Fri, 15 Sep 2000 10:03:17 -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 UAA13777 for ; Fri, 15 Sep 2000 20:42:14 GMT Received: from wipro.com ([164.164.28.228]) by ace.mail.wipro.com (Netscape Messaging Server 3.6) with ESMTP id AAA3F4A for ; Fri, 15 Sep 2000 20:29:10 +0530 Message-ID: <39C23CD9.B524A16B@wipro.com> Date: Fri, 15 Sep 2000 20:44:33 +0530 From: "Anuraj Kunnummel Ennai" Organization: Wipro X-Mailer: Mozilla 4.7 [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] Question on IMPP Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Hi, Now that it is known that SIP might not be adopted as the IMPP standard, what happens to the proposed extensions? It seems that SIP benefits by having the IMPP extensions. It might be the ideal way to provide Presence & IM in the SIP network. (An active push model is always desirable) Are there any proposals to keep the proposed IMPP framework as part of SIP and interwork with the possible IMPP protocol? Hope there is more debate on this issue. Thanks Anuraj SIP Designer Wipro Technologies- Bangalore - India _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Sep 15 12:53: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 MAA22486 for ; Fri, 15 Sep 2000 12:53: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 AD2274433F; Fri, 15 Sep 2000 11:53:06 -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 4500A44338 for ; Fri, 15 Sep 2000 11:53:03 -0400 (EDT) Received: from 157.54.9.104 by mail2.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 15 Sep 2000 09:52:59 -0700 (Pacific Daylight Time) Received: by INET-IMC-02 with Internet Mail Service (5.5.2651.58) id ; Fri, 15 Sep 2000 09:52:59 -0700 Message-ID: From: Christian Huitema To: "'Anuraj Kunnummel Ennai'" , sip@lists.bell-labs.com Subject: RE: [SIP] Question on IMPP Date: Fri, 15 Sep 2000 09:52:40 -0700 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com > Now that it is known that SIP might not be > adopted as the IMPP standard, what happens > to the proposed extensions? There are three proposals to the IMPP working group; SIP is one of them. The working group is not currently assessing the merits of the respective proposals; it is busy working on a common reference document, known as CPIM, that essentially specifies the behavior of gateways between the various systems. As you mention, it makes sense in any case to develop the SUBSCRIBE/NOTIFY capability within SIP. In fact, a good way to ensure that SIP *is* chosen as the IMPP standard is to work on the integration of SUBSCRIBE/NOTIFY in your SIP products, and demonstrate interoperability between implementations by multiple vendors. -- Christian Huitema _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Sep 15 14:20: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 OAA23465 for ; Fri, 15 Sep 2000 14:20: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 0B8EA4433F; Fri, 15 Sep 2000 13:19:42 -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 8A50044338 for ; Fri, 15 Sep 2000 13:12:10 -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 LAA29721; Fri, 15 Sep 2000 11:12:22 -0700 Message-ID: <39C26686.960EF1CB@mobilerain.com> Date: Fri, 15 Sep 2000 11:12:22 -0700 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: Anuraj Kunnummel Ennai Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Question on IMPP References: <39C23CD9.B524A16B@wipro.com> Content-Type: multipart/mixed; boundary="------------D2D3DF1500468A46837244AE" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com This is a multi-part message in MIME format. --------------D2D3DF1500468A46837244AE Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Greetings: Anuraj Kunnummel Ennai wrote: > Hi, > Now that it is known that SIP might not be > adopted as the IMPP standard, what happens > to the proposed extensions? When did this happen? The SIP draft for IMPP, though missing few links, is clean to understand and implement. Only the SIP framework provides unfied services development by encapsulating MIME and SDP. > > > It seems that SIP benefits by having the > IMPP extensions. It might be the ideal > way to provide Presence & IM in the SIP network. > (An active push model is always desirable) > Are there any proposals to keep the proposed > IMPP framework as part of SIP and > interwork with the possible IMPP protocol? Why perform interworking between two distinct protocols where one is good enough (excels) to perform the task :-) ? Though biased because we have implemented a SIP based stack -- for IMPP, which on the client side is just 6000 bytes, we feel that SIP provides the necessary framework & guidelines to do more than just IMPP. Just MHO. Regards, Bobby.Sardana@mobilerain.com > > > Hope there is more debate on this issue. > > Thanks > Anuraj > SIP Designer > Wipro Technologies- Bangalore - India > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip --------------D2D3DF1500468A46837244AE 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 --------------D2D3DF1500468A46837244AE-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Sep 15 19:12:22 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA25857 for ; Fri, 15 Sep 2000 19:12: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 8F5BD44369; Fri, 15 Sep 2000 18:12:17 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from bfgbhome.inetint.com (tnt-dal-42-239.dallas.net [209.44.42.239]) by lists.bell-labs.com (Postfix) with ESMTP id D8B3D4433F for ; Fri, 15 Sep 2000 18:12:11 -0400 (EDT) Received: (from brian@localhost) by bfgbhome.inetint.com (8.9.3/8.9.3) id SAA01695; Fri, 15 Sep 2000 18:11:59 -0500 Date: Fri, 15 Sep 2000 18:11:59 -0500 From: "Brian F. G. Bidulock" To: Jonathan Rosenberg Cc: "'sip (E-mail)'" , "'sip-implementors@cs.columbia.edu'" Subject: Re: [SIP] A warning to implementors Message-ID: <20000915181159.A32431@dallas.net> Reply-To: bidulock@dallas.net Mail-Followup-To: Jonathan Rosenberg , "'sip (E-mail)'" , "'sip-implementors@cs.columbia.edu'" References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from jdrosen@dynamicsoft.com on Thu, Sep 14, 2000 at 01:21:41AM -0400 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Jonathan, Jonathan Rosenberg wrote: (Thu, 14 Sep 2000 01:21:41) [snip] > > like this, it is NON-COMPLIANT to rfc2543. Please, folks, fix these things. ^^^^^^^^^^^^^ Please define... -- Brian F. G. Bidulock bidulock@dallas.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 Sep 15 21:21: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 VAA26605 for ; Fri, 15 Sep 2000 21:21: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 8D5004437D; Fri, 15 Sep 2000 20:20:37 -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 DFC544433D for ; Fri, 15 Sep 2000 20:20: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 ; Fri, 15 Sep 2000 18:18:39 -0700 From: "Simon Barber" To: "Hisham Khartabil" Cc: , "Jonathan Rosenberg" Subject: RE: [SIP] Outbound call routing Date: Fri, 15 Sep 2000 18:21:36 -0700 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0027_01C01F41.C8A20310" 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: <39C1C6BF.E1E2B2AF@ericsson.fi> Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com This is a multi-part message in MIME format. ------=_NextPart_000_0027_01C01F41.C8A20310 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I am not proposing that the user initiating a transaction have to go half way across the world, only that when the user registers the registration server can specify that all transactions be routed through a home proxy, if necessary. This way the transactions will be only be routed via the home server if the user has services that require this routing. Simon -----Original Message----- From: Hisham Khartabil [mailto:hisham.khartabil@lmf.ericsson.se] Sent: Thursday, September 14, 2000 11:51 PM To: Simon Barber Cc: sip@lists.bell-labs.com; Jonathan Rosenberg Subject: Re: [SIP] Outbound call routing I think that a user initiating a transaction and not having to go half way across the world through his/her proxy is a feature, not a disadvantage. If you require a special service, then you need a special client (eg: a configureable client that allows you to specify the outbound proxy). Regards, Hisham Simon Barber wrote: > The issue is service transparency with user mobility. User mobility is > supposed to be one of SIP's strengths. > > Solving the problem by having the client add Route to future requests > requires a specific client. This does not fit in well with user mobility - > the user should be able to log into any generic client, and still have his > services work. He should not have to use a special client for his services > to work. This is client mobility, not user mobility. > > A possible solution would be to add a header like record-route, but rather > than scoping it to a call leg, scope it to a particular registration. > > There are many services that get broken by not being able to track outbound > calls. > > Simon > > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Thursday, September 14, 2000 8:21 AM > To: 'Simon Barber'; 'sip@lists.bell-labs.com' > Subject: RE: [SIP] Outbound call routing > > > -----Original Message----- > > From: Simon Barber [mailto:simon@firetalk.com] > > Sent: Thursday, September 14, 2000 6:35 AM > > To: sip@lists.bell-labs.com > > Subject: [SIP] Outbound call routing > > > > > > This question may be due to my lack of understanding of > > request routing in > > SIP - if so please excuse me! > > > > Is it possible for a registration server to reply to a > > registration request, > > and insist that all future outbound requests be routed to a > > certain proxy? > > No. > > > > > For instance, I want to implement a service that logs all my > > outgoing calls. > > > > To implement this service I must be able to monitor all outgoing call > > requests. If I am always at home, I will be using my usual > > outbound proxy, > > and this can implement the service. The problem occurs if I > > am away from > > home - using a SIP client in another network. This SIP client > > will use it's > > local outbound proxy, and hence requests will not pass > > through my outbound > > proxy. > > This has come up as a subject of discussion a few times, primarily with > wireless. > > If you, as a client, wish to force a request to route through your normal > proxy, you can do so by inserting a Route header into the request, even > though you have not previously gotten a record-route. This is most > definitely a hack; I am not certain it will be completely interoperable > since most proxies expect to see Route only if they previously > record-routed. > > -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_0027_01C01F41.C8A20310 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_0027_01C01F41.C8A20310-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Sep 15 21:35: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 VAA27637 for ; Fri, 15 Sep 2000 21:35: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 E17434438B; Fri, 15 Sep 2000 20:35:19 -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 7B8014433D for ; Fri, 15 Sep 2000 20:35:16 -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 ; Fri, 15 Sep 2000 18:33:22 -0700 From: "Simon Barber" To: "'Sip@Lists. Bell-Labs. Com'" Subject: RE: [SIP] Outbound call routing Date: Fri, 15 Sep 2000 18:36:19 -0700 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_003B_01C01F43.D71129B0" 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: <8025695B.00323799.00@marconicomms.com> Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com This is a multi-part message in MIME format. ------=_NextPart_000_003B_01C01F43.D71129B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I'm asking for a bit more than that. The big problem is that the user may be roaming away from his home network, and be logged in to a SIP phone not only outside of the firewall of his home network, but also behind the firewall of a foreign network. Because of this second firewall all SIP requests have to be routed through the local SIP proxy to get to the outside world. However the user would also like his requests to be routed through a proxy server from his home domain - so his services can be provided. This requires that the SIP request have some routing at the SIP protocol layer, not just the internetwork layer. More simply - any of the user's home proxy servers may not be directly reachable from the client, if the user is behind a foreign firewall. Hence simply passing an IP address back in the register reply that the client should send future requests to is not sufficient. We must provide a mechanism whereby the SIP network can transport the requests to a server in the user's home domain. Simon -----Original Message----- From: Wayne Cutler [mailto:Wayne.Cutler@marconi.com] Sent: Friday, September 15, 2000 2:09 AM To: Jonathan Rosenberg Cc: 'Simon Barber'; 'sip Subject: RE: [SIP] Outbound call routing I believe that what Simon is asking for (please shout up if I'm misrepresenting you) is the abiltiy for the registrar/proxy to be able to explicitly assign an address to be used by the SIP user for all future requests during this registration. An analogue would be the h323 GK scenario where there may be a well know RAS (h323 registration) address which may be used by a h323 user to register with his "home" GK. For a succesful registration, the response provides a completely separate address to be used for h225 (call) signalling. The allocation of the h225 address is subject to local policy in the GK - e.g. the GK may be composed of several physical platforms and the allocation may be done on the basis of dynamicaly sharing work/load amongst the platforms and therefore avoiding/minimising pre-provisioning. In the SIP case, there doesn't seem to be a way (at least not one that's explicitly stated) for a Registrar to accept a registration request and tell the recipient an address that the registrar/proxy requires to be used for all future requests. Such a capability would be useful, I believe. Regards, Wayne. ------=_NextPart_000_003B_01C01F43.D71129B0 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_003B_01C01F43.D71129B0-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sat Sep 16 00: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 AAA00074 for ; Sat, 16 Sep 2000 00: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 037A14438B; Fri, 15 Sep 2000 23:47:24 -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 174164433D for ; Fri, 15 Sep 2000 21:05: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 WAA09791; Fri, 15 Sep 2000 22:03:43 -0400 (EDT) Message-ID: <39C2D4FE.F940AF86@cs.columbia.edu> Date: Fri, 15 Sep 2000 22:03:42 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Jo Hornsby Cc: Jonathan Rosenberg , "'Neil Deason'" , sip@lists.bell-labs.com Subject: Re: [SIP] Stateless Proxy References: <003301c01e30$b2bbf5e0$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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Jo Hornsby wrote: > > Seems right to me; the only exceptions are of course if > Record-Route were present, and if there were no Contact (in > which case I guess one uses To). Clarified the Section "Caller Receives Response to Initial Request" to read, in part: If the 200 (OK) response contained a \header{Contact} header field, it is copied into the \header{Request-URI} of the {\ACK} or {\BYE} requests. Otherwise, the \header{To} header field address is copied into the \header{Request-URI}. > > It might be helpful to have some clarification here in the spec; > the current definition is: > Outbound proxy: A proxy that is located near the originator of > requests. It receives all outgoing requests from a particular UAC, > ^^^ > including those requests whose Request-URLs identify a host other > than the outbound proxy. The outbound proxy sends these requests, > after any local processing, to the address indicated in the > request-URI. (All other proxy servers are simply referred as > proxies, not inbound proxies.) > > I would also note Section 11.4: > If a UAC does not support DNS resolution or the full > Record-Route/Route mechanism, it MAY send all requests to a > locally configured outbound proxy. In that case, that proxy > behaves as described above. The UAC MUST, however, perform the > mapping of Record-Route to Route header fields and MUST include > all Route header fields, i.e., the UAC does not remove the first > Route header field. > > Thus it's potentially a bit messy (although will work) if an > outbound proxy decides to add itself in Record-Route, since > re-INVITEs, or what have you, are likely to needlessly loop > through the outbound proxy (okay -- so the proxy could be > intelligent here). > > I think Henning's observation on most UACs using an outbound > proxy for _every_ request is about right (after all, that is > what the spec says); however, as Johnathan points out, just > using it for initial request would seem to give the necessary > flexibility. > There is a slight twist here. A minimal client does NOT have to implement Record-Route/Route (only a firewall-friendly client does). For firewalls to work, the "every request" rule seem safest. The only drawback is an increase in messages for those outbound proxies that really only want to see the first request. I don't recall seeing an example of a practical application where this would be required. All examples where proxies want to be in the path are for the whole call, as for firewalls, billing, and ACDs. One could make the distinction that minimal clients always send to the outbound proxies and others listen to the Record-Route/Route info, but I somehow don't see that adding yet another obscure distinction to the spec as helpful. Thus, since the negative consequences of sending subsequent requests to the proxy is far greater than sending an extra ACK, BYE or re-INVITE to a proxy server that could do without them, the simple "always" rule seems least likely to cause surprises and debates about backward compatibility. -- 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 Sat Sep 16 00:49: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 AAA00102 for ; Sat, 16 Sep 2000 00:49: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 C927F44396; Fri, 15 Sep 2000 23:47:28 -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 747494438B for ; Fri, 15 Sep 2000 20:27:54 -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 VAA08392; Fri, 15 Sep 2000 21:27:48 -0400 (EDT) Message-ID: <39C2CC94.98FD97C6@cs.columbia.edu> Date: Fri, 15 Sep 2000 21:27:48 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Simon Barber Cc: Hisham Khartabil , sip@lists.bell-labs.com, Jonathan Rosenberg Subject: Re: [SIP] Outbound call routing 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Forcing routing seems yet another user configuration parameter, along with other service parameters that I'd like to keep even as I change terminals. Thus, this is probably best addressed as user configuration data downloaded from the REGISTER server, along with things like speed-dial buttons or, say, CFB/CFNA end system behavior. If we define an extension of CPL that's tailored to user agents, this might be a useful feature to have, as one may want to make this feature conditional. -- 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 Sat Sep 16 00:51: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 AAA00118 for ; Sat, 16 Sep 2000 00:51: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 97E144439A; Fri, 15 Sep 2000 23:47:32 -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 052154433F for ; Fri, 15 Sep 2000 18:52: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 TAA04460; Fri, 15 Sep 2000 19:52:08 -0400 (EDT) Message-ID: <39C2B628.454F9973@cs.columbia.edu> Date: Fri, 15 Sep 2000 19:52:08 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Itamar Gilad Cc: "'SIP List'" Subject: Re: [SIP] Via header and case sensitivity 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Itamar Gilad wrote: > > In the bakeoff SIP Torture Tests page > (http://www.cs.columbia.edu/~hgs/sip/bakeoff/torture.html) under the > "Illegal but shouldn't crash you" section the following test appears: > > "case-sensitive fields in the wrong case (E.g. Via: sip/2.0/udp)" > > I'm not sure why this is illegal. In 6.46.6 Via syntax is given as: > > Via = ( "Via" | "v") ":" 1#( sent-protocol sent-by > *( ";" via-params ) [ comment ] ) > ... > sent-protocol = protocol-name "/" protocol-version "/" transport > protocol-name = "SIP" | token > protocol-version = token > transport = "UDP" | "TCP" | token > ... > > In C it says: > > "literal" > > Quotation marks surround literal text. Unless stated otherwise, the text > is case-insensitive. Indeed, to be consistent with HTTP, etc., all tokens (except request methods) must be CI. I fixed the example. > > So basically the protocol name 'sip' and the transport 'udp' should be OK. > > While we're on the subject, 2543bis-00 section 6.6 (Header Field format) > specifies the following: > "Unless otherwise noted, comparisons are case-sensitive. However, any > parameters preceded by semi-colons are case-insensitive, while any quoted > string literals are compared taken case into consideration." > > However this was removed from bis-01 and bis-02. So what is the default > behavior for header values (quoted strings or otherwise) now? Section 6.5 in -02: \begin{changebar} Unless otherwise stated, parameter names, parameter values and tokens are case-insensitive. \end{changebar} Again, this corresponds to standard HTTP and other BNF-based protocol rules (including RFC 2234). Values in quotation marks are case-sensitive, although I can't think of an instance where this would matter, beyond the "realm" parameter value (which RFC 2617 defines as cs). -- 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 Sat Sep 16 00: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 AAA00161 for ; Sat, 16 Sep 2000 00:54: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 B950D443A2; Fri, 15 Sep 2000 23:47:38 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from turin.trillium.com (turin.trillium.com [38.187.146.197]) by lists.bell-labs.com (Postfix) with ESMTP id 8FC9B4433D for ; Fri, 15 Sep 2000 21:04:05 -0400 (EDT) Received: from aiglos.trillium.com (smtp.trillium.com [192.168.3.20]) by turin.trillium.com (8.11.0/8.11.0) with ESMTP id e8G28UH03035 for ; Fri, 15 Sep 2000 19:08:30 -0700 (PDT) Received: from aega.trillium.com (aega.trillium.com [192.168.1.19]) by aiglos.trillium.com (8.9.3/8.9.3) with ESMTP id TAA10744 for ; Fri, 15 Sep 2000 19:03:48 -0700 (PDT) Received: by aega.trillium.com with Internet Mail Service (5.5.2650.21) id ; Fri, 15 Sep 2000 18:55:21 -0700 Message-ID: <8BBD33A986C5D311804000902719FF5DC09A93@aega.trillium.com> From: Aseem Agarwal To: sip@lists.bell-labs.com Date: Fri, 15 Sep 2000 18:55:20 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] SIP message transport on TCP Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Is there any application level framing mechanism (like TPKT -rfc 1006 for H.225/245 in H.323 network) for SIP when used over TCP ? If not, then each application will be required to collate the data read in each TCP-recv till it gets the full message. Any comments will be appreciated. -aseem _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sat Sep 16 00:57: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 AAA00175 for ; Sat, 16 Sep 2000 00:57: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 2252B443A6; Fri, 15 Sep 2000 23:47:43 -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 6D9914438B for ; Fri, 15 Sep 2000 20:21:36 -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 VAA08096; Fri, 15 Sep 2000 21:21:23 -0400 (EDT) Message-ID: <39C2CB13.DB2FD460@cs.columbia.edu> Date: Fri, 15 Sep 2000 21:21:23 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.72 [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] DNS SRV records in stateless mode 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit To address the random routing problem, I've tentatively added the following wording to the section on SRV usage (1.4.2): Within a transaction, a stateless proxy {\MUST} always select the same destination within the set of hosts with the same priority. This can be accomplished, for example, by using the modulo $N$ of a hash of the \header{Call-ID} value or some other combination of transaction-identifying headers as the uniform random number described in the weighting algorithm of RFC 2782. Here, $N$ is the sum of weights within the priority class. This is somewhat messier than just taking bits, in order to satisfy the non-even weighting rules. -- 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 Sat Sep 16 08:38: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 IAA14580 for ; Sat, 16 Sep 2000 08:38: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 5F2A144352; Sat, 16 Sep 2000 07:38:12 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from smtp-out2.bellatlantic.net (smtp-out2.bellatlantic.net [199.45.39.157]) by lists.bell-labs.com (Postfix) with ESMTP id 087BB44341 for ; Sat, 16 Sep 2000 07:38:09 -0400 (EDT) Received: from cs.columbia.edu (adsl-151-198-20-48.bellatlantic.net [151.198.20.48]) by smtp-out2.bellatlantic.net (8.9.1/8.9.1) with ESMTP id IAA23751; Sat, 16 Sep 2000 08:37:57 -0400 (EDT) Message-ID: <39C3699B.F06685A6@cs.columbia.edu> Date: Sat, 16 Sep 2000 08:37:47 -0400 From: Henning Schulzrinne X-Mailer: Mozilla 4.7 [en]C-CCK-MCD BA45DSL (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Aseem Agarwal Cc: sip@lists.bell-labs.com Subject: Re: [SIP] SIP message transport on TCP References: <8BBD33A986C5D311804000902719FF5DC09A93@aega.trillium.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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit The "framing" is described in the spec and is almost the same as that used billions of times a day by HTTP servers. Aseem Agarwal wrote: > > Is there any application level framing mechanism (like TPKT -rfc 1006 > for H.225/245 in H.323 network) for SIP when used over TCP ? > If not, then each application will be required to collate the > data read in each TCP-recv till it gets the full message. > > Any comments will be appreciated. > > -aseem > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > 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 Sat Sep 16 09:50: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 JAA14957 for ; Sat, 16 Sep 2000 09:50: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 4A7374434E; Sat, 16 Sep 2000 08:50:08 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from microappliances.com (unknown [216.103.255.138]) by lists.bell-labs.com (Postfix) with SMTP id 5164F44341 for ; Sat, 16 Sep 2000 08:50:04 -0400 (EDT) Received: (qmail 5171 invoked by uid 100); 16 Sep 2000 13:23:12 -0000 Date: 16 Sep 2000 13:23:12 -0000 Message-ID: <20000916132312.5170.qmail@microappliances.com> From: shh@microappliances.com To: Henning Schulzrinne Reply-To: shh@microappliances.com Cc: Jo Hornsby , Jonathan Rosenberg , "'Neil Deason'" , sip@lists.bell-labs.com References: <003301c01e30$b2bbf5e0$4e34c3c1@ubiquity.co.uk> <39C2D4FE.F940AF86@cs.columbia.edu> In-Reply-To: <39C2D4FE.F940AF86@cs.columbia.edu> MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit Subject: Re: [SIP] Stateless Proxy Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 8bit I would like some further clarification on this change: If the Contact is used as the URI for ACKs and BYEs, what happens when two users both behind their own firewalls are using numerically the same private addresses and the Contact: specified is a private address. I guess it all depends on how a proxy is going to use this information. If it is going to use for routing purposes we may have trouble. Shiv as Quoting Henning Schulzrinne : > Jo Hornsby wrote: > > > > > Seems right to me; the only exceptions are of course if > > Record-Route were present, and if there were no Contact (in > > which case I guess one uses To). > > Clarified the Section \"Caller Receives Response to Initial Request\" to > read, in part: > > If the 200 (OK) response contained a \\header{Contact} header field, it > is copied into the \\header{Request-URI} of the {\\ACK} or {\\BYE} > requests. Otherwise, the \\header{To} header field address is copied > into the \\header{Request-URI}. > > > > > > It might be helpful to have some clarification here in the spec; > > the current definition is: > > Outbound proxy: A proxy that is located near the originator of > > requests. It receives all outgoing requests from a particular UAC, > > ^^^ > > including those requests whose Request-URLs identify a host other > > than the outbound proxy. The outbound proxy sends these requests, > > after any local processing, to the address indicated in the > > request-URI. (All other proxy servers are simply referred as > > proxies, not inbound proxies.) > > > > I would also note Section 11.4: > > If a UAC does not support DNS resolution or the full > > Record-Route/Route mechanism, it MAY send all requests to a > > locally configured outbound proxy. In that case, that proxy > > behaves as described above. The UAC MUST, however, perform the > > mapping of Record-Route to Route header fields and MUST include > > all Route header fields, i.e., the UAC does not remove the first > > Route header field. > > > > Thus it\'s potentially a bit messy (although will work) if an > > outbound proxy decides to add itself in Record-Route, since > > re-INVITEs, or what have you, are likely to needlessly loop > > through the outbound proxy (okay -- so the proxy could be > > intelligent here). > > > > I think Henning\'s observation on most UACs using an outbound > > proxy for _every_ request is about right (after all, that is > > what the spec says); however, as Johnathan points out, just > > using it for initial request would seem to give the necessary > > flexibility. > > > > There is a slight twist here. A minimal client does NOT have to > implement Record-Route/Route (only a firewall-friendly client does). For > firewalls to work, the \"every request\" rule seem safest. The only > drawback is an increase in messages for those outbound proxies that > really only want to see the first request. I don\'t recall seeing an > example of a practical application where this would be required. All > examples where proxies want to be in the path are for the whole call, as > for firewalls, billing, and ACDs. > > One could make the distinction that minimal clients always send to the > outbound proxies and others listen to the Record-Route/Route info, but I > somehow don\'t see that adding yet another obscure distinction to the > spec as helpful. > > Thus, since the negative consequences of sending subsequent requests to > the proxy is far greater than sending an extra ACK, BYE or re- INVITE to > a proxy server that could do without them, the simple \"always\" rule > seems least likely to cause surprises and debates about backward > compatibility. > > -- > 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 Sat Sep 16 22:14: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 WAA19687 for ; Sat, 16 Sep 2000 22:14: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 580C544345; Sat, 16 Sep 2000 21:13:54 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from md3.vsnl.net.in (md3.vsnl.net.in [202.54.6.35]) by lists.bell-labs.com (Postfix) with ESMTP id 6247444340 for ; Sat, 16 Sep 2000 21:13:48 -0400 (EDT) Received: from jana ([203.197.129.188]) by md3.vsnl.net.in (8.9.3/8.9.3) with SMTP id HAA22591 for ; Sun, 17 Sep 2000 07:38:15 +0530 (IST) Message-ID: <000701c0204c$aa5870e0$38c9a8c0@labs> From: "Pathangi N Janardhanan" To: Date: Sun, 17 Sep 2000 07:40:31 +0530 Organization: HCL Technologies India Ltd. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Subject: [SIP] a question on 183 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Hi, The caller sends his capabilities in the SDP description in INVITE. Is early media meant for one way communication towards the caller for call progress anouncements. In that case why do we need the SDP in the 183, since the caller has already expressed the capability in INVITE? Thanks Jana _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sun Sep 17 03:41: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 DAA05183 for ; Sun, 17 Sep 2000 03:41: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 9DBB44434B; Sun, 17 Sep 2000 02:40:45 -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 0FDEE44340 for ; Sun, 17 Sep 2000 02:40:42 -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, 17 Sep 2000 10:39:55 +0200 Received: by NT-MAIL with Internet Mail Service (5.5.2650.21) id ; Sun, 17 Sep 2000 10:40:21 +0200 Message-ID: From: Itamar Gilad To: "'Henning Schulzrinne'" , Itamar Gilad Cc: "'SIP List'" Subject: RE: [SIP] Via header and case sensitivity Date: Sun, 17 Sep 2000 10:40:18 +0200 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com > -----Original Message----- > From: Henning Schulzrinne [mailto:schulzrinne@cs.columbia.edu] > Sent: Sat, September 16, 2000 1:52 AM > To: Itamar Gilad > Cc: 'SIP List' > Subject: Re: [SIP] Via header and case sensitivity > > > Itamar Gilad wrote: > > > > In the bakeoff SIP Torture Tests page > > (http://www.cs.columbia.edu/~hgs/sip/bakeoff/torture.html) under the > > "Illegal but shouldn't crash you" section the following > test appears: > > > > "case-sensitive fields in the wrong case (E.g. Via: sip/2.0/udp)" > > > > I'm not sure why this is illegal. In 6.46.6 Via syntax is given as: > > > > Via = ( "Via" | "v") ":" 1#( sent-protocol sent-by > > *( ";" via-params ) [ comment ] ) > > ... > > sent-protocol = protocol-name "/" protocol-version "/" > transport > > protocol-name = "SIP" | token > > protocol-version = token > > transport = "UDP" | "TCP" | token > > ... > > > > In C it says: > > > > "literal" > > > > Quotation marks surround literal text. Unless stated > otherwise, the text > > is case-insensitive. > > Indeed, to be consistent with HTTP, etc., all tokens (except request > methods) must be CI. I fixed the example. > > > > > So basically the protocol name 'sip' and the transport > 'udp' should be OK. > > > > While we're on the subject, 2543bis-00 section 6.6 (Header > Field format) > > specifies the following: > > "Unless otherwise noted, comparisons are case-sensitive. > However, any > > parameters preceded by semi-colons are case-insensitive, > while any quoted > > string literals are compared taken case into consideration." > > > > However this was removed from bis-01 and bis-02. So what > is the default > > behavior for header values (quoted strings or otherwise) now? > > Section 6.5 in -02: > > \begin{changebar} > Unless otherwise stated, parameter names, parameter values and tokens > are > case-insensitive. > \end{changebar} > I see, but until now as I read this sentence I was under the impression that it was referring only to header parameters preceded by semi-colons (as opposed to header fields). Maybe my understanding of what constitutes a 'header parameter' is wrong, but I found the bis-00 wording more straight forward. Itamar > Again, this corresponds to standard HTTP and other BNF-based protocol > rules (including RFC 2234). Values in quotation marks are > case-sensitive, although I can't think of an instance where this would > matter, beyond the "realm" parameter value (which RFC 2617 defines as > cs). > > -- > 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 Sun Sep 17 05:15: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 FAA07185 for ; Sun, 17 Sep 2000 05:15: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 080E144373; Sun, 17 Sep 2000 04:15:45 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from hotmail.com (lc7-lfd34.law5.hotmail.com [64.4.11.56]) by lists.bell-labs.com (Postfix) with ESMTP id 66FB544340 for ; Sun, 17 Sep 2000 04:15:42 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 17 Sep 2000 02:15:39 -0700 Received: from 164.164.6.34 by www.hotmail.msn.com with HTTP; Sun, 17 Sep 2000 09:15:39 GMT X-Originating-IP: [164.164.6.34] From: "rahul pande" To: sip@lists.bell-labs.com Date: Sun, 17 Sep 2000 14:45:39 IST Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 17 Sep 2000 09:15:39.0619 (UTC) FILETIME=[D8CA6330:01C02087] Subject: [SIP] a query.......... Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com hello all, I mailed the following query to confctrl@isi.edu but no responded and i am eagerly looking for a reply In SDP rfc we have the definition of a= as follows : a= : in the above case there will be few registered s such as "charset" but i searched through the iana site i couldn't get the information Can someone please give me these details, will "the grammar for the of that " be also available there. Does sdplang attribute mean that my session itself is described in that language...... Please reply to the above query i know this is not a proper mailing list to ask such questions but i need these information for working in the SIP stack only. Thanking you all, 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 Sun Sep 17 23:23: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 XAA15529 for ; Sun, 17 Sep 2000 23:23: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 98C994435F; Sun, 17 Sep 2000 22:22:56 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mail15a.boca15-verio.com (mail15a.boca15-verio.com [208.55.91.57]) by lists.bell-labs.com (Postfix) with SMTP id B7C074433B for ; Sun, 17 Sep 2000 22:22:53 -0400 (EDT) Received: from www.snowshore.com (128.241.144.247) by mail15a.boca15-verio.com (RS ver 1.0.57s) with SMTP id 15671862; Sun, 17 Sep 2000 23:22:33 -0400 (EDT) Message-ID: <000701c0211f$6bf07f40$0201015a@WinProxy> From: "Eric Burger" To: "Jonathan Rosenberg" Cc: References: Subject: Re: [SIP] A warning to implementors Date: Fri, 15 Sep 2000 13:06:24 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Loop-Detect: 1 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit I agree that an arbitrary limit of 16 characters is simply wrong. However, saying that the field length should be unbounded is not a good idea, either. Arbitrary-length fields are not really consistent with Section 3 of RFC 2543. This section suggests a maximum SIP message length of 1500 bytes (the LAN MTU). Such a suggestion is very important for embedded applications and UDP applications. I would go so far as to suggest that we set a maximum length to a SIP header field of 1000 bytes. This enables fixed-memory, embedded applications to run without barfing. 1000 bytes is effectively infinite. If you don't like 1000 bytes, how about 4095? The point is to have some bound, even if it looks unreasonably big. The only place I can find where we could realistically run in to problems with this are the Response-Key: or Authorization: fields. ----- Original Message ----- From: "Jonathan Rosenberg" To: "'sip (E-mail)'" ; Sent: Thursday, September 14, 2000 1:21 AM Subject: [SIP] A warning to implementors [snip] > The SIP spec in no way whatsoever says that tokens and other assorted > constructions are limited in length. If your implementation barfs on things > like this, it is NON-COMPLIANT to rfc2543. Please, folks, fix these things. [snip] _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Sep 18 00:10: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 AAA16195 for ; Mon, 18 Sep 2000 00:10: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 17C1844350; Sun, 17 Sep 2000 23:10: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 B56884433B for ; Sun, 17 Sep 2000 23:09: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 AAA01174; Mon, 18 Sep 2000 00:11:39 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Mon, 18 Sep 2000 00:06:39 -0400 Message-ID: From: Jonathan Rosenberg To: "'rahul pande'" , "'sip@lists.bell-labs.com'" Subject: RE: [SIP] a query.......... Date: Mon, 18 Sep 2000 00:06:38 -0400 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com > -----Original Message----- > From: rahul pande [mailto:panderahul@hotmail.com] > Sent: Sunday, September 17, 2000 10:46 AM > To: sip@lists.bell-labs.com > Subject: [SIP] a query.......... > > > hello all, > I mailed the following query to confctrl@isi.edu but no > responded and > i am eagerly looking for a reply > > In SDP rfc we have the definition of a= as follows : > a= : > in the above case there will be few registered > s such as > "charset" but i searched through the iana site i couldn't get the > information Can someone please give me these details, will > "the grammar for > the of that " be also available there. Most (if not all) of the attributes in usage are defined within the SDP specification itself. I know that the preconditions draft http://www.normos.org/ietf/draft/draft-manyfolks-sip-resource-01.txt defines a few also. > > Does sdplang attribute mean that my session itself is > described in > that language...... those pieces like the subject, yes. Protocol parameters like "audio" and "video", of course not. -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 Sep 18 00:16:29 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA16210 for ; Mon, 18 Sep 2000 00:16: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 038F844391; Sun, 17 Sep 2000 23:15:54 -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 EFC9C44377 for ; Sun, 17 Sep 2000 23:15:50 -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 AAA01254; Mon, 18 Sep 2000 00:17:31 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Mon, 18 Sep 2000 00:12:31 -0400 Message-ID: From: Jonathan Rosenberg To: "'Pathangi N Janardhanan'" , "'sip@lists.bell-labs.com'" Subject: RE: [SIP] a question on 183 Date: Mon, 18 Sep 2000 00:12:30 -0400 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com The SDP is needed largely to confirm that this is going to happen, and also to provide address/ports for RTCP for feedback. If the early media is unidirectional, the SDP in the 183 would also indicate that using the sendonly attribute. -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: Pathangi N Janardhanan [mailto:janar@netlab.hcltech.com] > Sent: Saturday, September 16, 2000 10:11 PM > To: sip@lists.bell-labs.com > Subject: [SIP] a question on 183 > > > Hi, > > The caller sends his capabilities in the SDP description in > INVITE. Is early media meant for one way communication > towards the caller for call progress anouncements. In that > case why do we need the SDP in the 183, since the caller > has already expressed the capability in INVITE? > > Thanks > Jana > > > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > 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 Sep 18 00:59: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 AAA16414 for ; Mon, 18 Sep 2000 00:59: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 53F0744377; Sun, 17 Sep 2000 23:59: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 32C9E4433B for ; Sun, 17 Sep 2000 23:59: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 AAA01392; Mon, 18 Sep 2000 00:43:09 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Mon, 18 Sep 2000 00:38:09 -0400 Message-ID: From: Jonathan Rosenberg To: "'Henning Schulzrinne'" , "'Jo Hornsby'" Cc: Jonathan Rosenberg , "'Neil Deason'" , "'sip@lists.bell-labs.com'" Subject: RE: [SIP] Stateless Proxy Date: Mon, 18 Sep 2000 00:38:09 -0400 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com > -----Original Message----- > From: Henning Schulzrinne [mailto:schulzrinne@cs.columbia.edu] > Sent: Friday, September 15, 2000 10:04 PM > To: Jo Hornsby > Cc: Jonathan Rosenberg; 'Neil Deason'; sip@lists.bell-labs.com > Subject: Re: [SIP] Stateless Proxy > > > Jo Hornsby wrote: > > > > > Seems right to me; the only exceptions are of course if > > Record-Route were present, and if there were no Contact (in > > which case I guess one uses To). > > Clarified the Section "Caller Receives Response to Initial Request" to > read, in part: > > If the 200 (OK) response contained a \header{Contact} header > field, it > is copied into the \header{Request-URI} of the {\ACK} or {\BYE} > requests. Otherwise, the \header{To} header field address is copied > into the \header{Request-URI}. This is still not correct; it would only be true if the 200 OK had no Record-Route parameters. Why not just reference the section on Record-Route, and say that you need to set the Route header + request URI as defined there? > > Thus it's potentially a bit messy (although will work) if an > > outbound proxy decides to add itself in Record-Route, since > > re-INVITEs, or what have you, are likely to needlessly loop > > through the outbound proxy (okay -- so the proxy could be > > intelligent here). > > > > I think Henning's observation on most UACs using an outbound > > proxy for _every_ request is about right (after all, that is > > what the spec says); however, as Johnathan points out, just > > using it for initial request would seem to give the necessary > > flexibility. > > > > There is a slight twist here. A minimal client does NOT have to > implement Record-Route/Route (only a firewall-friendly client > does). These days, I'm not sure that such a minimal client is worth anything at all. Realistically, every UA needs to support Route and Record-Route if they ever want to leave the lab. For > firewalls to work, the "every request" rule seem safest. The only > drawback is an increase in messages for those outbound proxies that > really only want to see the first request. I don't recall seeing an > example of a practical application where this would be required. All > examples where proxies want to be in the path are for the > whole call, as > for firewalls, billing, and ACDs. Its a bit of a stretch, but I could imagine large networks that have a hierarchy of outbound proxies. The first stage determine which peer SIP network to terminate to, and then the second stage would be a firewall/nat controlling proxy. The second stage would need to see every message, but the first stage wouldn't. This would mostly be an issue for phone numbers. > > One could make the distinction that minimal clients always send to the > outbound proxies and others listen to the Record-Route/Route > info, but I > somehow don't see that adding yet another obscure distinction to the > spec as helpful. Yuck. We should be completely consistent here. > > Thus, since the negative consequences of sending subsequent > requests to > the proxy is far greater than sending an extra ACK, BYE or > re-INVITE to > a proxy server that could do without them, the simple "always" rule > seems least likely to cause surprises and debates about backward > compatibility. Here's an issue, though. With this behavior, a local outbound proxy should never record-route. Since if it does, it will end up getting requests that have the top Route header pointing to itself. These *may* work, since we have just agreed to disable loop detection when Route is present, and the addition of the additional via branch ID would make the looped request look different from a transaction perspective. Even so, its not pretty. Problem is, local outbound proxy is a logical role. For different requests, it may not even be sure whether it is, in fact, a local outbound proxy for a given request. The proxy will thus need logic to determine for which requests it is a local outbound proxy, and for those, disable RR, and for others, keep it on. This is quite a pain. Seems simpler that a proxy always record-routes if it wants subsequent requests for the same call. -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 Sep 18 01:08: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 BAA16886 for ; Mon, 18 Sep 2000 01:08: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 69BE44439D; Mon, 18 Sep 2000 00:07:42 -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 C9EB74433B for ; Mon, 18 Sep 2000 00:07:38 -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 AAA01433; Mon, 18 Sep 2000 00:58:17 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Mon, 18 Sep 2000 00:53:17 -0400 Message-ID: From: Jonathan Rosenberg To: "'Henning Schulzrinne'" , Jonathan Rosenberg Cc: "'sip@lists.bell-labs.com'" Subject: RE: [SIP] DNS SRV records in stateless mode Date: Mon, 18 Sep 2000 00:53:16 -0400 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com > -----Original Message----- > From: Henning Schulzrinne [mailto:schulzrinne@cs.columbia.edu] > Sent: Friday, September 15, 2000 9:21 PM > To: Jonathan Rosenberg > Cc: 'sip@lists.bell-labs.com' > Subject: Re: [SIP] DNS SRV records in stateless mode > > > To address the random routing problem, I've tentatively added the > following wording to the section on SRV usage (1.4.2): > > Within a transaction, a stateless proxy {\MUST} always select > the same > destination within the set of hosts with the same priority. > This can be > accomplished, for example, by using the modulo $N$ of a hash of the > \header{Call-ID} value or some other combination of > transaction-identifying headers as the uniform random number described > in the weighting algorithm of RFC 2782. Here, $N$ is the sum > of weights > within the priority class. > > > > This is somewhat messier than just taking bits, in order to > satisfy the > non-even weighting rules. Yes, I had forgotten about that. One small change. As worded, it seems like this only applies to stateless proxies, so that stateful ones could send to diffrent destinations. How about: Within a transaction, a proxy {\MUST} always select the same destination within the set of hosts with the same priority. This can be accomplished statelessly, for example, by using the modulo $N$ of a hash of the \header{Call-ID} value or some other combination of transaction-identifying headers as the uniform random number described in the weighting algorithm of RFC 2782. Here, $N$ is the sum of weights within the priority class. All I did was remove stateless from the top line and add it into the third. -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 Sep 18 02:09: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 CAA29031 for ; Mon, 18 Sep 2000 02:09: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 7E7D44439A; Mon, 18 Sep 2000 01:09:00 -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 4B5E54433B for ; Mon, 18 Sep 2000 01:08: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 CAA01587; Mon, 18 Sep 2000 02:10:48 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Mon, 18 Sep 2000 02:05:48 -0400 Message-ID: From: Jonathan Rosenberg To: "'Eric Burger'" , Jonathan Rosenberg Cc: "'sip@lists.bell-labs.com'" Subject: RE: [SIP] A warning to implementors Date: Mon, 18 Sep 2000 02:05:48 -0400 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com > -----Original Message----- > From: Eric Burger [mailto:eburger@snowshore.com] > Sent: Friday, September 15, 2000 1:06 PM > To: Jonathan Rosenberg > Cc: sip@lists.bell-labs.com > Subject: Re: [SIP] A warning to implementors > > > I agree that an arbitrary limit of 16 characters is simply > wrong. However, > saying that the field length should be unbounded is not a > good idea, either. > > Arbitrary-length fields are not really consistent with > Section 3 of RFC > 2543. This section suggests a maximum SIP message length of > 1500 bytes (the > LAN MTU). Thats another number which is rapidly being approached (actually, I've seen it exceeded in some complex scenarios). I would also warn people against dropping requests that exceed this. Such a suggestion is very important for embedded > applications and > UDP applications. I would go so far as to suggest that we > set a maximum > length to a SIP header field of 1000 bytes. This enables > fixed-memory, > embedded applications to run without barfing. 1000 bytes is > effectively > infinite. Really? 1000 is much less that infinite last I checked. I understand the issues for embedded systems. Its nice to make assumptions about sizes so you can pre-allocate buffers and things like that. But, these ultimately lead to interoperability problems. The bigger the number, the less likely, and the farther into the future the problems arise. So, how big is big enough? Thats the question. Definitely not 1000 for a header field. If you don't like 1000 bytes, how about 4095? The > point is to > have some bound, even if it looks unreasonably big. > > The only place I can find where we could realistically run in > to problems > with this are the Response-Key: or Authorization: fields. No; the problem is also with fields like Via and Record-Route; we are seeing these fields get increasingly populated with stuff. This is because these headers have the "stack" property and come back to you in some form or another. -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 Sep 18 03:09: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 DAA29315 for ; Mon, 18 Sep 2000 03: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 E255F44393; Mon, 18 Sep 2000 02:09: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 7ED8C4436B for ; Mon, 18 Sep 2000 02:09:01 -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 DAA01787; Mon, 18 Sep 2000 03:10:53 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Mon, 18 Sep 2000 03:05:53 -0400 Message-ID: From: Jonathan Rosenberg To: =?iso-8859-1?Q?=27G=E9rard_GONNET=27?= , "'sip@lists.bell-labs.com'" Cc: "'lsteffan@atos-group.com'" , "'SEVESTRE Thibaut'" Subject: RE: [SIP] SIP syntax in 2543-bis-01 Date: Mon, 18 Sep 2000 03:05:53 -0400 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA29315 -----Original Message----- From: Gérard GONNET [mailto:ggonnet@atos-group.com] Sent: Tuesday, September 12, 2000 9:06 AM To: sip@lists.bell-labs.com Cc: lsteffan@atos-group.com; SEVESTRE Thibaut Subject: [SIP] SIP syntax in 2543-bis-01 >The syntax in the draft 2543bis-01, page 18, resulting from a modification of the >former release, can produce some ambiguous interpretation. >This concern the element, described as : >. >(was described in the former release as , notice that the > element is not optional). Hmm. Not sure why that happened; I can see no good reason for just having a password. Henning? -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 Mon Sep 18 03:37:22 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA29442 for ; Mon, 18 Sep 2000 03:37:22 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id ADB5E443A6; Mon, 18 Sep 2000 02:37:00 -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 C72A14433B for ; Mon, 18 Sep 2000 02:36:41 -0400 (EDT) Received: from bigboy ([210.212.215.169]) by hd2.dot.net.in (8.8.8/8.8.8) with SMTP id MAA03063 for ; Mon, 18 Sep 2000 12:33:07 +0530 (IST) Message-ID: <002f01c0213f$5cdcbbc0$a9d7d4d2@bigboy> Reply-To: "farhan" From: "farhan" To: "sip" Date: Mon, 18 Sep 2000 12:39:16 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Subject: [SIP] words of 2543 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit i dunno if i am being a little brash here. but the interpretation of 2543 is becoming more and more complex. each word within 2543 text seems to carry an enormous amount of thought and behavourial pattern with it. while as a text, 2543 is pretty good and solid, it is an extremely tough read. i guess that it is written as if it were a program. it stays away from explaining things lets implicit remain implicit and does not point out to the pitfalls within. that was one of the reasons why i had earlier raised the issue of documenting an implementor's FAQ. most of the issues raised in this list are answered by dr. schulzrinne or dr. rosenberg lucidly and clearly until they are asked again. i guess that is must be pretty boring for them to keep explaining the same points over and over again. sip is simple. but some discussions make it seem like a legal discussion of some arcane statute of british colonial law (well i have had those too, while working on a law database). lately, i have discovered that grepping through the archives of this list usually answer most of the questions. however, my basic issue still remains. sip text - the 2543 remains an enigmatic protocol specification for the present. it requires someone to mentor you before you can implement it. this is as opposed to a protocol like SMTP which you can figure out yourself. i am speaking from personal experience. a few weeks ago (before i discovered this list), i was sure that i had implemented the minimal protocol. now i am sure that i am 20% done. the other reason for confusion is that there is no reference implementation that is small enough to be easily understood by newbies. i was lucky to get the vovida stack (thanks duan!) by post. however, it is an intimidating system to understand. i know that there are people out there who have written simpler stacks and taken them to the bakeoffs. i urge these gurus to place parts (if not the complete code) of their stacks on the web. software is best described in programming languages and not in English. finally, there is still a need for a document that describes in details all the nitty gritty of implementing sip (like the illustrating tcp vol I and II). sip is as complex a protocol as tcp with far more involved issues of routing, proxying and interpreting headers than tcp it will certainly require an easier text that the 2543. possibly a whole book (or two). - farhan _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Sep 18 04: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 EAA29655 for ; Mon, 18 Sep 2000 04:11: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 47408443AD; Mon, 18 Sep 2000 03:10:41 -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 C21454433B for ; Mon, 18 Sep 2000 03:10: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 EAA01956; Mon, 18 Sep 2000 04:12:27 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Mon, 18 Sep 2000 04:07:27 -0400 Message-ID: From: Jonathan Rosenberg To: "'Rohan Mahy'" , "'Tom-PT Taylor'" Cc: "'Skip Cave'" , "'sip@lists.bell-labs.com'" Subject: RE: [SIP] Two Keystroke Encodings Date: Mon, 18 Sep 2000 04:07:26 -0400 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Catching up on some old email.... The subject of discussion here was Skips "generic keystroke" transport method, and whether to use rfc2833, rfc2793 (text over RTP), or something else. I would actually claim that we already have the worlds finest keystroke encoding protocol. It is also one of the worlds most widely deployed protocols. It is also the most powerful stimulus signaling protocol ever invented. It runs on every desktop and laptop. Shortly, it will run in some form on every wireless device. It is driven by client side interactions which can be rendered in the format appropriate for that device. What is this magical protocol? Its called HTTP. VoiceXML uses HTTP post to upload the data it collects from voice forms. HTML uses HTTP to upload the data it collects from text forms. Clients know nothing about the semantics of the data they render from HTTP, nor do they know anything about the semantics of the data they post to http servers. Only the human user knows. Sounds like a stimulus signaling protocol to me. When used in conjunction with SIP, HTTP is a very, very powerful tool for integrating in services which require application specific user stimulus. SIP provides all the needed hooks by allowing us to carry around http URLs and MIME content, and by using the various MIME headers like Accept which allow a server to figure out the rendering tools (html, voicexml, wml) that the client supports. As an example, consider a pre-paid calling card service. If the calling device can render html, wouldn't it be far cooler to return, in a 183, a pointer to a web page where the user can enter, via a form, their calling card number? If the card checks out, clicking "submit" will complete the call, else if the card validation fails, the SIP server would return a 400. In this case, the "stimulus" that the SIP server will receive is in the form of an http post containing the credit card number. I'll note that if the SIP server had returned a voiceXML script instead of an html page (or an http reference to it), the stimulus with the credit card number would be exactly the same - an HTTP form post. In that case, we completely decouple the user interaction from the processing of the resulting data, using http for the intermediate transfer of the raw data collected from the user. Very nice model, IMHO. -Jonathan R. > -----Original Message----- > From: sip-admin@lists.bell-labs.com > [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Rohan Mahy > Sent: Thursday, September 07, 2000 12:50 PM > To: Tom-PT Taylor > Cc: Skip Cave; sip@lists.bell-labs.com > Subject: RE: [SIP] Two Keystroke Encodings > > > I agree with Tom's assesment. My feeling is that stimulus > signalling is > fine for MGCP and Megaco, but is not appropriate in the SIP WG. > > thanks, > -rohan > > At 08:39 AM 9/7/00 , Tom-PT Taylor wrote: > >At least some of this debate seems to be a replay of the > ancient (from > >ISDN days) stimulus vs. functional protocol debate. Skip is > talking about > >stimulus signalling, Rohan about functional. Oldtimers can > tell you the > >merits of each, and also that functional may have won in the > short term, > >but stimulus keeps coming back. > > > >Tom T > > > > _______________________________________________ > 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 Mon Sep 18 04: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 EAA29687 for ; Mon, 18 Sep 2000 04: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 ECE4F443B8; Mon, 18 Sep 2000 03:12:24 -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 20F33443B4 for ; Mon, 18 Sep 2000 03:12:21 -0400 (EDT) Received: from oleane (dyn-1-1-101.Vin.dialup.oleane.fr [195.25.4.101]) by smtp1.cluster.oleane.net with SMTP id KAA48107 for ; Mon, 18 Sep 2000 10:12:45 +0200 (CEST) Message-ID: <01ab01c02148$0b4f9260$0401a8c0@oleane.com> From: "Peter Lewis" To: Date: Mon, 18 Sep 2000 10:11:26 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01A8_01C02158.CE521B60" 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] H.323 international conference Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com This is a multi-part message in MIME format. ------=_NextPart_000_01A8_01C02158.CE521B60 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable "Implementing H.323" international conference, October 10-13, Paris. Services, implementations, real deployments description. Presence of the = key players of the technology. Please get more details at: http://www.upperside.fr/bah323.htm ------=_NextPart_000_01A8_01C02158.CE521B60 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
"Implementing = H.323"=20 international conference, October 10-13, Paris.
Services, implementations, real = deployments=20 description. Presence of the key players of the technology.
Please get more details = at:
http://www.upperside.fr/bah32= 3.htm
 
------=_NextPart_000_01A8_01C02158.CE521B60-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Sep 18 04:28: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 EAA29742 for ; Mon, 18 Sep 2000 04:28: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 A0799443B0; Mon, 18 Sep 2000 03:28: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 671C64433B for ; Mon, 18 Sep 2000 03:28: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 EAA02041; Mon, 18 Sep 2000 04:29:51 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Mon, 18 Sep 2000 04:24:51 -0400 Message-ID: From: Jonathan Rosenberg To: "'Bobby Sardana'" , "'sip@lists.bell-labs.com'" Subject: RE: [SIP] IM Questions Date: Mon, 18 Sep 2000 04:24:50 -0400 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com > -----Original Message----- > From: sip-admin@lists.bell-labs.com > [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Bobby Sardana > Sent: Tuesday, September 05, 2000 5:29 PM > To: sip@lists.bell-labs.com > Subject: [SIP] IM Questions > > > Greetings: > > I have been reading the draft > [draft-rosenberg-impp-im-00.txt] and have > the following questions: > > a. In section 4.1 Message flow, the message F4 has two "Via" > headers. Is > this an error since the proxy should have popped the topmost "Via"? Yes, it is an error. > b. The draft does not outline support for multiple users > (2+). How will > the communication happen? What will be the message flow? There are several models. One is the "reflector" approach; I can send an IM to sip:mybuddies@lists.com, and this would result in an IM being sent to each of the members of that group. Much like a centralized conference server in SIP. In fact, it works very well with that model. The other approach is a fully distributed conference, where I would send an IM to each of the other participants. Much like the fully distributed multiparty conference for voice. > c. How are dynamic users added to a buddy list? Can a REGISTER message > be generated to perform the dynamic addition? Yes, that is one way. It can also be done administratively from a web page or something. -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 Sep 18 04:51: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 EAA29984 for ; Mon, 18 Sep 2000 04: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 E5D02443BD; Mon, 18 Sep 2000 03:50:28 -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 37E934433B for ; Mon, 18 Sep 2000 03:50: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 EAA02063; Mon, 18 Sep 2000 04:52:02 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Mon, 18 Sep 2000 04:47:02 -0400 Message-ID: From: Jonathan Rosenberg To: "'Itamar Gilad'" , "'Henning Schulzrinne'" Cc: "'Garret Wilson'" , "'SIP List'" Subject: RE: [SIP] isomorphic clarification Date: Mon, 18 Sep 2000 04:47:01 -0400 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Comments below (keeping full messages to establish some context here; its an old thread): > -----Original Message----- > From: Itamar Gilad [mailto:ItamarG@tlv.radvision.com] > Sent: Wednesday, August 16, 2000 12:49 PM > To: 'Henning Schulzrinne'; Jonathan Rosenberg > Cc: Garret Wilson; SIP List > Subject: RE: [SIP] isomorphic clarification > > > > > > -----Original Message----- > > From: Henning Schulzrinne [mailto:schulzrinne@cs.columbia.edu] > > Sent: Sat, August 12, 2000 12:53 AM > > To: Jonathan Rosenberg > > Cc: Garret Wilson; SIP List > > Subject: Re: [SIP] isomorphic clarification > > > > > > Jonathan Rosenberg wrote: > > > > > > Garret Wilson wrote: > > > > > > > > The SIP specification states that, "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." > > > > > > The -01 draft also mentions that the Request URIs must be > > identical, to > > > support spirals. > > > > > > As an additional thing, the *top* Vias must be the same, > in order to > > > detect merged requests. We should add this here and > elsewhere in the > > > document as needed. > > > > Might be good to have an example for this. > > > > > > > > You later write: > > > > I just realized that the latest spec explains how to > > compare URIs. The > > > > question remains that, if two URI's are equal yet not > > identical in string > > > > format, are two From headers (for example) which contain > > these two URIs > > > > considered to have the "same value" as per the definition > > of isomorphic? > > > > > > Yes. Two FRoms are equal if (1) their URIs match under URI > > comparison, > > > (2) their From parameters match, based on standard matching > > rules for > > > header parameters (case sensitive equality of both name > and value). > > > > Presumably parameters missing in one of the From/To are > ignored in the > > comparison. > > Not necessarily. I think 'tag' is a special case. In a UAC > when checking if > a 200 response matches an existing call leg you need to be > able to compare > its To: header which has a tag to the To: header of the > original INVITE, > which usually doesn't have a tag, and get the result that the > two are the > same. I think that this is the reason for the To/From > comparison rules that > disregard a missing tag. With other (generic-param) > parameters this may not > be the case. For example: > From: sip:itamarg@tlv.radvision.com;extparam=1 > and > From: sip:itamarg@tlv.radvision.com > > may not necessarily be the same. > We aren't talking about matching responses to requests. We're talking about whether two requests are the same. In that case, the comparison would not special case the tags. Cliff later writes: > One possible source of confusion is that the definition of > "isomorphic" > includes both requests and responses, but the RFCbis never > uses the word > "isomorphic" in relation to responses. > > I'm not sure that there is any particular significance to isomorphic > responses. For example, if the UAS sends a 183 to start an early media > session, and then sends a second 183 to modify that session, > the two 183's > are isomorphic, but they are not identical and both need to > be processed. > > On the other hand, the draft on reliable provisional > responses doesn't use > the word "isomorphic". Perhaps isomorphic reliable > provisional responses > should be defined there, and the definition would need to > include matching > RSeqs. > Although less critical, a definition of isomorphic responses would be nice. For example, a proxy will retransmit an ACK on a retransmit of a 4xx response. But, a totally different 4xx response (received as the result of an error downstream), might cause some kind of error logging or something. I would guess isomoprhic responses have the same To, From, Call-ID, CSeq, top Via, and response code. -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 Sep 18 06:16: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 GAA01033 for ; Mon, 18 Sep 2000 06:16: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 247334438C; Mon, 18 Sep 2000 05:15:39 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id D87BA4433B for ; Mon, 18 Sep 2000 05:15:32 -0400 (EDT) Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id LAA19747; Mon, 18 Sep 2000 11:02:29 +0100 (BST) From: "Jo Hornsby" To: "Henning Schulzrinne" , "Simon Barber" Cc: "Hisham Khartabil" , , "Jonathan Rosenberg" Subject: RE: [SIP] Outbound call routing Date: Mon, 18 Sep 2000 11:02:29 +0100 Message-ID: <006001c02157$8dd65840$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: <39C2CC94.98FD97C6@cs.columbia.edu> Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit > Forcing routing seems yet another user configuration parameter, along > with other service parameters that I'd like to keep even as I change > terminals. Thus, this is probably best addressed as user configuration > data downloaded from the REGISTER server, along with things like > speed-dial buttons or, say, CFB/CFNA end system behavior. If we define > an extension of CPL that's tailored to user agents, this might be a > useful feature to have, as one may want to make this feature > conditional. It's a nice idea, but I would guess that is going to be difficult in a lot of situations. I think the real problem lies with the fact that if a UA has an Outbound Proxy configured, then in a lot of cases, this is going to be for a very good reason (Firewall, or whatever). Therefore, if I happen to be working on some remote part of this Planet, and thus using "somebody else's" UA, I'm not necessarily going to be able to just reconfigure it to use my "home" proxy. As Jonathan pointed out, one could utilise Route to achieve this goal, but there is no guarantee that a proxy will honour this, since it will previously have been unaware of this "call". I've always wondered if it might be useful to have SIP URLs slightly more expressive, so that routing can be slightly richer without any information being lost as it occurs. And this seems as good a time as any to bring this point up. What I'm proposing, is a new SIP URL parameter, let's say: "proxy". The value of the "proxy" parameter is a `hostport'. This means that I can now roam to somebody else's domain, and send out an INVITE a la: INVITE sip:alice@example.com;proxy=sip.ubiquity.net SIP/2.0 ... In which case the INVITE is routed through the UAs normal outbound proxy, as needed, and "sip.ubiquity.net" supercedes any normal routing decisions. This would seem to satisfy the "always use this proxy" requirement, whether an outbound proxy is in the loop or not. Futhermore, it helps with the following scenario... Say my public SIP Address is sip:jo@ubiquity.net, but today I'm going to be working at buffy.com, thus I would like all my calls to be routed through to buffy.com. I plug in my laptop, and get allocated some private intranet IP via DHCP. I would like to send a REGISTER to my proxy at ubiquity.net, but my IP is not globally routable, so the Contact address my UA deduces is useless; however, it is trivial for me to multicast a REGISTER locally for sip:jo@ubiquity.net. So how does the proxy serving ubiquity.net know to route messages to buffy.com? Well, I can think of three solutions: 1) I send a REGISTER to ubiquity.net with my non-globally-routable IP in the Contact, and some proxy at buffy.com rewrites the Contact (and notes where I am for subsequent routing). 2) I have some sort of temporary account set up at buffy.com by the Systems Administrator, say "sip:ubiquity-jo@buffy.com". The necessary registrations are then done at both ubiquity.net and buffy.com . 3) I register my Contact at ubiquity.net as sip:jo@ubiquity.net;proxy=buffy.com I prefer 3), since maximum information is retained and very little messing around is required (i.e., we don't require any bastardisation of the message, nor extra staff). But in the end, I'm just bouncing this around, to see what people think. Routing is already very flexible, so this might be only really useful for the constant threat of firewall, in which case other, probably rewriting-based, solutions are probably preferable (since they're probably already going to have to be in place). Thoughts? 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 Mon Sep 18 06:21: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 GAA01105 for ; Mon, 18 Sep 2000 06:21: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 B7F35443BB; Mon, 18 Sep 2000 05:21:18 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id A4BB2443B6 for ; Mon, 18 Sep 2000 05:21:14 -0400 (EDT) Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id LAA25472; Mon, 18 Sep 2000 11:19:23 +0100 (BST) From: "Jo Hornsby" To: , "Henning Schulzrinne" Cc: "Jonathan Rosenberg" , "'Neil Deason'" , Subject: RE: [SIP] Stateless Proxy Date: Mon, 18 Sep 2000 11:19:23 +0100 Message-ID: <006201c02159$ea557950$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: <20000916132312.5170.qmail@microappliances.com> Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit > I would like some further clarification on this change: > > If the Contact is used as the URI for ACKs and BYEs, what happens > when two users both behind their own firewalls are using numerically > the same private addresses and the Contact: specified is a private > address. > > I guess it all depends on how a proxy is going to use this > information. If it is going to use for routing purposes we may have > trouble. If a non-routable Contact address managed to get so far "across" the network, then things have already gone pear-shaped. Whether an outbound proxy tries to route or the requesting-UA tries to route, it's gonna fail. - 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 Sep 18 06:35: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 GAA01389 for ; Mon, 18 Sep 2000 06:35: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 4946244355; Mon, 18 Sep 2000 05:35:28 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id 88E4D4434A for ; Mon, 18 Sep 2000 05:35:24 -0400 (EDT) Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id LAA00456; Mon, 18 Sep 2000 11:33:32 +0100 (BST) From: "Jo Hornsby" To: "Jonathan Rosenberg" , "'Itamar Gilad'" , "'Henning Schulzrinne'" Cc: "'Garret Wilson'" , "'SIP List'" Subject: RE: [SIP] isomorphic clarification Date: Mon, 18 Sep 2000 11:33:30 +0100 Message-ID: <006301c0215b$e31998e0$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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit > Cliff later writes: > > One possible source of confusion is that the definition of > > "isomorphic" includes both requests and responses, but the > > RFCbis never uses the word "isomorphic" in relation to > > responses. > > > > I'm not sure that there is any particular significance to > > isomorphic responses. For example, if the UAS sends a 183 > > to start an early media session, and then sends a second > > 183 to modify that session, the two 183's are isomorphic, > > but they are not identical and both need to be processed. > > > > On the other hand, the draft on reliable provisional responses > > doesn't use the word "isomorphic". Perhaps isomorphic reliable > > provisional responses should be defined there, and the > > definition would need to include matching RSeqs. > > Although less critical, a definition of isomorphic responses > would be nice. For example, a proxy will retransmit an ACK on > a retransmit of a 4xx response. But, a totally different 4xx > response (received as the result of an error downstream), might > cause some kind of error logging or something. > > I would guess isomoprhic responses have the same To, From, > Call-ID, CSeq, top Via, and response code. Actually, couldn't we make it easier than this? Since all To s with different responses should have different tags, couldn't the "response code" be dropped as a contributing factor? (The case where this would fail would be a legacy one where a UAS didn't support 487; or where Contact was not used, and thus a proxy did a forking search, and transitioned for stateful to stateless too early). Just a thought. - 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 Sep 18 06:51: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 GAA01737 for ; Mon, 18 Sep 2000 06:51: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 63BF14437F; Mon, 18 Sep 2000 05:50:42 -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 6103C4433B for ; Mon, 18 Sep 2000 05:50:39 -0400 (EDT) Received: from dynamicsoft.com (ip37.honxr1.ras.tele.dk [195.249.119.37]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id GAA02214; Mon, 18 Sep 2000 06:52:08 -0400 (EDT) Message-ID: <39C5F36F.F797694C@dynamicsoft.com> Date: Mon, 18 Sep 2000 12:50:23 +0200 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: Henning Schulzrinne , Simon Barber , Hisham Khartabil , sip@lists.bell-labs.com, Jonathan Rosenberg Subject: Re: [SIP] Outbound call routing References: <006001c02157$8dd65840$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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Jo Hornsby wrote: > > > Forcing routing seems yet another user configuration parameter, along > > with other service parameters that I'd like to keep even as I change > > terminals. Thus, this is probably best addressed as user configuration > > data downloaded from the REGISTER server, along with things like > > speed-dial buttons or, say, CFB/CFNA end system behavior. If we define > > an extension of CPL that's tailored to user agents, this might be a > > useful feature to have, as one may want to make this feature > > conditional. > > It's a nice idea, but I would guess that is going to be difficult > in a lot of situations. > > I think the real problem lies with the fact that if a UA has an > Outbound Proxy configured, then in a lot of cases, this is going > to be for a very good reason (Firewall, or whatever). Therefore, > if I happen to be working on some remote part of this Planet, and > thus using "somebody else's" UA, I'm not necessarily going to be > able to just reconfigure it to use my "home" proxy. > > As Jonathan pointed out, one could utilise Route to achieve this > goal, but there is no guarantee that a proxy will honour this, > since it will previously have been unaware of this "call". > > I've always wondered if it might be useful to have SIP URLs > slightly more expressive, so that routing can be slightly richer > without any information being lost as it occurs. And this seems > as good a time as any to bring this point up. > > What I'm proposing, is a new SIP URL parameter, let's say: "proxy". > The value of the "proxy" parameter is a `hostport'. > > This means that I can now roam to somebody else's domain, and > send out an INVITE a la: > INVITE sip:alice@example.com;proxy=sip.ubiquity.net SIP/2.0 > ... > In which case the INVITE is routed through the UAs normal > outbound proxy, as needed, and "sip.ubiquity.net" supercedes > any normal routing decisions. So this is another way of doing source-routing. I would have thought that if we really want to address this issue a better way would be to make sure Route: works even for initial requests. As far as I can tell that would be no more and no less backwards compatible than what you're suggesting, but it would use the existing mechanism, and it might even work with some existing implementations. > > This would seem to satisfy the "always use this proxy" requirement, > whether an outbound proxy is in the loop or not. > > Futhermore, it helps with the following scenario... > > Say my public SIP Address is sip:jo@ubiquity.net, but today I'm > going to be working at buffy.com, thus I would like all my calls > to be routed through to buffy.com. I plug in my laptop, and > get allocated some private intranet IP via DHCP. I would like > to send a REGISTER to my proxy at ubiquity.net, but my IP is > not globally routable, so the Contact address my UA deduces is > useless; however, it is trivial for me to multicast a REGISTER > locally for sip:jo@ubiquity.net. > > So how does the proxy serving ubiquity.net know to route messages > to buffy.com? Well, I can think of three solutions: > 1) I send a REGISTER to ubiquity.net with my non-globally-routable > IP in the Contact, and some proxy at buffy.com rewrites the > Contact (and notes where I am for subsequent routing). > 2) I have some sort of temporary account set up at buffy.com > by the Systems Administrator, say "sip:ubiquity-jo@buffy.com". > The necessary registrations are then done at both ubiquity.net > and buffy.com . > 3) I register my Contact at ubiquity.net as > sip:jo@ubiquity.net;proxy=buffy.com Could be done by registering sip:jo@ubiquity.net?Route= (suitably URL escaped) > > I prefer 3), since maximum information is retained and very little > messing around is required (i.e., we don't require any bastardisation > of the message, nor extra staff). > > But in the end, I'm just bouncing this around, to see what people > think. Routing is already very flexible, so this might be only > really useful for the constant threat of firewall, in which case > other, probably rewriting-based, solutions are probably preferable > (since they're probably already going to have to be in place). > > Thoughts? > > Cheers, > > - 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 Mon Sep 18 07:29: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 HAA02924 for ; Mon, 18 Sep 2000 07:29: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 5640644355; Mon, 18 Sep 2000 06:29:14 -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 3BFA24433B for ; Mon, 18 Sep 2000 05:02:04 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Mon Sep 18 06:00:46 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 1C21F4437D; Mon, 18 Sep 2000 05:47:37 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ukmail.uk.lucent.com (ukmail.uk.lucent.com [135.86.160.50]) by lists.bell-labs.com (Postfix) with ESMTP id EA43944341 for ; Mon, 18 Sep 2000 05:47:35 -0400 (EDT) Received: from lucent.com (uk0006166d078.uk.lucent.com [135.86.166.78]) by ukmail.uk.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id KAA11645; Mon, 18 Sep 2000 10:47:33 +0100 (BST) Message-ID: <39C5E51F.379206B@lucent.com> Date: Mon, 18 Sep 2000 10:49:19 +0100 From: Anna Simpson Organization: Lucent Technologies X-Mailer: Mozilla 4.6 [en]C-CCK-MCD EMS-1.4 (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] Question concerning SIP/ISUP interworking Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Hi, I have been studying SIP / ISUP interworking draft documents and I have a quesiton concerning the SIP response / cause mappings. Working from "Best Current Practice for ISUP to SIP mapping", March 2000 http://www.softarmor.com/sipwg/drafts/draft-camarillo-sip-isup-bcp-00.txt section 6.2.4 on page 21 shows Release 31, normal unspecified is mapped to the SIP response 404, Not found. Could anyone explain why this mapping was chosen? Thanks Anna _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Sep 18 07: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 HAA02991 for ; Mon, 18 Sep 2000 07:31: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 E0D4C443B6; Mon, 18 Sep 2000 06:29:17 -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 D1DAA443B7 for ; Mon, 18 Sep 2000 05:56:55 -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 FAA13137; Mon, 18 Sep 2000 05:56:18 -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 e8IAtGj26243; Mon, 18 Sep 2000 05:55:16 -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 FAA17482; Mon, 18 Sep 2000 05:56:16 -0500 (CDT) Message-ID: <39C5F4CD.E7B435D6@ericsson.com> Date: Mon, 18 Sep 2000 12:56:13 +0200 From: Sean Olson Organization: EUS/SI/PA X-Mailer: Mozilla 4.04 [en] (WinNT; I) MIME-Version: 1.0 To: Jo Hornsby Cc: Henning Schulzrinne , Simon Barber , Hisham Khartabil , sip@lists.bell-labs.com, Jonathan Rosenberg Subject: Re: [SIP] Outbound call routing References: <006001c02157$8dd65840$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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Jo Hornsby wrote: > I've always wondered if it might be useful to have SIP URLs > slightly more expressive, so that routing can be slightly richer > without any information being lost as it occurs. And this seems > as good a time as any to bring this point up. > > What I'm proposing, is a new SIP URL parameter, let's say: "proxy". > The value of the "proxy" parameter is a `hostport'. > > This means that I can now roam to somebody else's domain, and > send out an INVITE a la: > INVITE sip:alice@example.com;proxy=sip.ubiquity.net SIP/2.0 > ... > In which case the INVITE is routed through the UAs normal > outbound proxy, as needed, and "sip.ubiquity.net" supercedes > any normal routing decisions. Why not use a Route: header in the headers portion of the SIP URI? The outbound proxy can then decided whether or not to honor the Route:. This also generalizes to multiple proxies very nicely. There are probably encoding issues with embedding a Route: in the URI that I have not thought about yet, but this seems to work. > Thoughts? > Cheers, > - Jo. -- 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 Sep 18 07:50: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 HAA03440 for ; Mon, 18 Sep 2000 07:50: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 A8B444437D; Mon, 18 Sep 2000 06:50:14 -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 79FC9443B0 for ; Mon, 18 Sep 2000 06:44:55 -0400 (EDT) Received: from hotfoon.com ([202.54.68.186]) by hd2.dot.net.in (8.8.8/8.8.8) with ESMTP id RAA14469 for ; Mon, 18 Sep 2000 17:09:28 +0530 (IST) Message-ID: <39C6004B.A98EA22D@hotfoon.com> Date: Mon, 18 Sep 2000 17:15:15 +0530 From: diyanat Organization: Paradigm Computers Pvt. LTD X-Mailer: Mozilla 4.74 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Subject: RE: [SIP] IM Questions 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit the associated problems with IM on sip are that: 1. there is no way of identifying the complete list of subscribers to a user who joins a group chat. although separate notifications can be sent for each user, imagine doing that to a chokeful room of 50 users. it will cause a thundering herd effect. 2. there is no way of having reverse lists, ban lists, etc. within the SUBSCRIBE/NOTIFY mechanism. there are suggestions that we do this through a web interface. in that case, we might as well do the complete IM through web requests leaving only MESSAGE for unsolicited, push delivery of messages. Instant messaging is a type of session that can be initiated by SIP just like an RTP session. I would suggest that SIP can try a nomeclature of specifying a type of IM session within the body of an INVITE rather than being an IM session in itself. Remember that SIP is just an Intiation Protocol not a Session Protocol in itself. I have spent considerable time pestering rosenberg and schulzrinne about these issues. One suggestion from schulzrinne was that we could take a look at IRC itself for group chats. however, to date IRC doesnt have a formal URL definition. In anycase, if we adapt IRC protcol, it would be a fairly good choice. IRC already does what most IMs claim to do and more. it can be easily expanded and it has a far larger user base as compared to proprietory protocols and it is open. unfortunatley for the big buck corporations, the best of the irc systems are for free and that is reason enough for them to look away. it maybe a good idea to implement a session description like IRC/TCP specifying. the userid/password/server names are already well defined within the sip url. there is little else required to make the call. I have already tried integrating the mirc to do this with our sip client. it is a little slow in logging/connection but it works. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Sep 18 08:36: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 IAA05264 for ; Mon, 18 Sep 2000 08:36: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 AE6F94438E; Mon, 18 Sep 2000 07:36:16 -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 CAED744355 for ; Mon, 18 Sep 2000 07:36:12 -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 e8ICa6t07154; Mon, 18 Sep 2000 14:36:06 +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 PAA16948; Mon, 18 Sep 2000 15:36:05 +0300 (EET DST) Message-ID: <39C60C32.3CCA98F9@lmf.ericsson.se> Date: Mon, 18 Sep 2000 15:36:02 +0300 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: Anna Simpson Cc: sip@lists.bell-labs.com, adam.roach@ericsson.com Subject: Re: [SIP] Question concerning SIP/ISUP interworking References: <39C5E51F.379206B@lucent.com> 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 8bit Hi, In order to understand this cause value is better to use negative statements: Cause 31 belongs to the normal class. So, it does not belong to the following classes: resource unavailable class, service or option unavailable class, protocol error class and interworking class. This gives a rough idea about the semantics of this cause value. Or to be more precise, it gives an idea about which are not the samentics of this cause value. Inside the normal class, there are specific cause values that are used for specific situations: 1 – Unallocated (unassigned) number 2 – No route to specified transit network (national use) 3 – No route to destination 4 – Send special information tone 5 – Misdialled trunk prefix (national use) 6 – Channel unacceptable 7 – Call awarded and being delivered in an established channel 8 – Preemption 9 – Preemption – circuit reserved for reuse 16 – Normal call clearing 17 – User busy 18 – No user responding 19 – No answer from user (user alerted) 20 – Subscriber absent 21 – Call rejected 22 – Number changed 23 – Redirection to new destination 25 – Exchange – routing error 26 – Non-selected user clearing 27 – Destination out of order 28 – Invalid number format (address incomplete) 29 – Facility rejected 30 – Response to STATUS ENQUIRY Then, cause value 31 is defined as: 31 – Normal, unspecified Therefore, cause value 31 is applicable when there is a normal release whose cause does not fall into the previous mentioned categories. It is a general purpose cause value. One might think inmediately that 400 Bad Request would be appropiate, but if this status code is used the UA that sent the INVITE might think that the systax of the INVITE was not correct. Actually you are right, and 404 does not suit this fine either. The best option might be 480 Temporarily Unavailable. This way the UA would try again after some time... Any ideas against or in favour of this change? We have been pretty busy lately but we intend to relase a more or less definitive version of this draft soon. Regards, Gonzalo Anna Simpson wrote: > > Hi, I have been studying SIP / ISUP interworking draft documents and I have a quesiton concerning > the SIP response / cause mappings. > > Working from "Best Current Practice for ISUP to SIP mapping", March 2000 > http://www.softarmor.com/sipwg/drafts/draft-camarillo-sip-isup-bcp-00.txt > section 6.2.4 on page 21 shows > Release 31, normal unspecified is mapped to the SIP response 404, Not found. > > Could anyone explain why this mapping was chosen? > > Thanks > Anna > > _______________________________________________ > 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 Sep 18 09:14: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 JAA06505 for ; Mon, 18 Sep 2000 09:14: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 BC3AD44369; Mon, 18 Sep 2000 08:13:54 -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 6066E4434A for ; Mon, 18 Sep 2000 08:06:57 -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 JAA18159; Mon, 18 Sep 2000 09:06:50 -0400 (EDT) Message-ID: <39C61369.FADEC782@cs.columbia.edu> Date: Mon, 18 Sep 2000 09:06:49 -0400 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 Burger'" , "'sip@lists.bell-labs.com'" Subject: Re: [SIP] A warning to implementors 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Also, even for embedded systems, it is generally a good idea to allocate space for these fields dynamically rather than statically. Setting aside even 1,000 bytes for what is usually, say, 16 bytes is a waste of space. Thus, large limits are no help whatsoever and just cause opportunities for interoperability problems and various buffer-overflow attacks. Indeed, a large limit is worse since it is very unlikely to be exercised during normal tests, but very likely to be exploited by attackers. I'd also agree that the 1,500 byte limit is not too helpful. We should obviously try to keep messages below that, but there's not much you can do if you need large keys. Again, speaking from experience, lulling people into the notion that they don't have to deal with IP fragmentation can be very dangerous since there seem to be circumstances where a perfectly "nice" packet gets fragmented due to various encapsulation rules, without the sender having a clue. Note that the current MTU-related wording is SHOULD NOT, indicating that there may be valid reasons to ignore the prohibition. -- 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 Sep 18 09:39: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 JAA07247 for ; Mon, 18 Sep 2000 09:39: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 97FD04438C; Mon, 18 Sep 2000 08:39:36 -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 B4E4D44366 for ; Mon, 18 Sep 2000 08:39:16 -0400 (EDT) Received: from sampark.hss.hns.com (sampark.hss.hns.com [139.85.229.22]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id e8IDceC24358; Mon, 18 Sep 2000 19:08:41 +0530 (IST) Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 6525695E.004B4F40 ; Mon, 18 Sep 2000 19:12:34 +0530 X-Lotus-FromDomain: HSSBLR From: archow@hss.hns.com To: Henning Schulzrinne Cc: Jonathan Rosenberg , "'Eric Burger'" , "'sip@lists.bell-labs.com'" Message-ID: <6525695E.004B4D8C.00@sampark.hss.hns.com> Date: Mon, 18 Sep 2000 19:12:30 +0530 Subject: Re: [SIP] A warning to implementors 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com I tend to agree. Preferring static over dynamic memory for a SIP stack for embedded systems does not necessarily mean that its acheived by statically allocing Xk for every header, whether it needs it or not.Similar results can be acheived if your stack can work with a customised backend memory manager which can preallocate some fixed block to be used by any entity and then give 'dynamic' chunks from it to requesting sip entities. This way the OS still does not suffer from fragmentation. Basically, the point is, posing such limits to a SIP message really does not help that much, imho. As was rightly pointed out, often a message size can exceed not because a particular header is 1000 bytes, but because the message happened to traverse a series of proxies which all inserted normal size Via & Route headers. Often people designing sofware for 'embedded SIP' like phone et. al assume that since they are scaled down, they can handle 1500 byte messages and that is good enough - as pointed out, even such a simple device can be at the end of a long list of proxy chains. If you need to specify max size, I personally would prefer a max. size for a complete SIP message (for n/w read buffer maybe) as compared to limits for particular headers. (ie I'd much rather say that he complete message can be of max size 4000 bytes rather than saying From can be of 200, Route of 300 etc......) However, I do agree that in many systems, an implementor might want to specify maximum SIP message size - especially in systems where size of a text buffer does not grow dynamically (ie the convenience of s = s + newheader resulting in s being automatically increased is not there. In such environments, especially when a parsed message is re-encoded into a textual buffer, it may make sense to specify a fixed size for the output buffer, rather than goin thru the overhead of doing limit checks everytime and realloc() thereof- but that is really an implementation issue. A good stack should let the user decide how paranoid he wants to be with space allocation (ie static or dynamic) ) Regds Arjun -- Arjun Roychowdhury @ Hughes Software Systems Henning Schulzrinne on 09/18/2000 06:36:49 PM To: Jonathan Rosenberg cc: "'Eric Burger'" , "'sip@lists.bell-labs.com'" Subject: Re: [SIP] A warning to implementors Also, even for embedded systems, it is generally a good idea to allocate space for these fields dynamically rather than statically. Setting aside even 1,000 bytes for what is usually, say, 16 bytes is a waste of space. Thus, large limits are no help whatsoever and just cause opportunities for interoperability problems and various buffer-overflow attacks. Indeed, a large limit is worse since it is very unlikely to be exercised during normal tests, but very likely to be exploited by attackers. I'd also agree that the 1,500 byte limit is not too helpful. We should obviously try to keep messages below that, but there's not much you can do if you need large keys. Again, speaking from experience, lulling people into the notion that they don't have to deal with IP fragmentation can be very dangerous since there seem to be circumstances where a perfectly "nice" packet gets fragmented due to various encapsulation rules, without the sender having a clue. Note that the current MTU-related wording is SHOULD NOT, indicating that there may be valid reasons to ignore the prohibition. -- 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 Sep 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 KAA08017 for ; Mon, 18 Sep 2000 10: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 C8713443A8; Mon, 18 Sep 2000 09:04:17 -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 1421F44348 for ; Mon, 18 Sep 2000 09:04:14 -0400 (EDT) Received: from daebh02nok.americas.nokia.com (daebh02nok.americas.nokia.com [172.18.242.183]) by mgw-x1.nokia.com (8.10.2/8.10.2/Nokia) with ESMTP id e8IE44408437; Mon, 18 Sep 2000 17:04:04 +0300 (EET DST) Received: by daebh02nok with Internet Mail Service (5.5.2448.0) id ; Mon, 18 Sep 2000 09:04:02 -0500 Message-ID: From: Cliff.Harris@nokia.com To: archow@hss.hns.com Cc: sip@lists.bell-labs.com Subject: RE: [SIP] A warning to implementors Date: Mon, 18 Sep 2000 08:57:39 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com > -----Original Message----- > From: EXT archow@hss.hns.com [mailto:archow@hss.hns.com] > Sent: Monday, September 18, 2000 9:43 AM > To: Henning Schulzrinne > Cc: Jonathan Rosenberg; 'Eric Burger'; 'sip@lists.bell-labs.com' > Subject: Re: [SIP] A warning to implementors . . . > If you need to specify max size, I personally would prefer a > max. size for > a complete SIP message (for n/w read buffer > maybe) as compared to limits for particular headers. (ie I'd > much rather > say that he complete message can be of max > size 4000 bytes rather than saying From can be of 200, Route of 300 > etc......) > Note that the example of content-length in rfc-bis is "Content-Length: 3495". _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Sep 18 10:23: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 KAA08594 for ; Mon, 18 Sep 2000 10: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 A57C5443C7; Mon, 18 Sep 2000 09:22:33 -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 0985444348 for ; Mon, 18 Sep 2000 09:22:27 -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 e8IEMLZ26891; Mon, 18 Sep 2000 16:22: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 RAA25262; Mon, 18 Sep 2000 17:22:21 +0300 (EET DST) Message-ID: <39C6251A.6F863CA3@lmf.ericsson.se> Date: Mon, 18 Sep 2000 17:22:18 +0300 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: Anna Simpson Cc: sip@lists.bell-labs.com, adam.roach@ericsson.com Subject: Re: [SIP] Question concerning SIP/ISUP interworking References: <39C5E51F.379206B@lucent.com> <39C60C32.3CCA98F9@lmf.ericsson.se> <39C62303.7DE64774@lucent.com> 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 8bit Hi, If during an ongoing call a REL is received it will be mapped to a BYE request. The situation we are dealing with is when a REL comes back after sending a IAM. INVITE | -------->| IAM |-------> | REL Response |<------ <--------| ACK | -------->| In this scenario a response has to be sent (rather than a BYE). That's why the mapping cause value/status code is needed. Best regards, Gonzalo Anna Simpson wrote: > > Gonzalo, > > I am assuming that rel 16, normal call clearing would map to a BYE request. > > Is there any reason why a rel 31 could not be treated the same? > > I shall dig around and try and find some more information on when to use a REL 31 > to see if this helps. > > thanks for replying so quickly > Anna > > Gonzalo Camarillo wrote: > > > Hi, > > > > In order to understand this cause value is better to use negative > > statements: > > > > Cause 31 belongs to the normal class. So, it does not belong to the > > following classes: > > resource unavailable class, service or option unavailable class, > > protocol error class and interworking class. > > > > This gives a rough idea about the semantics of this cause value. Or to > > be more precise, it gives an idea about which are not the samentics of > > this cause value. > > > > Inside the normal class, there are specific cause values that are used > > for specific situations: > > > > 1 – Unallocated (unassigned) number > > 2 – No route to specified transit network (national use) > > 3 – No route to destination > > 4 – Send special information tone > > 5 – Misdialled trunk prefix (national use) > > 6 – Channel unacceptable > > 7 – Call awarded and being delivered in an established channel > > 8 – Preemption > > 9 – Preemption – circuit reserved for reuse > > 16 – Normal call clearing > > 17 – User busy > > 18 – No user responding > > 19 – No answer from user (user alerted) > > 20 – Subscriber absent > > 21 – Call rejected > > 22 – Number changed > > 23 – Redirection to new destination > > 25 – Exchange – routing error > > 26 – Non-selected user clearing > > 27 – Destination out of order > > 28 – Invalid number format (address incomplete) > > 29 – Facility rejected > > 30 – Response to STATUS ENQUIRY > > > > Then, cause value 31 is defined as: > > > > 31 – Normal, unspecified > > > > Therefore, cause value 31 is applicable when there is a normal release > > whose cause does not fall into the previous mentioned categories. It is > > a general purpose cause value. > > > > One might think inmediately that 400 Bad Request would be appropiate, > > but if this status code is used the UA that sent the INVITE might think > > that the systax of the INVITE was not correct. > > > > Actually you are right, and 404 does not suit this fine either. > > > > The best option might be 480 Temporarily Unavailable. This way the UA > > would try again after some time... > > > > Any ideas against or in favour of this change? > > > > We have been pretty busy lately but we intend to relase a more or less > > definitive version of this draft soon. > > > > Regards, > > > > Gonzalo > > > > Anna Simpson wrote: > > > > > > Hi, I have been studying SIP / ISUP interworking draft documents and I have a quesiton concerning > > > the SIP response / cause mappings. > > > > > > Working from "Best Current Practice for ISUP to SIP mapping", March 2000 > > > http://www.softarmor.com/sipwg/drafts/draft-camarillo-sip-isup-bcp-00.txt > > > section 6.2.4 on page 21 shows > > > Release 31, normal unspecified is mapped to the SIP response 404, Not found. > > > > > > Could anyone explain why this mapping was chosen? > > > > > > Thanks > > > Anna > > > > > > _______________________________________________ > > > 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 -- 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 Sep 18 10:48: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 KAA09649 for ; Mon, 18 Sep 2000 10:48: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 D3583443CF; Mon, 18 Sep 2000 09:47:46 -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 6191C443C5 for ; Mon, 18 Sep 2000 09:26:04 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Mon Sep 18 10:24:57 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 31FA24437D; Mon, 18 Sep 2000 10:11:47 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ukmail.uk.lucent.com (ukmail.uk.lucent.com [135.86.160.50]) by lists.bell-labs.com (Postfix) with ESMTP id 05EBE44341 for ; Mon, 18 Sep 2000 10:11:40 -0400 (EDT) Received: from lucent.com (uk0006166d078.uk.lucent.com [135.86.166.78]) by ukmail.uk.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id PAA04352; Mon, 18 Sep 2000 15:11:36 +0100 (BST) Message-ID: <39C62303.7DE64774@lucent.com> Date: Mon, 18 Sep 2000 15:13:23 +0100 From: Anna Simpson Organization: Lucent Technologies X-Mailer: Mozilla 4.6 [en]C-CCK-MCD EMS-1.4 (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Gonzalo Camarillo Cc: sip@lists.bell-labs.com, adam.roach@ericsson.com Subject: Re: [SIP] Question concerning SIP/ISUP interworking References: <39C5E51F.379206B@lucent.com> <39C60C32.3CCA98F9@lmf.ericsson.se> Content-Type: text/plain; charset=iso-8859-1 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA09649 Gonzalo, I am assuming that rel 16, normal call clearing would map to a BYE request. Is there any reason why a rel 31 could not be treated the same? I shall dig around and try and find some more information on when to use a REL 31 to see if this helps. thanks for replying so quickly Anna Gonzalo Camarillo wrote: > Hi, > > In order to understand this cause value is better to use negative > statements: > > Cause 31 belongs to the normal class. So, it does not belong to the > following classes: > resource unavailable class, service or option unavailable class, > protocol error class and interworking class. > > This gives a rough idea about the semantics of this cause value. Or to > be more precise, it gives an idea about which are not the samentics of > this cause value. > > Inside the normal class, there are specific cause values that are used > for specific situations: > > 1 – Unallocated (unassigned) number > 2 – No route to specified transit network (national use) > 3 – No route to destination > 4 – Send special information tone > 5 – Misdialled trunk prefix (national use) > 6 – Channel unacceptable > 7 – Call awarded and being delivered in an established channel > 8 – Preemption > 9 – Preemption – circuit reserved for reuse > 16 – Normal call clearing > 17 – User busy > 18 – No user responding > 19 – No answer from user (user alerted) > 20 – Subscriber absent > 21 – Call rejected > 22 – Number changed > 23 – Redirection to new destination > 25 – Exchange – routing error > 26 – Non-selected user clearing > 27 – Destination out of order > 28 – Invalid number format (address incomplete) > 29 – Facility rejected > 30 – Response to STATUS ENQUIRY > > Then, cause value 31 is defined as: > > 31 – Normal, unspecified > > Therefore, cause value 31 is applicable when there is a normal release > whose cause does not fall into the previous mentioned categories. It is > a general purpose cause value. > > One might think inmediately that 400 Bad Request would be appropiate, > but if this status code is used the UA that sent the INVITE might think > that the systax of the INVITE was not correct. > > Actually you are right, and 404 does not suit this fine either. > > The best option might be 480 Temporarily Unavailable. This way the UA > would try again after some time... > > Any ideas against or in favour of this change? > > We have been pretty busy lately but we intend to relase a more or less > definitive version of this draft soon. > > Regards, > > Gonzalo > > Anna Simpson wrote: > > > > Hi, I have been studying SIP / ISUP interworking draft documents and I have a quesiton concerning > > the SIP response / cause mappings. > > > > Working from "Best Current Practice for ISUP to SIP mapping", March 2000 > > http://www.softarmor.com/sipwg/drafts/draft-camarillo-sip-isup-bcp-00.txt > > section 6.2.4 on page 21 shows > > Release 31, normal unspecified is mapped to the SIP response 404, Not found. > > > > Could anyone explain why this mapping was chosen? > > > > Thanks > > Anna > > > > _______________________________________________ > > 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 Sep 18 11:56: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 LAA12203 for ; Mon, 18 Sep 2000 11:56:53 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 039504438C; Mon, 18 Sep 2000 10:56:06 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from godzilla.ipdialog.com (mail.ipdialog.com [208.238.222.66]) by lists.bell-labs.com (Postfix) with ESMTP id 7CF7544369 for ; Mon, 18 Sep 2000 10:56:03 -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 IAA03675; Mon, 18 Sep 2000 08:55:03 -0700 Message-ID: <39C63AD6.E411F47B@ipdialog.com> Date: Mon, 18 Sep 2000 08:55:02 -0700 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: Simon Barber Cc: "'Sip@Lists. Bell-Labs. Com'" Subject: Re: [SIP] Outbound call routing 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit I won't speak for the second part, but the first part could probably be addressed with a new DNS SRV record, say "sipoutbound". The roaming user would do a SRV lookup on his new, DHCP-derived local domain, and if "sipoutbound" exists, use that as the first hop. Howard Hart ipDialog, Inc. Simon Barber wrote: > I'm asking for a bit more than that. > > The big problem is that the user may be roaming away from his home network, > and be logged in to a SIP phone not only outside of the firewall of his home > network, but also behind the firewall of a foreign network. Because of this > second firewall all SIP requests have to be routed through the local SIP > proxy to get to the outside world. However the user would also like his > requests to be routed through a proxy server from his home domain - so his > services can be provided. This requires that the SIP request have some > routing at the SIP protocol layer, not just the internetwork layer. > > More simply - any of the user's home proxy servers may not be directly > reachable from the client, if the user is behind a foreign firewall. Hence > simply passing an IP address back in the register reply that the client > should send future requests to is not sufficient. We must provide a > mechanism whereby the SIP network can transport the requests to a server in > the user's home domain. > > Simon > > -----Original Message----- > From: Wayne Cutler [mailto:Wayne.Cutler@marconi.com] > Sent: Friday, September 15, 2000 2:09 AM > To: Jonathan Rosenberg > Cc: 'Simon Barber'; 'sip > Subject: RE: [SIP] Outbound call routing > > I believe that what Simon is asking for (please shout up if I'm > misrepresenting > you) is the abiltiy for the registrar/proxy to be able to explicitly assign > an > address to be used by the SIP user for all future requests during this > registration. > > An analogue would be the h323 GK scenario where there may be a well know RAS > (h323 registration) address which may be used by a h323 user to register > with > his "home" GK. For a succesful registration, the response provides a > completely > separate address to be used for h225 (call) signalling. The allocation of > the > h225 address is subject to local policy in the GK - e.g. the GK may be > composed > of several physical platforms and the allocation may be done on the basis of > dynamicaly sharing work/load amongst the platforms and therefore > avoiding/minimising pre-provisioning. > > In the SIP case, there doesn't seem to be a way (at least not one that's > explicitly stated) for a Registrar to accept a registration request and tell > the > recipient an address that the registrar/proxy requires to be used for all > future > requests. Such a capability would be useful, I believe. > > Regards, Wayne. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Sep 18 12:39: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 MAA14148 for ; Mon, 18 Sep 2000 12:39: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 46C56443A8; Mon, 18 Sep 2000 11:38:36 -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 CB3924438C for ; Mon, 18 Sep 2000 10:22:59 -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 KAA28835; Mon, 18 Sep 2000 10:22:54 -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 e8IFLqj03022; Mon, 18 Sep 2000 10:21: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 KAA02536; Mon, 18 Sep 2000 10:22:52 -0500 (CDT) Message-ID: <39C63349.15A168C2@ericsson.com> Date: Mon, 18 Sep 2000 17:22:49 +0200 From: Sean Olson Organization: EUS/SI/PA X-Mailer: Mozilla 4.04 [en] (WinNT; I) MIME-Version: 1.0 To: diyanat Cc: sip@lists.bell-labs.com Subject: Re: [SIP] IM Questions References: <39C6004B.A98EA22D@hotfoon.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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit I may be misunderstanding some of the terminology you are using. See my comments inline. diyanat wrote: > > the associated problems with IM on sip are that: > > 1. there is no way of identifying the complete list of subscribers to a > user who joins a group chat. although separate notifications can be sent > for each user, imagine doing that to a chokeful room of 50 users. it > will cause a thundering herd effect. If joining a group chat is accomplished via a REGISTER, then this ( supplying the new user with the list of current members) can be easily achieved. What you seem to want is to provide the current members of the group notification that a member has been added/deleted. This does not seem to be horribly heavy weight if implemented using a NOTIFY to each member. You could even piggyback this on another MESSAGE/response depending on your needs. I guess I'm missing the problem here. (I'm assuming a centralized server for the group chat.) > > 2. there is no way of having reverse lists, ban lists, etc. within the > SUBSCRIBE/NOTIFY mechanism. What about using Caller Preferences for this? Or do you want a more centralized approach? > there are suggestions that we do this > through a web interface. in that case, we might as well do the complete > IM through web requests leaving only MESSAGE for unsolicited, push > delivery of messages. It doesn't seem unreasonable to couple SIP with HTTP. They complement each other quite well. MESSAGE is meant for push delivery of messages. If you want a polling or queueing mechanism, it is relatively easy to do on top of MESSAGE. > > Instant messaging is a type of session that can be initiated by SIP just > like an RTP session. > I would suggest that SIP can try a nomeclature of specifying a type of > IM session within the body of an INVITE rather than being an IM session > in itself. Remember that SIP is just an Intiation Protocol not a Session > Protocol in itself. There are many good reasons to use MESSAGE outside of a INVITE session. The primary reason is the "instant" part. Why initiate a session for a one shot message? It is also nice to leave the correlation of MESSAGEs up to the applications/peers (a 'session' model may not be appropriate). There is nothing to say you can't use INVITE to initiate an RTP session for text (RFC2793). This may in fact be more appropriate for your application. > IRC already does what most IMs claim to do and more. it can be easily > expanded and it has a far larger user base as compared to proprietory > protocols and it is open. unfortunatley for the big buck corporations, > the best of the irc systems are for free and that is reason enough for > them to look away. > IRC is far from perfect. I don't like the relay segmentation problems. There are also nice synergies when you use the same mechanism for IM that you use for VoIP. Who says SIP can't be free as well? :) -- 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 Sep 18 13:35:22 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA15634 for ; Mon, 18 Sep 2000 13:35:22 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9EDD644393; Mon, 18 Sep 2000 12:34:27 -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 86F064438C for ; Mon, 18 Sep 2000 12:23:49 -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 e8IHNSm17705 for ; Mon, 18 Sep 2000 10:23:28 -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 e8IHNke15988 for ; Mon, 18 Sep 2000 10:23:46 -0700 (PDT) Received: by hqoutbound.ops.3com.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 8825695E.005F8B55 ; Mon, 18 Sep 2000 10:23:35 -0700 X-Lotus-FromDomain: 3COM From: Anoop_Tripathi@3com.com To: sip@lists.bell-labs.com Message-ID: <8825695E.005F2A55.00@hqoutbound.ops.3com.com> Date: Mon, 18 Sep 2000 12:19:11 -0500 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [SIP] Which Proxies should be stateful Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Hi All, Consider a call from UA1 through P1, P2 to UA2. P2 wants to recieve all the messages on TCP. This makes P2 to be in stateful mode. P1 does not want to be stateful by default. But does it have to be stateful just because it has to send the message to P2 over TCP. So, in brief, in this scenario can P1 stay in stateless mode? 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 Mon Sep 18 14:03: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 OAA16252 for ; Mon, 18 Sep 2000 14:03: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 D5C93443B1; Mon, 18 Sep 2000 13:03:07 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from rly-ip01.mx.aol.com (rly-ip01.mx.aol.com [205.188.156.49]) by lists.bell-labs.com (Postfix) with ESMTP id 613C844393 for ; Mon, 18 Sep 2000 13:03:04 -0400 (EDT) Received: from tot-ti.proxy.aol.com (tot-ti.proxy.aol.com [152.163.194.131]) by rly-ip01.mx.aol.com (8.8.8/8.8.8/AOL-5.0.0) with ESMTP id OAA00413; Mon, 18 Sep 2000 14:02:17 -0400 (EDT) Received: from athletics (ACA3BFEA.ipt.aol.com [172.163.191.234]) by tot-ti.proxy.aol.com (8.10.0/8.10.0) with SMTP id e8II2Fl28807; Mon, 18 Sep 2000 14:02:15 -0400 (EDT) From: "Steve Donovan" To: "Neil Deason" Cc: Subject: RE: [SIP] transaction identification Date: Mon, 18 Sep 2000 14:03:04 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: <39BCBC20.65E194@ubiquity.net> X-Apparently-From: UsDonovans@aol.com Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Neil Deason wrote: > > Steve Donovan wrote: > > > > Neil Deason wrote: > > > > > > > > As you say this wouldn't be a problem if > > > original uri in the record-route header was used > > > instead. But Jonathan pointed out that using the > > > originating name-addr... > > > > > > " maintains the fundamental principle that the > > > request URI indicates for whom the request is > > > destined. By relying on Route headers to get the > > > request there, even though the request URI says > > > something completely difference, makes the > > > operation of the protocol brittle. We have seen > > > this at bakeoffs - loops often occur if any proxy > > > has anything slightly wrong with their route > > > processing." > > > > > > > Let me push on this one a little bit. If the fundamental > principle is to be > > held for Route headers in requests from the callee to the > caller then why is > > that principle not also enforced for routes in requests going from the > > caller to the callee? If this is important then the same rule should be > > applied for building the route in both directions and the uri > in the contact > > received in the 200 OK should be used for building the caller to callee > > route. Don't get me wrong, I don't think this should be done, > I just don't > > understand the value of the request URI fundamental principle. > > > > I also don't understand how having broken proxies at bakeoffs makes the > > protocol brittle. It is also the case if proxies have anything > wrong with > > their via processing. If the proxy is implemented correctly > then using the > > original uri's in the Record-Route should work just fine. After all, > > proxies need to be able to handle routes with the original request uris > > correctly in the caller->callee direction. Why should they not > be able to > > in the callee->caller direction? > > > > My other question on the proposed solution is how can call > stateful proxies > > correlate requests with Route headers going in the > callee->caller direction > > with the correct call leg/transaction without the original request-uri? > > Can you elaborate on this please. As I see things call leg, > transactions and call state are 3 slightly different things. > The Request-URI is only important in the transasction ID. In > this example the new request would be part of a new transaction. > It is also part of an existing call leg as defined by the > Call-ID, To and From headers (user, hostport and tag parts). > If it needs to a Proxy can maintain call state by keeping track > of all requests and responses over this call leg. > Neil, you are correct, I was mixing issues on this. There was a related discussion, I believe at the same bake-off, about the posibility of adding a "state blob" to the record-route header and having that come back in the request-uri of subsequent requests. Sorry for mixing issues. > 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 Sep 18 14:06: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 OAA16346 for ; Mon, 18 Sep 2000 14:06: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 301A8443D1; Mon, 18 Sep 2000 13:04:23 -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 2F755443B0 for ; Mon, 18 Sep 2000 12:40:38 -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 e8IHeGm22431 for ; Mon, 18 Sep 2000 10:40:16 -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 e8IHeYe21112 for ; Mon, 18 Sep 2000 10:40:34 -0700 (PDT) Received: by hqoutbound.ops.3com.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 8825695E.0061149F ; Mon, 18 Sep 2000 10:40:22 -0700 X-Lotus-FromDomain: 3COM From: Anoop_Tripathi@3com.com To: sip@lists.bell-labs.com Message-ID: <8825695E.00609D66.00@hqoutbound.ops.3com.com> Date: Mon, 18 Sep 2000 12:35:00 -0500 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [SIP] Do Requests using record-route always go over UDP Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com I have a question regarding Record-Route behaviour. The definition of Record-Route states that in the maddr field "transport parameter" is not allowed. Does this mean that all Requests using Record-Route to reach the destination can only go over UDP(default) since there is no way to specify TCP. 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 Mon Sep 18 14:42: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 OAA17209 for ; Mon, 18 Sep 2000 14: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 D842D443D6; Mon, 18 Sep 2000 13:41:17 -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 563624433E for ; Mon, 18 Sep 2000 13:41:11 -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 OAA07337 for ; Mon, 18 Sep 2000 14:42:53 -0400 (EDT) From: "Robert Sparks" To: Date: Mon, 18 Sep 2000 13:38:05 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0022_01C02175.AC9CC7A0" 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: Subject: [SIP] draft-ietf-sip-cc-transfer-01 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com This is a multi-part message in MIME format. ------=_NextPart_000_0022_01C02175.AC9CC7A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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 ------=_NextPart_000_0022_01C02175.AC9CC7A0 Content-Type: text/plain; name="draft-ietf-sip-cc-transfer-01.txt" Content-Disposition: attachment; filename="draft-ietf-sip-cc-transfer-01.txt" Content-Transfer-Encoding: 7bit Internet Engineering Task Force Robert Sparks Internet Draft dynamicsoft draft-sip-cc-transfer-01.txt September 2000 Expires April 2001 SIP Call Control Transfer STATUS OF THIS MEMO This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as work in progress. The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract This document defines a SIP extension within the Call Control Framework to provide Call Transfer capabilities. Robert Sparks [Page 1] Internet Draft draft-ietf-sip-cc-transfer-01.txt July 2000 1 Overview...........................................................3 2 Changes from draft-sparks-sip-cc-transfer-01.......................4 3 The REFER Method...................................................5 3.1 The Refer-To Header............................................5 3.2 The Referred-By Header.........................................6 3.2.1 A PGP based signature-scheme.................................6 3.3 Header Field Support for the REFER Method......................7 3.4 Message Body Inclusion.........................................8 3.5 Responses to the REFER Method..................................8 3.6 Behavior of SIP User Agents....................................8 3.7 Behavior of SIP Registrars/Redirect Servers....................9 3.8 Behavior of SIP Proxies........................................9 3.9 Security Considerations........................................9 4 Call Transfer.....................................................10 4.1 Actors and Roles..............................................10 4.2 Requirements..................................................11 4.3 Using REFER to achieve Call Transfer..........................12 4.4 Unattended Transfer...........................................12 4.4.1 Successful Unattended Transfer..............................13 4.4.2 Failed Unattended Transfer..................................14 4.5 Unattended Transfer with Consultation Hold....................14 4.5.1 Variation 1 : Exposes transfer target.......................15 4.5.2 Variation 2 : Protects transfer target......................15 4.6 Attended Transfer.............................................16 4.7 Transfer with multiple parties................................16 5 Editor's Address..................................................18 6 Acknowledgments...................................................18 7 References........................................................18 Robert Sparks [Page 2] Internet Draft draft-ietf-sip-cc-transfer-01.txt July 2000 1 Overview This document defines a SIP [2] extension and details its use to provide Call Transfer capabilities. This is part of a family of Call Control extensions described in the Call Control Framework document [3]. The mechanisms discussed here are most closely related to traditional unattended and consultation hold transfers. Discussion of attended transfer (where all parties are briefly in a conference) is deferred until the conferencing features in this framework are addressed. This work has roots in draft-ietf-sip-cc-01 [4] but some basic semantics are different. In particular, transfers are achieved through a new method that does not terminate the original signaling relationship. By disassociating transfers from the processing of BYE, these changes facilitate recovery of failed transfers and clarify state management in the participating entities. Implementers that started with the sip-cc-01 BYE-ALSO technique for blind-transfer should find it straightforward to migrate to the mechanisms set forth here. Robert Sparks [Page 3] Internet Draft draft-ietf-sip-cc-transfer-01.txt July 2000 2 Changes from draft-sparks-sip-cc-transfer-01 . 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. Robert Sparks [Page 4] Internet Draft draft-ietf-sip-cc-transfer-01.txt July 2000 3 The REFER Method REFER is a SIP method as defined by [2]. The REFER method indicates that the recipient should contact a third party using the contact information provided in the method. A success response indicates that the recipient was able to contact the third party. The REFER method follows the session's current signaling path. In particular, the Request-URI of the REFER method identifies the recipient. Unless stated otherwise, the protocol for emitting and responding to a REFER request are identical to those for a BYE request in [2]. The behavior of SIP entities not implementing the REFER (or any other unknown) method is explicitly defined in [2] and is not discussed further here. 3.1 The Refer-To Header Refer-To is a request-header as defined by [2]. It may only appear in a REFER request. Refer-To = ("Refer-To" | "r") ":" URL A REFER method MUST contain exactly one Refer-To header. The Refer-To header MAY be encrypted as part of end-end encryption. The Contact header is an important part of the Route/Record-Route mechanism and is not available for this task. Robert Sparks [Page 5] Internet Draft draft-ietf-sip-cc-transfer-01.txt July 2000 3.2 The Referred-By Header Referred-By is a request-header as defined by [2]. It can appear in any request. It conveys the identity of the original REFERrer to the referred-to party, optionally proving the identity and that the REFERrer actually issued this reference. Referred-By = ("Referred-By" | "b") ":" referrer-url ";" referenced-url [";" ref-signature] referrer-url = SIP-URL referenced-url = "ref" "=" URL ref-signature = signature-scheme *( ";" sig-scheme-params ) signature-scheme = "scheme" "=" token sig-scheme-parms = token "=" ( token | quoted-string ) The referrer-url contains the SIP URL of the party sending the REFER request. The referenced-url contains a copy of the URL placed in the Refer-To: header. The ref-signature contains a signature over the concatenation of referrer-url and referenced-url. An example signature scheme is given in section 3.2.1. A REFER request MUST contain exactly one Referred-By header. The Referred-By header SHOULD be signed to help detection of REFERs from unauthorized third parties. A signed Referred-By header SHOULD include a Date header in the referrer-url to facilitate detection of replay attacks. A UA MAY reject a request containing an unsigned Referred-By header. A UA SHOULD verify the signature on any Referred-By header it receives. The Referred-By header MAY be encrypted as part of end-end encryption. 3.2.1 A PGP based signature-scheme One signature-scheme for Referred-By headers uses PGP as follows: signature-scheme = "scheme" "=" "pgp" sig-scheme-parms = pgp-version | signed-by | pgp-signature pgp-version, signed-by and pgp-signature are defined in section 15.1 of RFC2543, with the modification that the signature is computed across the concatenation of the referrer-url and the referenced-url. Robert Sparks [Page 6] Internet Draft draft-ietf-sip-cc-transfer-01.txt July 2000 3.3 Header Field Support for the REFER Method This table adds a column to tables 4 and 5 in [2], describing header presence in a REFER method. See [2] for a key for the symbols used. A row for the Refer-To: and Referred-By request-header should be inferred, each mandatory for REFER. Refer-To is not applicable for all other methods. Referred-By is a general Request header. The enc and e- e columns in [2] apply to the REFER method unmodified. Header Where REFER Accept R - Accept-Encoding R - Accept-Language R o Allow R - Allow 405 m Authorization R o Call-ID gc m Contact R o Contact 1xx - Contact 2-6xx o Content-Encoding e - Content-Length e o Content-Type e - CSeq gc m Date g o Encryption g o Expires R o From gc m Hide R o Max-Forwards R o Organization g o Priority R - Proxy-Authenticate 407 o Proxy-Authorization R o Proxy-Require R o Require R o Retry-After R - Retry-After 404,480,486 o Retry-After 503 o Retry-After 600,603 o Response-Key R o Record-Route R o Record-Route 2xx o Route R o Robert Sparks [Page 7] Internet Draft draft-ietf-sip-cc-transfer-01.txt July 2000 Server r o Subject R - Timestamp g o To gc(1) m Unsupported 420 o User-Agent g o Via gc(2) m Warning r o WWW-Authenticate 401 o 3.4 Message Body Inclusion A REFER method may contain a body which SHOULD be processed according to its Content-Type. 3.5 Responses to the REFER Method An agent responding to a REFER Method MUST return a 400 Bad Request if the request contained zero or more than one Refer-To headers. An agent responding to a REFER Method MUST return a 400 Bad Request if the request contained zero or more than one Referred-By headers. An agent (including proxies generating local responses) MAY return a 100 Trying or any appropriate 400-600 class response as prescribed by [2]. If the recipient's agent decides to contact the resource in the Refer-To header, a 200 OK response MUST be returned if it the contact was successful, otherwise a 503 Service Unavailable MUST be returned. The 503 response MAY contain a Retry-After: header indicating when the REFER may be attempted again. 3.6 Behavior of SIP User Agents A UA receiving a well-formed REFER request SHOULD request approval from the user to proceed (this request could be interactive or through configuration). Upon receiving approval from the user, the UA MUST contact the resource identified by the URL in the Refer-To: header. Note that if the URL is a SIP URL, it could contain header fields such as Call-Id that will be used to form the resulting request. If the URL is a SIP URL, the Referred-By header in the REFER request should be copied into the request sent to the referred-to resource. In accordance with [2], the UA SHOULD issue a provisional response to the REFER method if it cannot issue a final response within 200ms of its receipt. The appropriate response to issue to the REFER on receipt of a final response from the referred-to resource is discussed in "Responses to the REFER Method". Robert Sparks [Page 8] Internet Draft draft-ietf-sip-cc-transfer-01.txt July 2000 3.7 Behavior of SIP Registrars/Redirect Servers Registrars and Redirect Servers SHOULD return a 603 to a REFER request, unless they are also playing some other SIP role. 3.8 Behavior of SIP Proxies SIP Proxies do not require modification to support the REFER method. Specifically, as required by [2], a proxy should process a REFER request the same way it processes an OPTIONS request. 3.9 Security Considerations The security requirements of [2] apply to the REFER method. This mechanism relies on providing contact information for the referred-to resource to the party being referred. Care should be taken to provide a suitably restricted URI if the referred to resource should be protected. Care should be taken when implementing the logic that determines whether or not to accept the REFER request. A UA not capable of accessing non-SIP URLs SHOULD NOT accept REFER requests to them. Robert Sparks [Page 9] Internet Draft draft-ietf-sip-cc-transfer-01.txt July 2000 4 Call Transfer 4.1 Actors and Roles There are three actors in a given transfer event, each playing one of the following roles: Transferee - the party being transferred to the Transfer Target. Transferor - the party initiating the transfer Transfer Target - the new party being introduced into a call with the Transferee. The following roles are used to describe transfer requirements and scenarios: Originator - wishes to place a call to the Recipient. This actor is the source of the first INVITE in a session, to either a Facilitator or a Screener. Facilitator - receives a call or out-of-band request from the Originator, establishes a call to the Recipient through the Screener, and connects the Originator to the Recipient. Screener - receives a call ultimately intended for the Recipient and transfers the calling party to the Recipient if appropriate. Recipient - the party the Originator is ultimately connected to. Robert Sparks [Page 10] Internet Draft draft-ietf-sip-cc-transfer-01.txt July 2000 4.2 Requirements 1. Any party in a SIP session MUST be able to transfer any other party in that session at any point in that session. 2. The Transferor and the Transferee MUST NOT be removed from a session as part of a transfer transaction. At first glance, requirement 2 may seem to indicate that the user experience in a transfer must be significantly different from what a current PBX or Centrex user expects. As the call-flows in this document show, this is not the case. A client MAY preserve the current experience. In fact, without this requirement, some forms of the current experience (ringback on unattended transfer failure for instance) will be lost. 3. The Transferor MUST know whether or not the transfer was successful (this is significantly different from the requirements of draft-ietf-sip-cc-01). Robert Sparks [Page 11] Internet Draft draft-ietf-sip-cc-transfer-01.txt July 2000 4.3 Using REFER to achieve Call Transfer A REFER can be issued by the Transferor to cause the Transferee to issue an INVITE to the Transfer-Target. Note that a successful REFER transaction does not terminate the session between the Transferor and the Transferee. If those parties wish to terminate their session, they must do so with a subsequent BYE request. The media negotiated between the transferee and the transfer target is not affected by the media that had been negotiated between the transferor and the transferee. In particular, the INVITE issued by the Transferee will have the same SDP body it would have if he Transferee had initiated that INVITE on its own. Further, the disposition of the media streams between the Transferor and the Transferee is not altered by the REFER method. Agents may alter a session's media through additional signaling. For example, they may make use of the SIP hold re-INVITE [2] or the conferencing extensions provided by this framework. 4.4 Unattended Transfer Unattended Transfer consists of the Transferor providing the Transfer Target's contact to the Transferee. The Transferee attempts to establish a session using that contact and reports the results of that attempt to the Transferor. The signaling relationship between the Transferor and Transferee is not terminated, so the call is recoverable if the Transfer Target cannot be reached. Note that the Transfer Target's contact information has been exposed to the Transferee. The provided contact can be used to make new calls in the future. The diagrams below show indicate the first line of each message. All messages in a particular diagram share the same Call-ID. In these diagrams, media is managed through reINVITE holds, but using other mechanisms (mixing multiple media streams at the UA or using the conferencing extensions for example) are valid. Robert Sparks [Page 12] Internet Draft draft-ietf-sip-cc-transfer-01.txt July 2000 4.4.1 Successful Unattended Transfer Transferor Transferee Transfer | | Target | INVITE | | |<-------------------| | | 200 OK | | |------------------->| | | ACK | | |<-------------------| | | INVITE (hold) | | |------------------->| | | 200 OK | | |<-------------------| | | ACK | | |------------------->| | | REFER | | |------------------->| | | 100 Trying | | |<-------------------| | | | INVITE | | |------------------->| | | 200 OK | | |<-------------------| | | ACK | | |------------------->| | 200 OK | | |<-------------------| | | BYE | | |------------------->| | | 200 OK | | |<-------------------| | | | BYE | | |<-------------------| | | 200 OK | | |------------------->| Robert Sparks [Page 13] Internet Draft draft-ietf-sip-cc-transfer-01.txt July 2000 4.4.2 Failed Unattended Transfer Transferor Transferee Transfer | | Target | | | | INVITE | | |<-------------------| | | 200 OK | | |------------------->| | | ACK | | |<-------------------| | | INVITE (hold) | | |------------------->| | | 200 OK | | |<-------------------| | | ACK | | |------------------->| | | REFER | | |------------------->| | | 100 Trying | | |<-------------------| | | | INVITE | | |------------------->| | | 486 Busy Here | | |<-------------------| | | ACK | | |------------------->| | 503 Service Unavailable | |<-------------------| | | INVITE (unhold) | | |------------------->| | | 200 OK | | |<-------------------| | | ACK | | |------------------->| | | BYE | | |------------------->| | | 200 OK | | |<-------------------| | 4.5 Unattended Transfer with Consultation Hold Transfer with Consultation Hold involves a session between the transferor and the transfer target before the transfer actually takes place. This is implemented with SIP Hold and Unattended Transfer as described above. Robert Sparks [Page 14] Internet Draft draft-ietf-sip-cc-transfer-01.txt July 2000 4.5.1 Variation 1 : Exposes transfer target The transferor places the transferee on hold, establishes a call with the transfer target to alert them to the impending transfer, terminates the connection with the transfer target, then proceeds with unattended transfer as above. This variation can be used to provide an experience similar to that expected by current PBX and Centrex users. To (hopefully) improve clarity, non-REFER transactions have been collapsed into one indicator with the arrow showing the direction of the request. Transferor Transferee Transfer | | Target | | | Call-ID:1 | INVITE/200 OK/ACK | | |<-------------------| | Call-ID:1 | INVITE (hold)/200 OK/ACK | |------------------->| | Call-ID:2 | INVITE/200 OK/ACK | | |---------------------------------------->| Call-ID:2 | BYE/200 OK | | |---------------------------------------->| Call-ID:1 | REFER | | |------------------->| | | 100 Trying | | |<-------------------| | Call-ID:1 | | INVITE/200 OK/ACK | | |------------------->| | 200 OK | | |<-------------------| | Call-ID:1 | BYE/200 OK | | |------------------->| | Call-ID:1 | | BYE/200 OK | | |<-------------------| 4.5.2 Variation 2 : Protects transfer target The transferor places the transferee on hold, establishes a call with the transfer target and then reverses their roles, transferring the original transfer target to the original transferee. This has the advantage of hiding information about the original transfer target from the original transferee. On the other hand, the Transferee's experience is different that in current systems. The Transferee is effectively "called back" by the Transfer Target. Robert Sparks [Page 15] Internet Draft draft-ietf-sip-cc-transfer-01.txt July 2000 Transferor Transferee Transfer | | Target | | | Call-ID:1 | INVITE/200 OK/ACK | | |<-------------------| | Call-ID:1 | INVITE (hold)/200 OK/ACK | |------------------->| | Call-ID:2 | INVITE/200 OK/ACK | | |---------------------------------------->| Call-ID:2 | INVITE (hold)/200 OK/ACK | |---------------------------------------->| Call-ID:2 | REFER | | |---------------------------------------->| | 100 Trying | | |<----------------------------------------| Call-ID:2 | | INVITE/200 OK/ACK | | |<-------------------| | 200 OK | | |<----------------------------------------| Call-ID:1 | BYE/200 OK | | |------------------->| | Call-ID:2 | BYE/200 OK | | |---------------------------------------->| Call-ID:2 | | BYE/200 OK | | |------------------->| 4.6 Attended Transfer In an attended transfer, the three actors participate in an ad-hoc conference as part of the event. Discussion of the implementation of attended transfer is thus deferred until the conferencing portion of the Call Control framework has been addressed. 4.7 Transfer with multiple parties In this example the Originator places call to the Facilitator who reaches the Recipient through the Screener. The Recipient's contact information is exposed to the Facilitator and the Originator. This example is provided for clarification of the semantics of the REFER method only and should not be used as the design of an implementation. Robert Sparks [Page 16] Internet Draft draft-ietf-sip-cc-transfer-01.txt July 2000 Originator Facilitator Screener Recipient Call-ID | | | | 1 |INVITE/200 OK/ACK | |"Get Fred for me!" |----------->| | | "Right away!" 1 |INVITE (hold)/200 OK/ACK | | |<-----------| | | 2 | |INVITE/200 OK/ACK |"I have a call | |----------->| |from Mary for Fred" 2 | |INVITE (hold)/200 OK/ACK "Hold please" | |<-----------| | 3 | | |INVITE/200 OK/ACK | | |--------->|"You have a call | | | |from Mary" | | | | "Put her through" 3 | | |INVITE (hold)/200 OK/ACK | | |--------->| 2 | |REFER | | | |<-----------| | | |100 Trying | | | |----------->| | 2 | |INVITE/200 OK/ACK | | |---------------------->|"This is Fred" | |200 OK | | "Please hold for | |----------->| | Mary" 2 | |BYE/200 OK | | | |<-----------| | 3 | | |BYE/200 OK| | | |--------->| 2 | |INVITE (hold)/200 OK/ACK | |---------------------->| 1 |REFER | | | |<-----------| | | |100 Trying | | | |----------->| | | 1 |INVITE/200 OK/ACK | | |----------------------------------->| "Hey Fred" |200 OK | | | "Hello Mary" |----------->| | | 1 |BYE/200 OK | | | |<-----------| | | 2 | |BYE/200 OK | | | |---------------------->| 1 |BYE/200 OK | | | |<-----------------------------------| "See you later" Robert Sparks [Page 17] Internet Draft draft-ietf-sip-cc-transfer-01.txt July 2000 5 Editor's Address Robert Sparks dynamicsoft 200 Executive Drive Suite 120 West Orange, NJ 07052 email: rsparks@dynamicsoft.com 6 Acknowledgments This draft is a collaborative product of the SIP working group. The editor thanks the following for their early contributions to this work: Ben Campbell, Chris Cunningham, Steve Donovan, Alan Johnston, Kevin Summers and Dean Willis. 7 References [1] S. Bradner, "The Internet Standards Process -- Revision 3", BCP9, RFC2026, October 1996. [2] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP:Session Initiation Protocol", RFC 2543, March 1999. [3] B. Campbell, "Framework for SIP Call Control Extensions", Internet Draft draft-ietf-sip-cc-framework-00, Internet Engineering Task Force, March 2000. Work in Progress. [4] H. Schulzrinne, J. Rosenberg, "SIP Call Control Services", Internet Draft draft-ietf-sip-cc-01, Internet Engineering Task Force, June 17, 1999 Work in Progress (expired). Robert Sparks [Page 18] ------=_NextPart_000_0022_01C02175.AC9CC7A0-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Sep 18 14:57: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 OAA17447 for ; Mon, 18 Sep 2000 14:57: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 2B92F443AD; Mon, 18 Sep 2000 13:57:26 -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 7EA064433E for ; Mon, 18 Sep 2000 13:57:22 -0400 (EDT) Received: from daebh02nok.americas.nokia.com (daebh02nok.americas.nokia.com [172.18.242.183]) by mgw-x1.nokia.com (8.10.2/8.10.2/Nokia) with ESMTP id e8IIvH426765; Mon, 18 Sep 2000 21:57:17 +0300 (EET DST) Received: by daebh02nok with Internet Mail Service (5.5.2448.0) id ; Mon, 18 Sep 2000 13:57:16 -0500 Message-ID: From: Cliff.Harris@nokia.com To: rsparks@dynamicsoft.com, sip@lists.bell-labs.com Subject: RE: [SIP] draft-ietf-sip-cc-transfer-01 Date: Mon, 18 Sep 2000 13:50:50 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com There was a suggestion from Jonathan that doesn't seem to have made it into the draft: Subject: Possible REFER problem? Date: Sun 9/10/00 Partial Text: "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." > -----Original Message----- > From: EXT Robert Sparks [mailto:rsparks@dynamicsoft.com] > Sent: Monday, September 18, 2000 2:38 PM > 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 > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Sep 18 15:04: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 PAA17627 for ; Mon, 18 Sep 2000 15:04: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 E1A7D443DE; Mon, 18 Sep 2000 14:03:50 -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 45C8C443B1 for ; Mon, 18 Sep 2000 14:03:47 -0400 (EDT) Received: from zrchb200.us.nortel.com (actually zrchb200) by smtprch2.nortel.com; Mon, 18 Sep 2000 13:56:07 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Mon, 18 Sep 2000 13:59:49 -0500 Message-ID: <36FA02BD7083D411BC9E0000F8073E43A617B8@crchy271.us.nortel.com> From: "Brian Stucker" To: "'sip@lists.bell-labs.com'" Subject: RE: [SIP] DNS SRV records in stateless mode Date: Mon, 18 Sep 2000 13:59:39 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C021A2.98990E80" X-Orig: Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com 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_01C021A2.98990E80 Content-Type: text/plain; charset="ISO-8859-1" This wording concerns me. I'm afraid of what the term 'hash' may imply to implementors down the road. Since Call-IDs do not need to be randomly selected, a (poor) hash of non-random sequence may very well wind up not being random either. This wouldn't be easily detectible in situations like bake-offs, where a limited number of calls are made. But, if it were applied to a much larger scale, with higher traffic, the problem could render the spirit of the weighting algorithm of RFC 2782 moot. Instead of getting random, weighted server selection; you're getting sort-of random, kind-of weighted server selection. Imagine if a portion of a large IP backbone provider was using SIP, and had a stateless proxy setup with DNS-SRV for load balaning ran into this problem? I think more stress needs to be placed on ensuring that the hash is as random as possible (to the point of suggesting a suitable hash algorithm, such as diving by a small prime number then modulus that with the weight total). A lot of algorithms qualify as hashing algorithms that may just great for small numbers of data elements, but not for a high-traffic environment. Example: let's just add up all the digits in the Call-ID, and mod that with the weighting total (bad idea). I suspect that if we're having issues with fixed length fields, that this sort of issue could easily creep up as well to the detriment of the implementor. Also, this poses another problem, one where we can get out-of-sync with our record selection. Let's say we have an INVITE that DNS-SRV returns two entries for, each at a different priority level (priority A, and B, A is better). The proxy selects the entry with priority A, and tries to route to the server listed in the SRV record. That routing attempt times-out, so it fails over to the second entry at priority B. During this time a retransmission of the INVITE is sent by the originating UA, and is going to get hashed back to the records with priority A in the proxy. However, we now know that route is bad. We shouldn't re-select it for this transaction, we should go straight to B for the retransmission as well. There's ways around this for stateful proxies, but a stateless proxy can't employ the same methods with your selection method. UNLESS you also stipulate that you should remove an entry from the list of selectable SRV entries left in the list once they're excluded due to a timeout, or whatever other event the proxy implementor deems appropriate. Thoughts? Brian Stucker Nortel Networks -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Sunday, September 17, 2000 11:53 PM To: 'Henning Schulzrinne'; Jonathan Rosenberg Cc: 'sip@lists.bell-labs.com' Subject: RE: [SIP] DNS SRV records in stateless mode > -----Original Message----- > From: Henning Schulzrinne [mailto:schulzrinne@cs.columbia.edu] > Sent: Friday, September 15, 2000 9:21 PM > To: Jonathan Rosenberg > Cc: 'sip@lists.bell-labs.com' > Subject: Re: [SIP] DNS SRV records in stateless mode > > > To address the random routing problem, I've tentatively added the > following wording to the section on SRV usage (1.4.2): > > Within a transaction, a stateless proxy {\MUST} always select > the same > destination within the set of hosts with the same priority. > This can be > accomplished, for example, by using the modulo $N$ of a hash of the > \header{Call-ID} value or some other combination of > transaction-identifying headers as the uniform random number described > in the weighting algorithm of RFC 2782. Here, $N$ is the sum > of weights > within the priority class. > > > > This is somewhat messier than just taking bits, in order to > satisfy the > non-even weighting rules. Yes, I had forgotten about that. One small change. As worded, it seems like this only applies to stateless proxies, so that stateful ones could send to diffrent destinations. How about: Within a transaction, a proxy {\MUST} always select the same destination within the set of hosts with the same priority. This can be accomplished statelessly, for example, by using the modulo $N$ of a hash of the \header{Call-ID} value or some other combination of transaction-identifying headers as the uniform random number described in the weighting algorithm of RFC 2782. Here, $N$ is the sum of weights within the priority class. All I did was remove stateless from the top line and add it into the third. -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 ------_=_NextPart_001_01C021A2.98990E80 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: [SIP] DNS SRV records in stateless mode

This wording concerns me. I'm afraid of what the term = 'hash' may imply to implementors down the road. Since Call-IDs do not = need to be randomly selected, a (poor) hash of non-random sequence may = very well wind up not being random either. This wouldn't be easily = detectible in situations like bake-offs, where a limited number of = calls are made. But, if it were applied to a much larger scale, with = higher traffic, the problem could render the spirit of the weighting = algorithm of RFC 2782 moot. Instead of getting random, weighted server = selection; you're getting sort-of random, kind-of weighted server = selection. Imagine if a portion of a large IP backbone provider was = using SIP, and had a stateless proxy setup with DNS-SRV for load = balaning ran into this problem?

I think more stress needs to be placed on ensuring = that the hash is as random as possible (to the point of suggesting a = suitable hash algorithm, such as diving by a small prime number then = modulus that with the weight total). A lot of algorithms qualify as = hashing algorithms that may just great for small numbers of data = elements, but not for a high-traffic environment. Example: let's just = add up all the digits in the Call-ID, and mod that with the weighting = total (bad idea). I suspect that if we're having issues with fixed = length fields, that this sort of issue could easily creep up as well to = the detriment of the implementor.

Also, this poses another problem, one where we can = get out-of-sync with our record selection. Let's say we have an INVITE = that DNS-SRV returns two entries for, each at a different priority = level (priority A, and B, A is better). The proxy selects the entry = with priority A, and tries to route to the server listed in the SRV = record. That routing attempt times-out, so it fails over to the second = entry at priority B. During this time a retransmission of the INVITE is = sent by the originating UA, and is going to get hashed back to the = records with priority A in the proxy. However, we now know that route = is bad. We shouldn't re-select it for this transaction, we should go = straight to B for the retransmission as well.

There's ways around this for stateful proxies, but a = stateless proxy can't employ the same methods with your selection = method. UNLESS you also stipulate that you should remove an entry from = the list of selectable SRV entries left in the list once they're = excluded due to a timeout, or whatever other event the proxy = implementor deems appropriate.

Thoughts?

Brian Stucker
Nortel Networks



-----Original Message-----
From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
Sent: Sunday, September 17, 2000 11:53 PM
To: 'Henning Schulzrinne'; Jonathan Rosenberg
Cc: 'sip@lists.bell-labs.com'
Subject: RE: [SIP] DNS SRV records in stateless = mode





> -----Original Message-----
> From: Henning Schulzrinne [mailto:schulzrinne@cs.columb= ia.edu]
> Sent: Friday, September 15, 2000 9:21 PM
> To: Jonathan Rosenberg
> Cc: 'sip@lists.bell-labs.com'
> Subject: Re: [SIP] DNS SRV records in stateless = mode
>
>
> To address the random routing problem, I've = tentatively added the
> following wording to the section on SRV usage = (1.4.2):
>
> Within a transaction, a stateless proxy {\MUST} = always select
> the same
> destination within the set of hosts with the = same priority. 
> This can be
> accomplished, for example, by using the modulo = $N$ of a hash of the
> \header{Call-ID} value or some other = combination of
> transaction-identifying headers as the uniform = random number described
> in the weighting algorithm of RFC 2782.  = Here, $N$ is the sum
> of weights
> within the priority class.
>
>
>
> This is somewhat messier than just taking bits, = in order to
> satisfy the
> non-even weighting rules.


Yes, I had forgotten about that.

One small change. As worded, it seems like this only = applies to stateless
proxies, so that stateful ones could send to = diffrent destinations. How
about:

Within a transaction, a proxy {\MUST} always select = the same
destination within the set of hosts with the same = priority.  This can be
accomplished statelessly, for example, by using the = modulo $N$ of a hash of
the
\header{Call-ID} value or some other combination = of
transaction-identifying headers as the uniform = random number described
in the weighting algorithm of RFC 2782.  Here, = $N$ is the sum of weights
within the priority class.



All I did was remove stateless from the top line and = add it into the third.

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


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

------_=_NextPart_001_01C021A2.98990E80-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Sep 18 15:09: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 PAA17739 for ; Mon, 18 Sep 2000 15:09: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 4A89D443E2; Mon, 18 Sep 2000 14:08:55 -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 A8EA7443E2 for ; Mon, 18 Sep 2000 14:04:36 -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 OAA23688; Mon, 18 Sep 2000 14:04:33 -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 e8IJ3Wj08517; Mon, 18 Sep 2000 14:03:32 -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 OAA14028; Mon, 18 Sep 2000 14:04:32 -0500 (CDT) Received: (from eusadam@localhost) by b04a24.exu.ericsson.se (8.9.1/8.9.1) id OAA00344; Mon, 18 Sep 2000 14:04:31 -0500 (CDT) Message-Id: <200009181904.OAA00344@b04a24.exu.ericsson.se> Subject: Re: [SIP] Question concerning SIP/ISUP interworking To: annasimpson@lucent.com (Anna Simpson) Date: Mon, 18 Sep 2000 14:04:31 -0500 (CDT) Cc: Gonzalo.Camarillo@lmf.ericsson.se (Gonzalo Camarillo), sip@lists.bell-labs.com In-Reply-To: <39C62303.7DE64774@lucent.com> from "Anna Simpson" at Sep 18, 2000 03:13:23 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit I think you have to look at the context. In the case that I've sent an IAM to the ISUP network, a REL before a CON or ACM indicates an error of some sort. The concept of "normal call clearing" in an error situation doesn't make sense, and a switch really isn't expected to behave this way. In the case that the call hase already been set up, *all* REL messages are mapped to a BYE (I beleive this is covered in the draft), regardless of the release code. If the call *hasn't* been setup, you shouldn't send a BYE: I'm not sure how many implementations would react gracefully if they sent an INVITE, and received a BYE without any intervening INVITE response. Many will probably be okay, but this really isn't well defined behaviour. You're correct in your assertion that an unxpected release code during call setup should map to some error code which usually contains a "Retry-After" header; this will be taken into consideration for the next draft. Thanks for the feedback. /a >I am assuming that rel 16, normal call clearing would map to a BYE reques= >t. > >Is there any reason why a rel 31 could not be treated the same? > >I shall dig around and try and find some more information on when to use = >a REL 31 >to see if this helps. > >thanks for replying so quickly >Anna > > > >Gonzalo Camarillo wrote: > >> Hi, >> >> In order to understand this cause value is better to use negative >> statements: >> >> Cause 31 belongs to the normal class. So, it does not belong to the >> following classes: >> resource unavailable class, service or option unavailable class, >> protocol error class and interworking class. >> >> This gives a rough idea about the semantics of this cause value. Or to >> be more precise, it gives an idea about which are not the samentics of >> this cause value. >> >> Inside the normal class, there are specific cause values that are used >> for specific situations: >> >> 1 =96 Unallocated (unassigned) number >> 2 =96 No route to specified transit network (national use) >> 3 =96 No route to destination >> 4 =96 Send special information tone >> 5 =96 Misdialled trunk prefix (national use) >> 6 =96 Channel unacceptable >> 7 =96 Call awarded and being delivered in an established channel >> 8 =96 Preemption >> 9 =96 Preemption =96 circuit reserved for reuse >> 16 =96 Normal call clearing >> 17 =96 User busy >> 18 =96 No user responding >> 19 =96 No answer from user (user alerted) >> 20 =96 Subscriber absent >> 21 =96 Call rejected >> 22 =96 Number changed >> 23 =96 Redirection to new destination >> 25 =96 Exchange =96 routing error >> 26 =96 Non-selected user clearing >> 27 =96 Destination out of order >> 28 =96 Invalid number format (address incomplete) >> 29 =96 Facility rejected >> 30 =96 Response to STATUS ENQUIRY >> >> Then, cause value 31 is defined as: >> >> 31 =96 Normal, unspecified >> >> Therefore, cause value 31 is applicable when there is a normal release >> whose cause does not fall into the previous mentioned categories. It is= > >> a general purpose cause value. >> >> One might think inmediately that 400 Bad Request would be appropiate, >> but if this status code is used the UA that sent the INVITE might think= > >> that the systax of the INVITE was not correct. >> >> Actually you are right, and 404 does not suit this fine either. >> >> The best option might be 480 Temporarily Unavailable. This way the UA >> would try again after some time... >> >> Any ideas against or in favour of this change? >> >> We have been pretty busy lately but we intend to relase a more or less >> definitive version of this draft soon. >> >> Regards, >> >> Gonzalo >> >> Anna Simpson wrote: >> > >> > Hi, I have been studying SIP / ISUP interworking draft documents and = >I have a quesiton concerning >> > the SIP response / cause mappings. >> > >> > Working from "Best Current Practice for ISUP to SIP mapping", March 2= >000 >> > http://www.softarmor.com/sipwg/drafts/draft-camarillo-sip-isup-bcp-00= >=2Etxt >> > section 6.2.4 on page 21 shows >> > Release 31, normal unspecified is mapped to the SIP response 404, Not= > found. >> > >> > Could anyone explain why this mapping was chosen? >> > >> > Thanks >> > Anna >> > >> > _______________________________________________ >> > 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 > -- 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 Sep 18 17: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 RAA19931 for ; Mon, 18 Sep 2000 17:21: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 BFCE0443DC; Mon, 18 Sep 2000 16:21: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 D50774433E for ; Mon, 18 Sep 2000 16:21:00 -0400 (EDT) Received: from driftwood.cisco.com (driftwood.cisco.com [171.71.157.40]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id OAA04157; Mon, 18 Sep 2000 14:20:57 -0700 (PDT) Received: from cisco.com ([171.71.159.231]) by driftwood.cisco.com (Mirapoint) with ESMTP id ACI03265; Mon, 18 Sep 2000 16:20:55 -0500 (CDT) Message-ID: <39C68778.52D5DAF1@cisco.com> Date: Mon, 18 Sep 2000 16:22:00 -0500 From: Hong Chen Organization: Cisco Systems X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: "'rajeev@empowertel.com'" , "'Anders Kristensen'" , "'sip@lists.bell-labs.com'" Subject: Re: [SIP] SIP feature services 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > This question only makes sense in the context of directly applying the > IN model for SIP applications. I think SIP and its operation is sufficiently > different that this really doesn't make sense. > > In the SIP model, the AS is simply another SIP entity. This means that it > gets > the initial INVITE, along with any other signaling in the call (if it > record-routes). Exact issue here, since the AS SIP address should be set in the SIP URI of initial INVITE. Questions raised here are: who(UAC or SIP proxy) should set the AS SIP URI in INVITE request ? and How to find the SIP address for an AS serving the feature? > > Any "mid-call" event, such as a re-INVITE, gets to the AS because the proxy > will > forward the INVITE there are per normal SIP procedures. > > Rajeev writes: > > How do you indicate the occurence of a mid-call trigger (such > > as for call > > waiting) from a SIP proxy (which could be running in a > > softswitch) to an > > application server (which contains logic on how to handle the > > feature for > > this specific subscriber, and may be running on another > > SCP-like node)? This > > is a transaction-type messaging between SIP proxy and > > application server, > > which is not necessarily in the context of a SIP session > > setup between the > > two. > > -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 Sep 18 17:59: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 RAA20500 for ; Mon, 18 Sep 2000 17:59: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 B5C90443D8; Mon, 18 Sep 2000 16:59:19 -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 8A7EA4433E for ; Mon, 18 Sep 2000 16:59:16 -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 RAA16196; Mon, 18 Sep 2000 17:55:00 -0400 (EDT) Message-ID: <39C6902F.7EE4D30D@nist.gov> Date: Mon, 18 Sep 2000 17:59:12 -0400 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=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] A question on forwarding INVITES Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Hello! When a proxy server forwards an invite, does it need to have a registration from the server that it is forwarding it to (or is this an implementation choice)? Second, it would appear to be a good idea to periodically propagate user location information between proxy's to reduce latency in for user location. If so, is there a recommended method to do this? (and if not, is there a good argument against it?) I appreciate your help and thank you in advance for your replies. Regards, Ranga. -- M.Ranganathan NIST Advanced Networking Technologies Group, 100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899. Tel: 301 975 3664 Fax: 301 590 0934 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Sep 18 20:15: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 UAA21879 for ; Mon, 18 Sep 2000 20:15: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 3BAF9443D8; Mon, 18 Sep 2000 19:15:04 -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 6C1A64433E for ; Mon, 18 Sep 2000 19:15:00 -0400 (EDT) Received: by rwcxch02.clarent.com with Internet Mail Service (5.5.2650.21) id ; Mon, 18 Sep 2000 17:13:39 -0700 Message-ID: <6374EFC78443D41197DD00508B5C35DD0113FB43@rwcxch02.clarent.com> From: Jean-Francois Mule To: sip@lists.bell-labs.com Subject: [SIP] register method and cseq Date: Mon, 18 Sep 2000 17:13:38 -0700 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com This context of this message is: a SIP UA registers with SIP proxy server/registrar, the server issues 401 Unauthorized with challenge, SIP UA sends a REGISTER with proper credentials (A), server accepts and sends 200 OK... Then later on, SIP UA sends a "keepalive" msg (B) 2543bis-01 states: "registrations with the same Call-ID MUST have increasing CSeq header values" and "all registrations from a client SHOULD use the same Call-ID header value, at least within the same reboot cycle". So, 1. in case (A) - re-register with proper credentials, the SIP UA must send a REGISTER with a Cseq of CSeq: 2 REGISTER 2. in case (B) - keepalive, the SIP UA must increase CSeq for each periodical REGISTER msg sent.... 3 REGISTER ... 4 REGISTER... Correct? If that is the case, draft-ietf-sip-call-flows-01.txt needs to be corrected, at least in sections 2.1.1 and 2.2.1, msgs F3 REGISTER B -> SIP Server, and the subsequent responses F4 200 OK, etc. Jean-Francois Clarent corp. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Sep 18 20:25: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 UAA21970 for ; Mon, 18 Sep 2000 20:25: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 01879443E8; Mon, 18 Sep 2000 19:25:28 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from nwcst287.netaddress.usa.net (nwcst287.netaddress.usa.net [204.68.23.32]) by lists.bell-labs.com (Postfix) with SMTP id AB529443E5 for ; Mon, 18 Sep 2000 19:25:25 -0400 (EDT) Received: (qmail 6545 invoked by uid 60001); 19 Sep 2000 00:25:23 -0000 Message-ID: <20000919002523.6544.qmail@nwcst287.netaddress.usa.net> Received: from 204.68.23.32 by nwcst287 for [209.24.141.50] via web-mailer(34FM.0700.4.03) on Tue Sep 19 00:25:23 GMT 2000 Date: 18 Sep 00 18:25:23 MDT From: Nishith Chudasama To: sip@lists.bell-labs.com X-Mailer: USANET web-mailer (34FM.0700.4.03) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Subject: [SIP] SIP conference Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id UAA21970 Hi, Can anybody let me know, how does SIP keep track of conference members in case of Multiparty(more than 2) conference sessions? For example, in a three party conference, each member should be aware of other two members. That's how the data can be transfered to all the members (except the sender) in the conference. Or else, some controlling entity should be there making multiple copies of the received data and to send it to all the other members of the conference except the originator of the data. Is this the responsibility of RTP??? Thanks in advance. Regards, Nishith. ____________________________________________________________________ Get free email and a permanent address at http://www.netaddress.com/?N=1 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Sep 18 21:19: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 VAA22551 for ; Mon, 18 Sep 2000 21:19: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 8C61A443E1; Mon, 18 Sep 2000 20:19:06 -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 6E6874433E for ; Mon, 18 Sep 2000 20:19:01 -0400 (EDT) Received: from vctest1 ([192.168.1.153]) by marie.nada.co.kr (8.9.3/8.9.3) with SMTP id KAA23588 for ; Tue, 19 Sep 2000 10:23:30 +0900 Message-ID: <005b01c021d8$4eedbe30$9901a8c0@nadatel.com> From: "Junyoung Heo" To: References: <20000919002523.6544.qmail@nwcst287.netaddress.usa.net> Subject: Re: [SIP] SIP conference Date: Tue, 19 Sep 2000 10:23:33 +0900 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id VAA22551 In my opinion, conference/media control(such as keeping member information, media switching) is out of scope of SIP. I think this is implementor's responsibility. :) In my case(I want multi-unicast conference.), I make MCU supports SIP. and use origin of SDP as conference id. All participants already know origin of SDP via , for example, WWW. And, for conference control, I use mbus which is not RFC but draft. MCU switch media data automatically. RTP just play role as data sending/receiving. In multicast, I think RTP may be used actively. and terminal should get other's data from multicast session by itself. Audio data should be mixed at all terminal side. so, I gave up multicast conference. I wish my response is not a different with question. ----- Original Message ----- From: "Nishith Chudasama" To: Sent: Tuesday, September 19, 2000 9:25 AM Subject: [SIP] SIP conference > Hi, > > Can anybody let me know, how does SIP keep track of conference members in case > of Multiparty(more than 2) conference sessions? For example, in a three party > conference, each member should be aware of other two members. That's how the > data can be transfered to all the members (except the sender) in the > conference. Or else, some controlling entity should be there making multiple > copies of the received data and to send it to all the other members of the > conference except the originator of the data. > > Is this the responsibility of RTP??? > > Thanks in advance. > Regards, > Nishith. > > ____________________________________________________________________ > Get free email and a permanent address at http://www.netaddress.com/?N=1 > > > _______________________________________________ > 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 Mon Sep 18 23:31: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 XAA25971 for ; Mon, 18 Sep 2000 23:31: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 79EBC443CA; Mon, 18 Sep 2000 22:31:17 -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 77BC14433E for ; Mon, 18 Sep 2000 22:31:08 -0400 (EDT) Received: from sampark.hss.hns.com (sampark.hss.hns.com [139.85.229.22]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id e8J3VqC29501; Tue, 19 Sep 2000 09:01:52 +0530 (IST) Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 6525695F.0013C3EF ; Tue, 19 Sep 2000 09:05:53 +0530 X-Lotus-FromDomain: HSSBLR From: archow@hss.hns.com To: Cliff.Harris@nokia.com Cc: archow@hss.hns.com, sip@lists.bell-labs.com Message-ID: <6525695F.0013C248.00@sampark.hss.hns.com> Date: Tue, 19 Sep 2000 09:05:48 +0530 Subject: RE: [SIP] A warning to implementors 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Actually 4000 is just representational. I dont mean *I* use 4000 :-). How much of len you want to alloc is again a very implementation specific issue. Regds Arjun -- Arjun Roychowdhury @ Hughes Software Systems cliff> Note that the example of content-length in rfc-bis is "Content-Length: cliff> 3495". Cliff.Harris@nokia.com on 09/18/2000 07:27:39 PM To: archow cc: sip@lists.bell-labs.com Subject: RE: [SIP] A warning to implementors > -----Original Message----- > From: EXT archow@hss.hns.com [mailto:archow@hss.hns.com] > Sent: Monday, September 18, 2000 9:43 AM > To: Henning Schulzrinne > Cc: Jonathan Rosenberg; 'Eric Burger'; 'sip@lists.bell-labs.com' > Subject: Re: [SIP] A warning to implementors . . . > If you need to specify max size, I personally would prefer a > max. size for > a complete SIP message (for n/w read buffer > maybe) as compared to limits for particular headers. (ie I'd > much rather > say that he complete message can be of max > size 4000 bytes rather than saying From can be of 200, Route of 300 > etc......) > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com 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 Sep 19 01:15:22 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA28271 for ; Tue, 19 Sep 2000 01:15: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 38ED544363; Tue, 19 Sep 2000 00:14:51 -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 D6C8A44336 for ; Tue, 19 Sep 2000 00:14: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 BAA11900; Tue, 19 Sep 2000 01:16:41 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Tue, 19 Sep 2000 01:11:39 -0400 Message-ID: From: Jonathan Rosenberg To: "'Jean-Francois Mule'" , "'sip@lists.bell-labs.com'" Subject: RE: [SIP] register method and cseq Date: Tue, 19 Sep 2000 01:11:33 -0400 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com > -----Original Message----- > From: Jean-Francois Mule [mailto:jfmule@clarent.com] > Sent: Monday, September 18, 2000 8:14 PM > To: sip@lists.bell-labs.com > Subject: [SIP] register method and cseq > > > This context of this message is: a SIP UA registers with SIP proxy > server/registrar, the server issues 401 Unauthorized with > challenge, SIP UA > sends a REGISTER with proper credentials (A), server accepts > and sends 200 > OK... Then later on, SIP UA sends a "keepalive" msg (B) > > 2543bis-01 states: "registrations with the same Call-ID MUST > have increasing > CSeq header values" and "all registrations from a client > SHOULD use the same > Call-ID header value, at least within the same reboot cycle". > > So, > 1. in case (A) - re-register with proper credentials, the SIP > UA must send a > REGISTER with a Cseq of CSeq: 2 REGISTER Assuming the first REGISTER had CSeq: 1 REGISTER, anything higher (including 2) is fine. > 2. in case (B) - keepalive, the SIP UA must increase CSeq for each > periodical REGISTER msg sent.... 3 REGISTER ... 4 REGISTER... > > Correct? They must increase; there is no requirement that it be by one but thats of course fine. > > If that is the case, draft-ietf-sip-call-flows-01.txt needs > to be corrected, > at least in sections 2.1.1 and 2.2.1, msgs F3 REGISTER B -> > SIP Server, and > the subsequent responses F4 200 OK, etc. Thanks for pointing it out. -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 Sep 19 01:32: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 BAA00683 for ; Tue, 19 Sep 2000 01:32: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 1F210443E8; Tue, 19 Sep 2000 00:32:30 -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 8EA75443C2 for ; Tue, 19 Sep 2000 00:32: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 e8J5WNZ25632; Tue, 19 Sep 2000 07:32:23 +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 IAA22349; Tue, 19 Sep 2000 08:32:22 +0300 (EET DST) Message-ID: <39C6FA5F.80F68450@lmf.ericsson.se> Date: Tue, 19 Sep 2000 08:32:15 +0300 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: "Adam B. Roach" Cc: Anna Simpson , sip@lists.bell-labs.com Subject: Re: [SIP] Question concerning SIP/ISUP interworking References: <200009181904.OAA00344@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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Hi, A small review of this thread: In the draft, for ISUP to SIP calls we send a CANCEL if no 200 response for the INVITE has been received. I believe that this is the best behavior, as Adam pointed already out. It is OK if a UA decides to send a BYE instead, but we do not need to cover this case in the draft (for ISUP to SIP calls). Anna was asking about SIP to ISUP calls. In this situation, the gateway will send responses to the INVITE, so CANCEL is not applicable here. "Adam B. Roach" wrote: >In the case that I've sent an IAM to the ISUP network, a REL before a >CON or ACM indicates an error of some sort. The concept of "normal >call clearing" in an error situation doesn't make sense, and a switch >really isn't expected to behave this way. This is correct in the fixed network. However, when there is interworking with GSM for instance, the user has a chance of sending a REL before the ACM if he does not want to take the call. Anyway, as you said, this is already covered in the draft. 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 Tue Sep 19 01:33:57 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA00906 for ; Tue, 19 Sep 2000 01:33: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 C17B6443F2; Tue, 19 Sep 2000 00:32:59 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from md3.vsnl.net.in (md3.vsnl.net.in [202.54.6.35]) by lists.bell-labs.com (Postfix) with ESMTP id C44BF443F0 for ; Tue, 19 Sep 2000 00:32:53 -0400 (EDT) Received: from jana ([203.199.224.130]) by md3.vsnl.net.in (8.9.3/8.9.3) with SMTP id KAA03681; Tue, 19 Sep 2000 10:56:57 +0530 (IST) Message-ID: <020701c021fa$ca0d8c40$38c9a8c0@labs> From: "Pathangi N Janardhanan" To: , References: <8825695E.00609D66.00@hqoutbound.ops.3com.com> Subject: Re: [SIP] Do Requests using record-route always go over UDP Date: Tue, 19 Sep 2000 11:00:24 +0530 Organization: HCL Technologies India Ltd. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Hi Anoop, > The definition of Record-Route states that in the maddr field "transport > parameter" is not allowed. > > Does this mean that all Requests using Record-Route to reach the > destination can only go over UDP(default) since there is no way to specify TCP. > A proxy should not mandate the use of TCP, through the use of "transport parameter" in the maddr. It should be willing to accept both TCP and UDP. It would be upto the UA to initiate the request in either TCP or UDP which may be a configurable option on that UA. The reason why the "transport addr" should not be specified is given below from the draft "Inclusion of, say, a TCP transport parameter may prevent a UA that supports only UDP but reached the proxy inserting the Record-Route via another proxy from reaching this proxy " Jana _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Sep 19 01:43:22 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA01974 for ; Tue, 19 Sep 2000 01:43:22 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id BFA1C4435A; Tue, 19 Sep 2000 00:43: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 DC2634434D for ; Tue, 19 Sep 2000 00:42:58 -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 e8J5gtZ28331; Tue, 19 Sep 2000 07:42:55 +0200 (MEST) Received: from ericsson.fi (E0080C7FA22D6.lmf.ericsson.se [131.160.30.48]) by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id IAA23037; Tue, 19 Sep 2000 08:42:54 +0300 (EET DST) Message-ID: <39C6FCDC.3DC5DA59@ericsson.fi> Date: Tue, 19 Sep 2000 08:42:52 +0300 From: Hisham Khartabil X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Anoop_Tripathi@3com.com Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Which Proxies should be stateful References: <8825695E.005F2A55.00@hqoutbound.ops.3com.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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit ALL proxies MUST implement UDP. Statefull proxies MUST implement TCP, so P2 must accept messages on UDP. Regards Hisham Anoop_Tripathi@3com.com wrote: > Hi All, > > Consider a call from UA1 through P1, P2 to UA2. > > P2 wants to recieve all the messages on TCP. > > This makes P2 to be in stateful mode. P1 does not want to be stateful by > default. > But does it have to be stateful just because it has to send the message to P2 > over TCP. > > So, in brief, in this scenario can P1 stay in stateless mode? > > Thanks, > > Anoop > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > 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 Sep 19 01:48: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 BAA02750 for ; Tue, 19 Sep 2000 01:48: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 C68A044378; Tue, 19 Sep 2000 00:48: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 5978444353 for ; Tue, 19 Sep 2000 00:48: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 BAA11959; Tue, 19 Sep 2000 01:50:01 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Tue, 19 Sep 2000 01:44:59 -0400 Message-ID: From: Jonathan Rosenberg To: "'mranga@nist.gov'" , "'sip@lists.bell-labs.com'" Subject: RE: [SIP] A question on forwarding INVITES Date: Tue, 19 Sep 2000 01:44:48 -0400 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com > -----Original Message----- > From: M. Ranganathan [mailto:mranga@nist.gov] > Sent: Monday, September 18, 2000 5:59 PM > To: sip@lists.bell-labs.com > Subject: [SIP] A question on forwarding INVITES > > > Hello! > > When a proxy server forwards an invite, does it need to have a > registration from the server that it is forwarding it to (or > is this an > implementation choice)? No, it doesn't need to have a registration. Routing is a matter of local policy. A proxy can use whatever means it sees fit to determine what next hop to forward to. > > Second, it would appear to be a good idea to periodically propagate > user location information between proxy's to reduce latency in for > user location. If so, is there a recommended method to do this? (and > if not, is there a good argument against it?) Let me make sure I am understanding what you are proposing. Lets say I register to engineering.dynamicsoft.com. Your proposal is that my registration basically be propagated to dynamicsoft.com as well, so that calls for me (jdrosen@dynamicsoft.com) can go directly to my PC, rather than first to engineering and then to my PC? There is no way for this to be done now; its close in concept to what TRIP provides, but in this case its intra-domain and not phone numbers. I don't think its a good idea in any case, as it presents a monstrous scalability problem. I'll also note that in many cases proxies exist on the call establishment path for useful purposes, and bypassing them is not necessarily a good thing. -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 Sep 19 02:00: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 CAA03957 for ; Tue, 19 Sep 2000 02:00: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 8E68844376; Tue, 19 Sep 2000 01:00:11 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from md3.vsnl.net.in (md3.vsnl.net.in [202.54.6.35]) by lists.bell-labs.com (Postfix) with ESMTP id E106C4436A for ; Tue, 19 Sep 2000 01:00:05 -0400 (EDT) Received: from jana ([203.199.224.130]) by md3.vsnl.net.in (8.9.3/8.9.3) with SMTP id LAA21272; Tue, 19 Sep 2000 11:24:20 +0530 (IST) Message-ID: <023a01c021fe$94152f40$38c9a8c0@labs> From: "Pathangi N Janardhanan" To: , References: <8825695E.005F2A55.00@hqoutbound.ops.3com.com> Subject: Re: [SIP] Which Proxies should be stateful Date: Tue, 19 Sep 2000 11:27:49 +0530 Organization: HCL Technologies India Ltd. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Hi Anoop, > P2 wants to recieve all the messages on TCP. This cannot be mandated. P2 must be willing to accept UDP also. > > This makes P2 to be in stateful mode. P1 does not want to be stateful by > default. P2 can receive in UDP and still be stateful. The decision to be stateful or not should not tied to the lower transport protocol. > But does it have to be stateful just because it has to send the message to P2 > over TCP. No, P1 can send on UDP and if P2 wants it can still be stateful. > > So, in brief, in this scenario can P1 stay in stateless mode? P1 will also have to support TCP, sicne the specification says Proxies, Regsitrars and Redirect Servers MUST implement both UDP and TCP. If any proxy contacts P1 over TCP, and P1 MUST accept the call and behave as transaction stateful for that transaction. Jana _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Sep 19 02:02: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 CAA06856 for ; Tue, 19 Sep 2000 02:02: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 50F21443A3; Tue, 19 Sep 2000 01:02: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 59AC844353 for ; Tue, 19 Sep 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 CAA12048; Tue, 19 Sep 2000 02:04:02 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Tue, 19 Sep 2000 01:59:00 -0400 Message-ID: From: Jonathan Rosenberg To: "'Hong Chen'" , Jonathan Rosenberg Cc: "'rajeev@empowertel.com'" , "'Anders Kristensen'" , "'sip@lists.bell-labs.com'" Subject: RE: [SIP] SIP feature services Date: Tue, 19 Sep 2000 01:58:53 -0400 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com > -----Original Message----- > From: Hong Chen [mailto:hjlechen@cisco.com] > Sent: Monday, September 18, 2000 5:22 PM > To: Jonathan Rosenberg > Cc: 'rajeev@empowertel.com'; 'Anders Kristensen'; > 'sip@lists.bell-labs.com' > Subject: Re: [SIP] SIP feature services > > > > > Jonathan Rosenberg wrote: > > > This question only makes sense in the context of directly > applying the > > IN model for SIP applications. I think SIP and its > operation is sufficiently > > different that this really doesn't make sense. > > > > In the SIP model, the AS is simply another SIP entity. This > means that it > > gets > > the initial INVITE, along with any other signaling in the > call (if it > > record-routes). > > Exact issue here, since the AS SIP address should be set in > the SIP URI of > initial INVITE. > Questions raised here are: > who(UAC or SIP proxy) should set the AS SIP URI in INVITE > request ? and > How to find the SIP address for an AS serving the feature? First off, its not strictly necessary to actually set the request URI to have a host part that points to the AS. A proxy or UA can send a request with any request URI to the AS, and then it would perform its feature processing. This is analagous in http where you can send a request to an http proxy even though the request URI points to some other host. In fact, modifying the request URI is probably bad, since it likely contains some useful information for feature processing. As to whom should send a request to the AS - that depends on the architecture of your network. How to find its address is a hard problem. Right now, static configuration of rules and conditions is the only way. Ideally, I'd like to have some way for application servers to propagate information on their application invocation conditions to upstream proxies or UAs. This way, I need only drop an application into an AS, and it would take care of propagating the routing information so that it gets properly invoked. This kind of propagation is what I have referred to as "service routing". It can be viewed as a multi-dimensional routing problem. The reason its multi-dimensional is that the criteria for application invocation can be quite varied. Its not just "request URI = foo"; it can be based on the From field (for outgoing features, in general), To field, Request URI, and components there in. For example, a departmental outgoing call screening application might execute whenever a call with a From field domain of cs.columbia.edu is found. Service execution might also depend on a subscriber list. For example, a call forward no answer service might execute if the called party subscribes to the service. In this case, the criteria for application invocation depends on matching the user@host portion of the request URI against a potentially long list of subscribers. Not all of the criteria for service invocation need be propagated; perhaps only the general criteria are propagated, and then the specifics are verified at the AS itself. In fact, the verification might itself be part of the application. For example, lets say columbia.edu has an call forward service enabled for certain students in its CS department, depending on their GPA (above 3.5, and they get the service). In this case, the application might propagate the rule "INVITE request with request URI domain cs.columbia.edu will trigger execution of CFNA at AS 3.4.5.6 port 5060". When the call arrives at the AS, it will need to run and check the GPA of the called party against the university database. If their GPA is too low, the call is simply proxied without doing anything special. -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 Sep 19 02:10: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 CAA09681 for ; Tue, 19 Sep 2000 02:10: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 9E24D4437F; Tue, 19 Sep 2000 01:09:46 -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 A728044373 for ; Tue, 19 Sep 2000 01:09:39 -0400 (EDT) Received: from sampark.hss.hns.com (sampark.hss.hns.com [139.85.229.22]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id e8J68wC04692 for ; Tue, 19 Sep 2000 11:39:02 +0530 (IST) Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 6525695F.0021E6F9 ; Tue, 19 Sep 2000 11:40:18 +0530 X-Lotus-FromDomain: HSSBLR From: airoy@hss.hns.com To: sip@lists.bell-labs.com Message-ID: <6525695F.0021E6C5.00@sampark.hss.hns.com> Date: Tue, 19 Sep 2000 11:39:15 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [SIP] syntax clarifications in the bis-draft-02 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com hi.. A doubt in the ABNF of the bis-draft-02 dated Sept 04, 2000 Alert-Info = "Alert-Info" ":" # ( " < " URI " > " *( ";" generic-param )) Call-Info = "Call-Info" ":" # ( " < " URI " > " *( ";" info-param) ) Error-Info = "Error-Info" ":" # ( " < " URI " > " *( ";"generic-param )) all these indicate that the header can just be alert-info: with blank header body...shouldn't they all be 1# ??? also sections H and I of the bis draft have the same title "changes to 01"... regards, Ashok Ashok Roy @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 Sep 19 04:36: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 EAA10506 for ; Tue, 19 Sep 2000 04:36: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 0397B4435A; Tue, 19 Sep 2000 03:36:28 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id 7D72B44336 for ; Tue, 19 Sep 2000 03:36:24 -0400 (EDT) Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id JAA05644; Tue, 19 Sep 2000 09:33:14 +0100 (BST) From: "Jo Hornsby" To: "Pathangi N Janardhanan" , , Subject: RE: [SIP] Which Proxies should be stateful Date: Tue, 19 Sep 2000 09:33:14 +0100 Message-ID: <000901c02214$4081c2b0$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: <023a01c021fe$94152f40$38c9a8c0@labs> Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Jana wrote: > P1 will also have to support TCP, sicne the > specification says Proxies, Regsitrars and > Redirect Servers MUST implement both UDP > and TCP. If any proxy contacts P1 over > TCP, and P1 MUST accept the call and > behave as transaction stateful for that transaction. Bleh. I'd previously missed this somehow, but the first sentence of this text is pretty-much from Section 1.5.2; and surely it's not right? Given recent discussions about "stateless" proxies responding definitively, how about: "User agents, proxies, registrar, and redirect servers MUST implement UDP and SHOULD implement TCP transport." (I am right about UDP being mandated across the board now, right? Although am I imagining things when I say I saw it on the "Open Issues" List?) Further, A.1 (bis 02) says: "User agents and stateless proxies MUST support UDP and MAY support TCP or other transport protocols, stateful proxies MUST support both UDP and TCP." I think this is slightly confusing (Logical Roles rears it's Ugly Head once again). How about reusing the sentence suggested for 1.5.2, with a slight clarifaction on when it is necessary to behave statefully, a la: "User agents, proxies, registrar, and redirect servers MUST implement UDP, SHOULD implement TCP, and MAY implement other transport protocols. Any client or server utilising a reliable transport such as TCP for a request MUST behave statefully for the duration of that transaction." - 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 Sep 19 08:43: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 IAA14143 for ; Tue, 19 Sep 2000 08:43: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 753834435A; Tue, 19 Sep 2000 07:42:51 -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 4B3624434C for ; Tue, 19 Sep 2000 07:42:47 -0400 (EDT) Received: from esealnt406 (esealnt406.al.sw.ericsson.se [153.88.251.29]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id e8JCght08152 for ; Tue, 19 Sep 2000 14:42:43 +0200 (MEST) Received: FROM esealnt172.ericsson.se BY esealnt406 ; Tue Sep 19 14:42:35 2000 +0200 Received: by esealnt172 with Internet Mail Service (5.5.2651.58) id ; Tue, 19 Sep 2000 14:42:43 +0200 Message-ID: From: "Stefan Runeson (ECS)" To: "'sip@lists.bell-labs.com'" Date: Tue, 19 Sep 2000 14:42:34 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="ISO-8859-1" Subject: [SIP] Call-ID in Two-party Call example Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Hello, In Chapter 16.3 of RFC2543bis there is an example of a two-party call. The INVITE message is transmitted with Call-ID: 662606876@kton.bell-tel.com. The first and second responses use the same Call-ID. From the third response, the Call-ID 3298420296@kton.bell-tel.com is used instead. Is this correct? BR Stefan Runeson Ericsson Mobile Communications AB S - 221 83 Lund SWEDEN * E-mail: mailto:Stefan.Runeson@ecs.ericsson.se * Phone: +46 46 19 39 38 Mobile: +46 708 84 07 59 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Sep 19 08:52: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 IAA14364 for ; Tue, 19 Sep 2000 08:52: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 8A18844376; Tue, 19 Sep 2000 07:52:24 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id BA04044336 for ; Tue, 19 Sep 2000 07:52:10 -0400 (EDT) Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id NAA02281; Tue, 19 Sep 2000 13:49:59 +0100 (BST) Message-ID: <39C760F6.C0F31E98@ubiquity.net> Date: Tue, 19 Sep 2000 13:49:58 +0100 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: "Stefan Runeson (ECS)" , "'sip@lists.bell-labs.com'" Subject: Re: [SIP] Call-ID in Two-party Call example 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit "Stefan Runeson (ECS)" wrote: > > Hello, > > In Chapter 16.3 of RFC2543bis there is an example of a two-party call. The INVITE message is transmitted with Call-ID: 662606876@kton.bell-tel.com. The first and second responses use the same Call-ID. From the third response, the Call-ID 3298420296@kton.bell-tel.com is used instead. Is this correct? No, the Call-ID should remain the same throughout a call. 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 Sep 19 08:57: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 IAA14532 for ; Tue, 19 Sep 2000 08:57: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 3F95F4438D; Tue, 19 Sep 2000 07:57:22 -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 2352F44336 for ; Tue, 19 Sep 2000 05:37:07 -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 GAA11333; Tue, 19 Sep 2000 06:37:04 -0400 (EDT) Message-Id: <200009191037.GAA11333@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 Date: Tue, 19 Sep 2000 06:37:03 -0400 Subject: [SIP] I-D ACTION:draft-ietf-sip-cc-transfer-01.txt Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com --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 Call Control Author(s) : R. Sparks Filename : draft-ietf-sip-cc-transfer-01.txt Pages : 18 Date : 18-Sep-00 This document defines a SIP extension within the new Call Control Framework to provide Call Transfer capabilities. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-cc-transfer-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-cc-transfer-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-cc-transfer-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000918144049.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-cc-transfer-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-cc-transfer-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000918144049.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 Sep 19 09:01: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 JAA14595 for ; Tue, 19 Sep 2000 09:01: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 0DEA3443A0; Tue, 19 Sep 2000 07:57:27 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mel.alcatel.fr (mel.alcatel.fr [212.208.74.132]) by lists.bell-labs.com (Postfix) with ESMTP id E066444336 for ; Tue, 19 Sep 2000 03:30:03 -0400 (EDT) Received: from aifhs2.alcatel.fr (mailhub.alcatel.fr [155.132.180.80]) by mel.alcatel.fr (ALCANET/SMTP) with ESMTP id KAA07555 for ; Tue, 19 Sep 2000 10:29:31 +0200 Received: from medine.ms.alcatel.fr (medine.ms.alcatel.fr [193.105.117.1]) by aifhs2.alcatel.fr (ALCANET/SMTP2) with ESMTP id KAA21927 for ; Tue, 19 Sep 2000 10:27:31 +0200 (MET DST) Received: from ms.ms.alcatel.fr (aar.ms.alcatel.fr [188.9.12.93]) by medine.ms.alcatel.fr (8.8.8/8.8.8/aar-1.2) with ESMTP id KAA26225 for ; Tue, 19 Sep 2000 10:29:47 +0200 (MET DST) Received: from young.dinsunnet (young [188.9.34.36]) by ms.ms.alcatel.fr (8.8.7/8.8.7/aar-1.0) with ESMTP id KAA16767 for ; Tue, 19 Sep 2000 10:29:45 +0200 (MET DST) Received: from ms.alcatel.fr by young.dinsunnet (8.9.1b+Sun/SMI-SVR4) id KAA01567; Tue, 19 Sep 2000 10:29:46 +0200 (MET DST) Message-ID: <39C723FA.D5C30BA9@ms.alcatel.fr> Date: Tue, 19 Sep 2000 10:29:46 +0200 From: Francois-Xavier Guitton X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: SIP Subject: [SIP] Modify media during a call Content-Type: multipart/alternative; boundary="------------B9EB0CFB238BA4FB888D4D98" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com --------------B9EB0CFB238BA4FB888D4D98 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit All, Just a quick question: Is it possible to modify a media codec type during a call thanks to a second INVITE ? ( I can not find in the spec RFC 2543 where that case is described) e.g.: A INVITE B with media m=audio 49170 RTP/AVP 0 , and the call is successfully established. May A re-INVITE B in replacing the media line by m=audio 49170 RTP/AVP 2 (to replace PCMU by G721) ? Fx./. -- Francois-Xavier Guitton (SWD/ULC) mailto:Francois-Xavier.Guitton@ms.alcatel.fr Tel: +33 (0)1 69 63 47 52 Fax: +33 (0)1 69 63 17 89 --------------B9EB0CFB238BA4FB888D4D98 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit 
All,
Just a quick question: Is it possible to modify a media codec type during a call thanks to a second INVITE ? ( I can not find in the spec RFC 2543 where that case is described)
e.g.: A INVITE B with media m=audio 49170 RTP/AVP 0 , and the call is successfully established.
May A re-INVITE B in replacing the media line by m=audio 49170 RTP/AVP 2 (to replace PCMU by G721) ?



Fx./.



-- 
Francois-Xavier Guitton (SWD/ULC)
mailto:Francois-Xavier.Guitton@ms.alcatel.fr      
Tel: +33 (0)1 69 63 47 52                    
Fax: +33 (0)1 69 63 17 89

 

--------------B9EB0CFB238BA4FB888D4D98--




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


From sip-admin@lists.bell-labs.com  Tue Sep 19 09:05:57 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA14703
	for ; Tue, 19 Sep 2000 09:05: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 97E1D443BF; Tue, 19 Sep 2000 07:57:36 -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 0349E4436A
	for ; Tue, 19 Sep 2000 01:14:07 -0400 (EDT)
Received: from hotfoon.com ([203.197.20.59])
	by hd2.dot.net.in (8.8.8/8.8.8) with ESMTP id LAA00525
	for ; Tue, 19 Sep 2000 11:39:54 +0530 (IST)
Message-ID: <39C7047B.1880C9D6@hotfoon.com>
Date: Tue, 19 Sep 2000 11:45:23 +0530
From: diyanat 
Organization: Paradigm Computers Pvt. LTD
X-Mailer: Mozilla 4.74 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: sip@lists.bell-labs.com
Subject: Re: [SIP] IM Questions
References: <39C6004B.A98EA22D@hotfoon.com> <39C63349.15A168C2@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-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

sean,

i guess that i was a little abrupt with my rantings. i have, in an
earlier post covered some issues of IM that i have faced with practical
implementations. let me very briefly run through them.

First Issue:
A group chat may or may not use a centralised server. 
IF we use a centralised server
        the bandwidth requirements of the centralised server 
        will go up as the square of the number of users per group.
        for ex: if there are three members in a group,
                        each message is relayed twice.
                if there are fifty memebers in a group,
                        each message is relyaed 50 times.
ELSE we use a peer to peer group chat
       each member of the group has to be informed of any
       new members joining or leaving the group. so that
       the group list is synchronised by everyone.

in our implementation, we did the following:
1. new group starts it's life as a 1-1 chat between two users. this
essentially consists of MESSAGE requests flying back and forth with the
same Call-ID but different CSeq for each message.
2. a new user is INVITEd to join the group by sending (hold your
breath!) and INVITE message with SDP specifying SIP/2.0/UDP MESSAGE as
the media description. multiple a=participant=userid specify the other
participants in the list.
3. upon receiving an INVITE, the called user reacts just like a normal
SIP response and awaits an ACK from the caller.
4. Once the MESSAGE session is established, the called user sends a
dummy MESSAGE with the group chat's Call-ID to update everyone's group
list.

the advantages of this scheme are:
1. any member of the list can now choose between taking a text only or a
text+voice chat. this is especially important if the UA can handle only
one voice call while being able to handle multiple message sessions.
2. a user can maintain (and it does in our UA) the list of banned userid
or refuse to receive messages from a particular user.
3. while sending a message to all the group members, if a 200 OK
response doesnt arrive from a particular user, the user is removed from
the group list if it is a final response. thus, a userid is removed from
a list when a user returns with a 400+ final response.
4. as the scheme is completely peer-to-peer, the centralised chat server
bandwidth is conserved and the users have to pay (nominally though, text
is hardly bandwidth intensive) by bandwidth whenever they send a group
message.
5. this scheme can very well include using a group chat server (where
in, the chat server represents a bunch of users).
6. this scheme will work well with the existing clients that understand
only MESSAGE, INVITE. we are only adding a new session type.INVITE is
interpreted the same way as before.

Second Issue:
dr. rosenberg convinced me that polymorphism of MESSAGE is a bad idea
and thus, there is no point using MESSAGE to invite a  user. invite with
an INVITE, and message with a MESSAGE. get out of a group by saying BYE.
simple.

the idea of a session-less messaging is great. It is essentially a page.
an SMS for the Net. If the MESSAAGE receiver returns a reply back with
the same Call-ID, then it is an ad-hoc session, else it was a page and
sender can forget about the MESSAGE. am i right on this?

But are we moving towards IM domination or are we adding minimal IM for
functionality? the approach in would be different for the two aims. If
we are to provide a high class IM, then we cannot bifurcate the
SUBSCRIBE, MESSAGE and REGISTER into separate and independent proposals.
they all MUST be implemented and available together. The solution has to
be optimal in anycase. For instance, within a single SUBSCRIBE message,
we should be able to subscribe to more than one presentities. Similarly,
in MESSAGE we need to be able to CC to more than one people. we need to
adding forking, we need to add message signing and we need to add store
and forward deliveries (deliver me a message that coffee is ready in 5
minutes).

Issue three:
the main advantage of peer to peer messaging is that there are no
servers to crash out and attack. a trivial Redirect UDP server handling
REGISTER and MESSAGE is all that is required. this is architecturally a
beautiful piece. the problem is that without a server, that you cannot
add more services and functionality to a network unless the UAs are
replaced. while in a server based messaging system, sky is the limit
(rather, the complexity and bandwidth are the limitations).
it would be best if you could leave out the decision of either of the
two to the implementors and have a protocol that will work well in both
cases. I think that MESSAGE is one such scheme. But SUBSCRIBE is not. In
a steamy undernet server, i cant imagine sending SUBSCRIBE to over
hunderd users each time I join or leave a group.

- farhan



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


From sip-admin@lists.bell-labs.com  Tue Sep 19 09:08: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 JAA14762
	for ; Tue, 19 Sep 2000 09:08: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 05614443C7; Tue, 19 Sep 2000 07:57:41 -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 8ABAB4434C
	for ; Tue, 19 Sep 2000 07:40: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 IAA03713;
	Tue, 19 Sep 2000 08:40:18 -0400 (EDT)
Message-ID: <39C75EB1.31AC1510@cs.columbia.edu>
Date: Tue, 19 Sep 2000 08:40:17 -0400
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: airoy@hss.hns.com
Cc: sip@lists.bell-labs.com
Subject: Re: [SIP] syntax clarifications in the bis-draft-02
References: <6525695F.0021E6C5.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-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

airoy@hss.hns.com wrote:
> 
> hi..
> 
> A  doubt in the ABNF of the bis-draft-02 dated Sept 04, 2000
> 
> Alert-Info = "Alert-Info" ":" # ( " < " URI " > " *( ";" generic-param ))
> Call-Info = "Call-Info" ":" # ( " < " URI " > " *( ";" info-param) )
> Error-Info = "Error-Info" ":" # ( " < " URI " > " *( ";"generic-param ))
> 
> all these indicate that the header can just be
>      alert-info:
> with blank header body...shouldn't they all be 1# ???

Generally, empty headers are ok. I don't see a reason to prohibit them.
Encourages robustness...

> 
> also sections H and I of the bis draft have the same title "changes to
> 01"...

Fixed.



-- 
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 Sep 19 09:12: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 JAA14857
	for ; Tue, 19 Sep 2000 09:12: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 37CCA443D4; Tue, 19 Sep 2000 07:57:45 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from turin.trillium.com (turin.trillium.com [38.187.146.197])
	by lists.bell-labs.com (Postfix) with ESMTP id 56CCD4433E
	for ; Mon, 18 Sep 2000 18:22:59 -0400 (EDT)
Received: from aiglos.trillium.com (smtp.trillium.com [192.168.3.20])
	by turin.trillium.com (8.11.0/8.11.0) with ESMTP id e8INRPH07585
	for ; Mon, 18 Sep 2000 16:27:25 -0700 (PDT)
Received: from aega.trillium.com (aega.trillium.com [192.168.1.19])
	by aiglos.trillium.com (8.9.3/8.9.3) with ESMTP id QAA28253
	for ; Mon, 18 Sep 2000 16:22:38 -0700 (PDT)
Received: by aega.trillium.com with Internet Mail Service (5.5.2650.21)
	id ; Mon, 18 Sep 2000 16:14:02 -0700
Message-ID: <8BBD33A986C5D311804000902719FF5DC09A9E@aega.trillium.com>
From: Aseem Agarwal 
To: sip 
Date: Mon, 18 Sep 2000 16:14:01 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [SIP] Overlap dialing in SIP
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com

I need some clarification about overlap dialing in SIP as referred in
Section 4.2.1

"A UAC MUST NOT issue another INVITE request for the same call leg
before the previous transaction has completed"

"A UAS acting as a gateway ..."

The above two references are confusing. If a UAC can not initiate 
a reINVITE before receiving a definite response, how does a UAS at a
GW get additional digits ? A Gateway can get additional digits once 
the call is established (may be for supplementary services)but not 
in call set up phase. Is this correct ? 

Another source of confusion :

"If the UAC wishes to modify the session after the call set up has
begun, it MUST use another INVITE request"

Can a UA after sending an INVITE, send another INVITE for modifying the
session parameters before getting a definite response ( in call set up 
phase itself) ?

-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 Sep 19 09:27: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 JAA15129
	for ; Tue, 19 Sep 2000 09:27: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 150394439E; Tue, 19 Sep 2000 08:27:19 -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 1CF8044388
	for ; Tue, 19 Sep 2000 08:27: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 e8JDR8t07263;
	Tue, 19 Sep 2000 15:27:08 +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 QAA28437;
	Tue, 19 Sep 2000 16:27:07 +0300 (EET DST)
Message-ID: <39C769A3.517F96E0@lmf.ericsson.se>
Date: Tue, 19 Sep 2000 16:26:59 +0300
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: Anna Simpson 
Cc: "Adam B. Roach" , sip@lists.bell-labs.com,
        "Vijay K. Gurbani" 
Subject: Re: [SIP] Question concerning SIP/ISUP interworking
References: <200009181904.OAA00344@b04a24.exu.ericsson.se> <39C6FA5F.80F68450@lmf.ericsson.se> <39C76388.93A9FBA9@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-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

Hi,

Anna Simpson wrote:
> 
> All,
> 
> This is my understanding from your emails and the spec.
> 
> If a call is established, e.g. a 200 [OK] has been received in
> response to
> the INVITE then a BYE message will be sent.

Yes.

> For a SIP to ISUP call the 200 [OK] is sent on receiving the CON or
> ANM
> over ISUP.

Yes.

> For an ISUP to SIP call the 200 [OK] is received when the SIP node
> answers
> the call and will be mapped to an ANM or CON, as appropriate.

Yes.

> 
> For the calling or called party to now release a BYE would map to a
> REL(16)
> and vice versa.

Yes.

> 
> Adam stated once a call is set up all REL messages are mapped to a
> BYE.
> If this is so then the BYE will need to contain information to
> distinguish between
> different REL messages otherwise information can be lost. (however
> this is a seperate
> issue).

Actually you don't usually need this information in the SIP network, but
if you still want to have it available you can embed the REL in the body
of the BYE, for instance.

 
> If the call is still being setup then either a response is seen or a
> CANCEL.
> (A BYE could be used but is not the preferred option).
> e.g.
> SIP to ISUP
> calling tears down before called answers then a CANCEL is sent and
> mapped to
> a REL 16.ref 6.1.9. in the spec.

Yes.

> 
> If the call ends for another reason then a SIP response is sent.

I do not think I follow you. A SIP response is sent from the server. A
CANCEL is sent by the client.

> 
> If I have the above correct then I am back to the original question of
> why
> map a REL 31 to a 404 response.
> I have been searching through the ITU specs to try and find examples
> of
> when a rel 31 is used, rather than just saying when another normal
> cause value
> is inappropriate.
> I found this example in Q.764, 2.2.4
> If a call set-up fails and an in-band tone or announcement has to be
> returned to the
> calling party from an exchange or called party, the exchange or user
> concerned
> connects the in-band tone or announcement to the transmission path. If
> a time-out
> occurs at the exchange providing the in-band tone or announcement, the
> exchange
> sends a release message to the preceding exchange with cause value 31
> (normal
> unspecified).
> To me this does not look like a 404 NOT FOUND.
>

As I said in a previous mail, I find 480 more appropiate. We'll change
it.

 
> However I am clueless as to which response would be more appropriate
> if we
> cannot use a CANCEL or BYE.

You cannot use them because you are a server, not a client, and you have
to terminate the transaction that was initiated by the INVITE received.

Anyway, I believe that the call flows and the state machines in the
draft describe this pretty clearly.

Best regards,

Gonzalo

> During the definition of SIP was it ever considered that there should
> be catch
> all responses, that would say mimic this ISUP catch all cause values?
> Or is this something that is not needed by SIP.
> 
> Thanks for your thoughts so far, this discussion has been very
> beneficial to
> my understanding of SIP.
> 
> Anna

-- 
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 Sep 19 10:00: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 KAA15815
	for ; Tue, 19 Sep 2000 10:00: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 14C6144361; Tue, 19 Sep 2000 08:59:50 -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 9561444348
	for ; Tue, 19 Sep 2000 08:59:43 -0400 (EDT)
Received: from sampark.hss.hns.com (sampark.hss.hns.com [139.85.229.22])
	by mars.hss.co.in (8.10.0/8.10.0) with SMTP id e8JDw5C16065;
	Tue, 19 Sep 2000 19:28:06 +0530 (IST)
Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2  (651.2 6-10-1998))  id 6525695F.004D171E ; Tue, 19 Sep 2000 19:32:01 +0530
X-Lotus-FromDomain: HSSBLR
From: airoy@hss.hns.com
To: Henning Schulzrinne 
Cc: sip@lists.bell-labs.com
Message-ID: <6525695F.004D1624.00@sampark.hss.hns.com>
Date: Tue, 19 Sep 2000 19:31:58 +0530
Subject: Re: [SIP] syntax clarifications in the bis-draft-02
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-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com








Henning Schulzrinne  on 09/19/2000 06:10:17 PM

To:   Ashok I Roy/HSSBLR
cc:   sip@lists.bell-labs.com

Subject:  Re: [SIP] syntax clarifications in the bis-draft-02




airoy@hss.hns.com wrote:
>
> hi..
>
> A  doubt in the ABNF of the bis-draft-02 dated Sept 04, 2000
>
> Alert-Info = "Alert-Info" ":" # ( " < " URI " > " *( ";" generic-param ))
> Call-Info = "Call-Info" ":" # ( " < " URI " > " *( ";" info-param) )
> Error-Info = "Error-Info" ":" # ( " < " URI " > " *( ";"generic-param ))
>
> all these indicate that the header can just be
>      alert-info:
> with blank header body...shouldn't they all be 1# ???

>>Generally, empty headers are ok. I don't see a reason to prohibit them.
>>Encourages robustness...


yes i agree with what you are trying to say...but shouldn't this be
standardised across ALL headers??..for example the syntax for route or
record route mandates at least one value in  the header body....now a
parser implemtation that rigidly adheres to the ABNF would throw errors  if
the record route field was empty though for robustness it shouldn't
...apart from robustness is there any other reason for allowing an empty
header?

imho that we should follow one convention...to either allow empty headers
or to treat them as errors...throughout.

regards,
ashok

------
ashok roy @ 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 Sep 19 11:27: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 LAA17566
	for ; Tue, 19 Sep 2000 11:27: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 69A4544346; Tue, 19 Sep 2000 10:27:16 -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 894B244348
	for ; Tue, 19 Sep 2000 08:56:05 -0400 (EDT)
Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Tue Sep 19 09:54:04 EDT 2000
Received: by lists.bell-labs.com (Postfix)
	id 7278C4437D; Tue, 19 Sep 2000 09:40:55 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from ukmail.uk.lucent.com (ukmail.uk.lucent.com [135.86.160.50])
	by lists.bell-labs.com (Postfix) with ESMTP id DC9A444341
	for ; Tue, 19 Sep 2000 09:40:53 -0400 (EDT)
Received: from lucent.com (uk0006166d078.uk.lucent.com [135.86.166.78]) by ukmail.uk.lucent.com (8.8.8+Sun/EMS-1.5 sol2)
	id OAA05029; Tue, 19 Sep 2000 14:40:49 +0100 (BST)
Message-ID: <39C76D4E.6EA19083@lucent.com>
Date: Tue, 19 Sep 2000 14:42:39 +0100
From: Anna Simpson 
Organization: Lucent Technologies
X-Mailer: Mozilla 4.6 [en]C-CCK-MCD EMS-1.4  (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Gonzalo Camarillo 
Cc: "Adam B. Roach" , sip@lists.bell-labs.com,
        "Vijay K. Gurbani" 
Subject: Re: [SIP] Question concerning SIP/ISUP interworking
References: <200009181904.OAA00344@b04a24.exu.ericsson.se> <39C6FA5F.80F68450@lmf.ericsson.se> <39C76388.93A9FBA9@lucent.com> <39C769A3.517F96E0@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-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

Gonzalo,

Thanks, I think I am finally getting there.

I shall go back and look at the Server vs Client releases.

Thanks again
Anna




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


From sip-admin@lists.bell-labs.com  Tue Sep 19 11:29: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 LAA17590
	for ; Tue, 19 Sep 2000 11:29: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 5025744356; Tue, 19 Sep 2000 10:27:19 -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 E26C544348
	for ; Tue, 19 Sep 2000 09:29: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 JAA17049;
	Tue, 19 Sep 2000 09:29: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 e8JESMj27865;
	Tue, 19 Sep 2000 09:28:22 -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 JAA26110; Tue, 19 Sep 2000 09:29:24 -0500 (CDT)
Message-ID: <39C77841.D82EC3A9@ericsson.com>
Date: Tue, 19 Sep 2000 16:29:21 +0200
From: Sean Olson 
Organization: EUS/SI/PA
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: diyanat 
Cc: sip@lists.bell-labs.com
Subject: Re: [SIP] IM Questions
References: <39C6004B.A98EA22D@hotfoon.com> <39C63349.15A168C2@ericsson.com> <39C7047B.1880C9D6@hotfoon.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-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

Interesting ideas. Comments inline

diyanat wrote:

> 
> First Issue:
> A group chat may or may not use a centralised server.
> IF we use a centralised server
>         the bandwidth requirements of the centralised server
>         will go up as the square of the number of users per group.
>         for ex: if there are three members in a group,
>                         each message is relayed twice.
>                 if there are fifty memebers in a group,
>                         each message is relyaed 50 times.

If you are speaking about text messages, the bandwidth is minimal.
This can be done in a stateless manner by the centralised server
and so involves no state information per message (there is 
registration state of course). 

> ELSE we use a peer to peer group chat
>        each member of the group has to be informed of any
>        new members joining or leaving the group. so that
>        the group list is synchronised by everyone.
>

There are clever ways to do this that don't involve notifying 
every single member but they are brittle.
 
> in our implementation, we did the following:
> 1. new group starts it's life as a 1-1 chat between two users. this
> essentially consists of MESSAGE requests flying back and forth with the
> same Call-ID but different CSeq for each message.
> 2. a new user is INVITEd to join the group by sending (hold your
> breath!) and INVITE message with SDP specifying SIP/2.0/UDP MESSAGE as
> the media description. multiple a=participant=userid specify the other
> participants in the list.
> 3. upon receiving an INVITE, the called user reacts just like a normal
> SIP response and awaits an ACK from the caller.
> 4. Once the MESSAGE session is established, the called user sends a
> dummy MESSAGE with the group chat's Call-ID to update everyone's group
> list.
> 

Why not use the Call-ID of the INVITE and skip step 4. Other than
that, this is basically what I had in mind as well (except for the
media description :) 

> the advantages of this scheme are:
> 1. any member of the list can now choose between taking a text only or a
> text+voice chat. this is especially important if the UA can handle only
> one voice call while being able to handle multiple message sessions.
> 2. a user can maintain (and it does in our UA) the list of banned userid
> or refuse to receive messages from a particular user.

This can be done with a centralized server as well.

> 3. while sending a message to all the group members, if a 200 OK
> response doesnt arrive from a particular user, the user is removed from
> the group list if it is a final response. thus, a userid is removed from
> a list when a user returns with a 400+ final response.

I'm not sure I would take this approach. There are many 400+ responses
that might indicate just a transient error that might be recoverable
on subsequent MESSAGE requests, especially since the routing of the
MESSAGE might involve things like forking, DNS SRV lookups, etc.
A 600 class response would clearly indicate that the user should be
removed, but the other response codes I would look at individually.

> 4. as the scheme is completely peer-to-peer, the centralised chat server
> bandwidth is conserved and the users have to pay (nominally though, text
> is hardly bandwidth intensive) by bandwidth whenever they send a group
> message.

But the user ends up paying proportionally to the size of the group :(

> 6. this scheme will work well with the existing clients that understand
> only MESSAGE, INVITE. we are only adding a new session type.INVITE is
> interpreted the same way as before.

With a new media type and the understanding that the first MESSAGE
after the INVITE conveys the Call-ID for the chat session.
 
> Second Issue:
> the idea of a session-less messaging is great. It is essentially a page.
> an SMS for the Net. If the MESSAAGE receiver returns a reply back with
> the same Call-ID, then it is an ad-hoc session, else it was a page and
> sender can forget about the MESSAGE. am i right on this?

Exactly. 

> But are we moving towards IM domination or are we adding minimal IM for
> functionality? the approach in would be different for the two aims. If
> we are to provide a high class IM, then we cannot bifurcate the
> SUBSCRIBE, MESSAGE and REGISTER into separate and independent proposals.
> they all MUST be implemented and available together. 

Actually they all work quite well independently. MESSAGE does not
rely on SUBSCRIBE or REGISTER. REGSITER obviously does not depend
on MESSAGE or SUBSCRIBE. And SUBSCRIBE can be used for things far
beyond IM. They do work wonderfully together though.

> The solution has to
> be optimal in anycase. For instance, within a single SUBSCRIBE message,
> we should be able to subscribe to more than one presentities. 

You can do this with SUBSCRIBE. It all depends on your interpretation
of the Request-URI.

> Similarly,
> in MESSAGE we need to be able to CC to more than one people. we need to
> adding forking, we need to add message signing and we need to add store
> and forward deliveries (deliver me a message that coffee is ready in 5
> minutes).

I agree this is a shortcoming with MESSAGE. I would like to see
a Cc: and/or Also: header for this purpose. [this opens up all kinds
of problems though as the original cc draft demonstrated]
 
> Issue three:
> the main advantage of peer to peer messaging is that there are no
> servers to crash out and attack. a trivial Redirect UDP server handling
> REGISTER and MESSAGE is all that is required. 

You don't consider this a central server? Or do you intend to
implement this on one of the peers?

> this is architecturally a
> beautiful piece. the problem is that without a server, that you cannot
> add more services and functionality to a network unless the UAs are
> replaced. while in a server based messaging system, sky is the limit
> (rather, the complexity and bandwidth are the limitations).
> it would be best if you could leave out the decision of either of the
> two to the implementors and have a protocol that will work well in both
> cases. I think that MESSAGE is one such scheme. But SUBSCRIBE is not.

I don't understand your argument regarding SUBSCRIBE vs. MESSAGE.
[I'm making the bold assumption that you can send a NOTIFY without
a prior SUBSCRIBE; not in the current draft, but a useful mechanism]


> In
> a steamy undernet server, i cant imagine sending SUBSCRIBE to over
> hunderd users each time I join or leave a group.

Vs. sending your MESSAGE to a hundred users? 
 
> - farhan 

--
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  Tue Sep 19 11: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 LAA17672
	for ; Tue, 19 Sep 2000 11:32: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 0CB2E44367; Tue, 19 Sep 2000 10:27:25 -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 AFE78443F2
	for ; Tue, 19 Sep 2000 08:13:50 -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 JAA05513;
	Tue, 19 Sep 2000 09:13:42 -0400 (EDT)
Message-ID: <39C76686.62BB4A43@cs.columbia.edu>
Date: Tue, 19 Sep 2000 09:13:42 -0400
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: "Stefan Runeson (ECS)" 
Cc: "'sip@lists.bell-labs.com'" 
Subject: Re: [SIP] Call-ID in Two-party Call example
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-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

"Stefan Runeson (ECS)" wrote:
> 
> Hello,
> 
> In Chapter 16.3 of RFC2543bis there is an example of a two-party call. The INVITE message is transmitted with Call-ID: 662606876@kton.bell-tel.com. The first and second responses use the same Call-ID. From the third response, the Call-ID 3298420296@kton.bell-tel.com is used instead. Is this correct?
> 

Typo fixed; thanks for catching it.

-- 
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 Sep 19 11:36: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 LAA17755
	for ; Tue, 19 Sep 2000 11:36: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 89E3944376; Tue, 19 Sep 2000 10:27:29 -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 58808443F5
	for ; Tue, 19 Sep 2000 08:14:05 -0400 (EDT)
Received: from lists.bell-labs.com ([135.104.27.211]) by dirty; Tue Sep 19 09:12:21 EDT 2000
Received: by lists.bell-labs.com (Postfix)
	id B33E64437D; Tue, 19 Sep 2000 08:59:11 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from ukmail.uk.lucent.com (ukmail.uk.lucent.com [135.86.160.50])
	by lists.bell-labs.com (Postfix) with ESMTP id D0E5E44341
	for ; Tue, 19 Sep 2000 08:59:10 -0400 (EDT)
Received: from lucent.com (uk0006166d078.uk.lucent.com [135.86.166.78]) by ukmail.uk.lucent.com (8.8.8+Sun/EMS-1.5 sol2)
	id NAA25371; Tue, 19 Sep 2000 13:59:06 +0100 (BST)
Message-ID: <39C76388.93A9FBA9@lucent.com>
Date: Tue, 19 Sep 2000 14:00:56 +0100
From: Anna Simpson 
Organization: Lucent Technologies
X-Mailer: Mozilla 4.6 [en]C-CCK-MCD EMS-1.4  (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Gonzalo Camarillo 
Cc: "Adam B. Roach" , sip@lists.bell-labs.com,
        "Vijay K. Gurbani" 
Subject: Re: [SIP] Question concerning SIP/ISUP interworking
References: <200009181904.OAA00344@b04a24.exu.ericsson.se> <39C6FA5F.80F68450@lmf.ericsson.se>
Content-Type: multipart/alternative;
 boundary="------------382FB894B825CE30BEC32BD5"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com


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

All,

This is my understanding from your emails and the spec.

If a call is established, e.g. a 200 [OK] has been received in response to
the INVITE then a BYE message will be sent.
For a SIP to ISUP call the 200 [OK] is sent on receiving the CON or ANM
over ISUP.
For an ISUP to SIP call the 200 [OK] is received when the SIP node answers
the call and will be mapped to an ANM or CON, as appropriate.

For the calling or called party to now release a BYE would map to a REL(16)
and vice versa.

Adam stated once a call is set up all REL messages are mapped to a BYE.
If this is so then the BYE will need to contain information to distinguish between
different REL messages otherwise information can be lost. (however this is a seperate
issue).


If the call is still being setup then either a response is seen or a CANCEL.
(A BYE could be used but is not the preferred option).
e.g.
SIP to ISUP
calling tears down before called answers then a CANCEL is sent and mapped to
a REL 16.ref 6.1.9. in the spec.

If the call ends for another reason then a SIP response is sent.


If I have the above correct then I am back to the original question of why
map a REL 31 to a 404 response.
I have been searching through the ITU specs to try and find examples of
when a rel 31 is used, rather than just saying when another normal cause value
is inappropriate.
I found this example in Q.764, 2.2.4
If a call set-up fails and an in-band tone or announcement has to be returned to the
calling party from an exchange or called party, the exchange or user concerned
connects the in-band tone or announcement to the transmission path. If a time-out
occurs at the exchange providing the in-band tone or announcement, the exchange
sends a release message to the preceding exchange with cause value 31 (normal
unspecified).
To me this does not look like a 404 NOT FOUND.

However I am clueless as to which response would be more appropriate if we
cannot use a CANCEL or BYE.
During the definition of SIP was it ever considered that there should be catch
all responses, that would say mimic this ISUP catch all cause values?
Or is this something that is not needed by SIP.

Thanks for your thoughts so far, this discussion has been very beneficial to
my understanding of SIP.

Anna

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



All,

This is my understanding from your emails and the spec.

If a call is established, e.g. a 200 [OK] has been received in response
to

the INVITE then a BYE message will be sent.

For a SIP to ISUP call the 200 [OK] is sent on receiving the CON or
ANM

over ISUP.

For an ISUP to SIP call the 200 [OK] is received when the SIP node
answers

the call and will be mapped to an ANM or CON, as appropriate.

For the calling or called party to now release a BYE would map to a
REL(16)

and vice versa.

Adam stated once a call is set up all REL messages are mapped to a BYE.

If this is so then the BYE will need to contain information to distinguish
between

different REL messages otherwise information can be lost. (however
this is a seperate

issue).

 

If the call is still being setup then either a response is seen or a
CANCEL.

(A BYE could be used but is not the preferred option).

e.g.

SIP to ISUP

calling tears down before called answers then a CANCEL is sent and
mapped to

a REL 16.ref 6.1.9. in the spec.

If the call ends for another reason then a SIP response is sent.

 

If I have the above correct then I am back to the original question
of why

map a REL 31 to a 404 response.

I have been searching through the ITU specs to try and find examples
of

when a rel 31 is used, rather than just saying when another normal
cause value

is inappropriate.

I found this example in Q.764, 2.2.4

If a call set-up fails and an in-band tone or announcement has to
be returned to the

calling party from an exchange or called party, the exchange or
user concerned

connects the in-band tone or announcement to the transmission path.
If a time-out

occurs at the exchange providing the in-band tone or announcement,
the exchange

sends a release message to the preceding exchange with cause value
31 (normal

unspecified).

To me this does not look like a 404 NOT FOUND.

However I am clueless as to which response would be more appropriate
if we

cannot use a CANCEL or BYE.

During the definition of SIP was it ever considered that there should
be catch

all responses, that would say mimic this ISUP catch all cause values?

Or is this something that is not needed by SIP.

Thanks for your thoughts so far, this discussion has been very beneficial
to

my understanding of SIP.

Anna

--------------382FB894B825CE30BEC32BD5--




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


From sip-admin@lists.bell-labs.com  Tue Sep 19 12:35: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 MAA19549
	for ; Tue, 19 Sep 2000 12:35: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 84F784437B; Tue, 19 Sep 2000 11:35:09 -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 BD2A044346
	for ; Tue, 19 Sep 2000 11:35:02 -0400 (EDT)
Received: from zrchb200.us.nortel.com (actually zrchb200) 
          by smtprch2.nortel.com; Mon, 18 Sep 2000 19:31:13 -0500
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2652.35) 
          id ; Mon, 18 Sep 2000 19:35:01 -0500
Message-ID: <36FA02BD7083D411BC9E0000F8073E43A61A5E@crchy271.us.nortel.com>
From: "Brian Stucker" 
To: Howard Hart 
Cc: sip@lists.bell-labs.com
Subject: RE: [SIP] DNS SRV records in stateless mode
Date: Mon, 18 Sep 2000 19:34:51 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C021D1.6C8B8BE0"
X-Orig: 
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com

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_01C021D1.6C8B8BE0
Content-Type: text/plain;
	charset="ISO-8859-1"

I don't understand how would it seriously impact load balancing? That's what
the specification tells you to do for SRV, I think =).
 
If you try an entry, and it fails due to timeout, then you go to the next
guy on the list. Maybe I'm just not reading this correctly, or I just don't
understand your position correctly...
 
RFC-2782:
        To select a target to be contacted next, arrange all SRV RRs
        (that have not been ordered yet) in any order, except that all
        those with weight 0 are placed at the beginning of the list.
 
        Compute the sum of the weights of those RRs, and with each RR
        associate the running sum in the selected order. Then choose a
        uniform random number between 0 and the sum computed
        (inclusive), and select the RR whose running sum value is the
        first in the selected order which is greater than or equal to
        the random number selected. The target host specified in the
        selected SRV RR is the next one to be contacted by the client.
        Remove this SRV RR from the set of the unordered SRV RRs and
        apply the described algorithm to the unordered SRV RRs to select
        the next target host.  Continue the ordering process until there
        are no unordered SRV RRs.  This process is repeated for each
        Priority.
 
I read that to mean that you should go through the records in a particular
order if one times out, go to the next one that you've prioritized and
weighted to be next. Otherwise, if you weren't supposed to go through the
list on error scenarios, why apply the algorithm more than once? Pick your
one, be done with it. If that's the case, then why have different
priorities, because only those servers in the topmost priority would be
picked?
 
Since you don't want subsequent INVITES to get routed to a server you know
is bad, and since the logic for the stateless proxy is to treat all INVITES
(retransmitted or otherwise) to be one SRV transaction because we want to
"rig" the randomization process (which in itself would impact load balancing
at the SRV level, but not on the SIP perspective) so it picks the same guy
every time for all retransmittions. Therefore, it would make sense not to
try an IP that you just had a timeout on. Move on, go to the next record.
Next time you get a completely new session, it's a whole new ball-game. You
start all over expecting that all of the servers returned (even though you
just tried them for a different session, and may have found some that were
bad) are potentially ok to use again.
 
I would consider that an improvement on load balancing, especially given the
impact that the rigging for SIP is going to have (which will probably work
out to a big net gain in load savings at the end of the day).
 
Brian Stucker
Nortel Networks

-----Original Message-----
From: Howard Hart [mailto:hch@ipdialog.com]
Sent: Monday, September 18, 2000 6:08 PM
To: Stucker, Brian [RICH2:WI12:EXCH]
Subject: Re: [SIP] DNS SRV records in stateless mode


Brian Stucker wrote: 

  

There's ways around this for stateful proxies, but a stateless proxy can't
employ the same methods with your selection method. UNLESS you also
stipulate that you should remove an entry from the list of selectable SRV
entries left in the list once they're excluded due to a timeout, or whatever
other event the proxy implementor deems appropriate. 
 

Probably don't want to do that since it could seriously impact load
balancing. 

Howard Hart 
ipDialog, Inc. 


------_=_NextPart_001_01C021D1.6C8B8BE0
Content-Type: text/html;
	charset="ISO-8859-1"









I 
don't understand how would it seriously impact load balancing? That's what the 
specification tells you to do for SRV, I think =).


 


If you 
try an entry, and it fails due to timeout, then you go to the next guy on the 
list. Maybe I'm just not reading this correctly, or I just don't understand your 
position correctly...


 


RFC-2782:


        To select a 
target to be contacted next, arrange all SRV 
RRs
        (that have not been ordered 
yet) in any order, except that all
        
those with weight 0 are placed at the beginning of the list.


 


        Compute the 
sum of the weights of those RRs, and with each 
RR
        associate the running sum in 
the selected order. Then choose a
        
uniform random number between 0 and the sum 
computed
        (inclusive), and select 
the RR whose running sum value is 
the
        first in the selected order 
which is greater than or equal to
        
the random number selected. The target host specified in 
the
        selected SRV RR is the next 
one to be contacted by the client.
        
Remove this SRV RR from the set of the unordered SRV RRs 
and
        apply the described algorithm 
to the unordered SRV RRs to select
        
the next target host.  Continue the ordering process until 
there
        are no unordered SRV 
RRs.  This process is repeated for 
each
        Priority.


 


I read 
that to mean that you should go through the records in a particular order if one 
times out, go to the next one that you've prioritized and weighted to be next. 
Otherwise, if you weren't supposed to go through the list on error scenarios, 
why apply the algorithm more than once? Pick your one, be done with it. If 
that's the case, then why have different priorities, because only those servers 
in the topmost priority would be picked?


 


Since 
you don't want subsequent INVITES to get routed to a server you know is bad, and 
since the logic for the stateless proxy is to treat all INVITES (retransmitted 
or otherwise) to be one SRV transaction because we want to "rig" the 
randomization process (which in itself would impact load balancing at the SRV 
level, but not on the SIP perspective) so it picks the same guy every time for 
all retransmittions. Therefore, it would make sense not to try an IP that you 
just had a timeout on. Move on, go to the next record. Next time you get a 
completely new session, it's a whole new ball-game. You start all over expecting 
that all of the servers returned (even though you just tried them for a 
different session, and may have found some that were bad) are potentially ok to 
use again.


 


I 
would consider that an improvement on load balancing, especially given the 
impact that the rigging for SIP is going to have (which will probably work out 
to a big net gain in load savings at the end of the day).


 


Brian 
Stucker


Nortel 
Networks



  
-----Original Message-----
From: Howard Hart 
  [mailto:hch@ipdialog.com]
Sent: Monday, September 18, 2000 6:08 
  PM
To: Stucker, Brian [RICH2:WI12:EXCH]
Subject: Re: [SIP] 
  DNS SRV records in stateless mode

Brian Stucker wrote: 
  
  
    
There's ways around this for stateful proxies, but a 
    stateless proxy can't employ the same methods with your selection method. 
    UNLESS you also stipulate that you should remove an entry from the list of 
    selectable SRV entries left in the list once they're excluded due to a 
    timeout, or whatever other event the proxy implementor deems 
    appropriate. 
 
Probably don't want to do that 
  since it could seriously impact load balancing. 
  
Howard Hart 
ipDialog, Inc. 


------_=_NextPart_001_01C021D1.6C8B8BE0--


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


From sip-admin@lists.bell-labs.com  Tue Sep 19 12:42: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 MAA19773
	for ; Tue, 19 Sep 2000 12:42: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 C7BAE44369; Tue, 19 Sep 2000 11:42:49 -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 78BCC44361
	for ; Tue, 19 Sep 2000 11:42:46 -0400 (EDT)
Received: from driftwood.cisco.com (driftwood.cisco.com [171.71.157.40])
	by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id JAA03035;
	Tue, 19 Sep 2000 09:42:38 -0700 (PDT)
Received: from cisco.com ([171.71.159.231])
	by driftwood.cisco.com (Mirapoint)
	with ESMTP id ACI07883;
	Tue, 19 Sep 2000 11:42:36 -0500 (CDT)
Message-ID: <39C797BE.9D7FC1D6@cisco.com>
Date: Tue, 19 Sep 2000 11:43:42 -0500
From: Hong Chen 
Organization: Cisco Systems
X-Mailer: Mozilla 4.5 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg 
Cc: "'rajeev@empowertel.com'" ,
        "'Anders Kristensen'" ,
        "'sip@lists.bell-labs.com'" 
Subject: Re: [SIP] SIP feature services
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-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit



Jonathan Rosenberg wrote:

> > -----Original Message-----
> > From: Hong Chen [mailto:hjlechen@cisco.com]
> > Sent: Monday, September 18, 2000 5:22 PM
> > To: Jonathan Rosenberg
> > Cc: 'rajeev@empowertel.com'; 'Anders Kristensen';
> > 'sip@lists.bell-labs.com'
> > Subject: Re: [SIP] SIP feature services
> >
> >
> >
> >
> > Jonathan Rosenberg wrote:
> >
> > > This question only makes sense in the context of directly
> > applying the
> > > IN model for SIP applications. I think SIP and its
> > operation is sufficiently
> > > different that this really doesn't make sense.
> > >
> > > In the SIP model, the AS is simply another SIP entity. This
> > means that it
> > > gets
> > > the initial INVITE, along with any other signaling in the
> > call (if it
> > > record-routes).
> >
> > Exact issue here, since the AS SIP address should be set in
> > the SIP URI of
> > initial INVITE.
> > Questions raised here are:
> > who(UAC or SIP proxy) should set the AS SIP URI in INVITE
> > request ? and
> > How to find the SIP address for an AS serving the feature?
>
> First off, its not strictly necessary to actually set the request URI to
> have a host part that points to the AS. A proxy or UA can send a request
> with any request URI to the AS, and then it would perform its feature
> processing. This is analagous in http where you can send a request to an
> http proxy even though the request URI points to some other host.
>
> In fact, modifying the request URI is probably bad, since it likely contains
> some useful information for feature processing.
>
> As to whom should send a request to the AS - that depends on the
> architecture of your network. How to find its address is a hard problem.
> Right now, static configuration of rules and conditions is the only way.
> Ideally, I'd like to have some way for application servers to propagate
> information on their application invocation conditions to upstream proxies
> or UAs. This way, I need only drop an application into an AS, and it would
> take care of propagating the routing information so that it gets properly
> invoked.
>
> This kind of propagation is what I have referred to as "service routing". It
> can be viewed as a multi-dimensional routing problem. The reason its
> multi-dimensional is that the criteria for application invocation can be
> quite varied. Its not just "request URI = foo"; it can be based on the From
> field (for outgoing features, in general), To field, Request URI, and
> components there in. For example, a departmental outgoing call screening
> application might execute whenever a call with a From field domain of
> cs.columbia.edu is found.
>
> Service execution might also depend on a subscriber list. For example, a
> call forward no answer service might execute if the called party subscribes
> to the service. In this case, the criteria for application invocation
> depends on matching the user@host portion of the request URI against a
> potentially long list of subscribers.
>
> Not all of the criteria for service invocation need be propagated; perhaps
> only the general criteria are propagated, and then the specifics are
> verified at the AS itself. In fact, the verification might itself be part of
> the application. For example, lets say columbia.edu has an call forward
> service enabled for certain students in its CS department, depending on
> their GPA (above 3.5, and they get the service). In this case, the
> application might propagate the rule "INVITE request with request URI domain
> cs.columbia.edu will trigger execution of CFNA at AS 3.4.5.6 port 5060".
> When the call arrives at the AS, it will need to run and check the GPA of
> the called party against the university database. If their GPA is too low,
> the call is simply proxied without doing anything special.

Thanks for response in such details!

First, I would like to generalize service routing criteria here and bring up
issue with it:
        Service routing criteria are combination of
        (1) SIP message contents.
            - Method of Request.
            - Request URI.
            - SIP message headers (especially TO, FROM and STATE headers).
        (2) Subscriber's profiles.
        (3) Time and / or date of the request.
        (4) Address of proxy or UA processing the request.
        (5) ...

        Issue: If there are more than one ASes satisfying the above combined
service routing criteria,
                  which AS should  be selected by the proxy or the UA to route
the request to?

        We may have several different solutions and please let me know which is
the proper SIP mechanism.
        (1)  SIP mechanism.
              Use "url-parameters" of SIP URL in the request URI to solve the
unique service routing problem and
              use "STATE" header to pass end point call state. Like:

                    INVITE sip:Bob@calleeHost.com;service=feature-i SIP/2.0
                    Via: SIP/2.0/UDP callerHost.com:5060
                    From: Alice
                    To: Bob
                    State:callerHost;state=initialCall

                Is it a proper SIP mechanism? If not, please explain why.

        (2) AS interactions.
              AS will interact to each other to solve the unique service
problem.
              We need to find a proper protocol for the purpose.

        (3) Do not need to do it at all!

Second, I like the idea of dynamic "service routing". But what protocol in your
mind could help us to do so, SIP or others?
              Plus we need to solve the conflicting problems introduced by more
than one ASes propagating
              conflict service routing criteria.


>
>
> -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 Sep 19 15: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 PAA22913
	for ; Tue, 19 Sep 2000 15:07: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 D4F4E4434C; Tue, 19 Sep 2000 14:06:58 -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 236C044346
	for ; Tue, 19 Sep 2000 13:38:09 -0400 (EDT)
Received: from vovida.com ([209.237.8.113]) by pigeon.vovida.com
          (Netscape Messaging Server 4.15) with ESMTP id G15CW200.PTD for
          ; Tue, 19 Sep 2000 11:33:38 -0700 
Message-ID: <39C7B28F.EA942A3@vovida.com>
Date: Tue, 19 Sep 2000 11:38:08 -0700
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="------------028454C0ABC89B9B33E7A267"
Subject: [SIP] clarification o 302 message content.
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com


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

 In the August 6th, draft ( draft-ietf-sip-rfc2543bis-01.ps),
pg 64 , section 7.3.3 states that UACs may add a branch to the new
request, keeping the Cseq, to, from, call-id the same.
Now, isnt adding the branch a significance of forking?, which apparently
only the proxies perform.

Also, the text does not specify bumbing up the CSeq and maintaining all
other fields the same for a re-INVITE.

However, the example on page 108, the CSeq has been bumped up, with no
branch added. This is inconsistant..

Can someone clarify this please.
thanks

--
Sunitha Kumar
http://www.vovida.com



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



 In the August 6th, draft ( draft-ietf-sip-rfc2543bis-01.ps),

pg 64 , section 7.3.3 states that UACs may add a branch to the new
request, keeping the Cseq, to, from, call-id the same.

Now, isnt adding the branch a significance of forking?, which apparently
only the proxies perform.

Also, the text does not specify bumbing up the CSeq and maintaining
all other fields the same for a re-INVITE.

However, the example on page 108, the CSeq has been bumped up, with
no branch added. This is inconsistant..

Can someone clarify this please.

thanks

-- 
Sunitha Kumar
http://www.vovida.com

 

--------------028454C0ABC89B9B33E7A267--




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


From sip-admin@lists.bell-labs.com  Tue Sep 19 16: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 QAA24704
	for ; Tue, 19 Sep 2000 16: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 3AB374434C; Tue, 19 Sep 2000 15:40:50 -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 7808044348
	for ; Tue, 19 Sep 2000 14:54:01 -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 MAA21830;
	Tue, 19 Sep 2000 12:54:25 -0700
Message-ID: <39C7C471.44E0D315@mobilerain.com>
Date: Tue, 19 Sep 2000 12:54:25 -0700
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: Jonathan Rosenberg 
Cc: "'sip@lists.bell-labs.com'" 
Subject: Re: [SIP] IM Questions
References: 
Content-Type: multipart/mixed;
 boundary="------------C1019CE014B4DD521A281AFE"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com

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

Jonathan:

Thanks for the answers. However, I have some more questions regarding the
centralized server:

a. Can a centralized server INVITE buddies on its own? e.g., if a centralized
server is managing a buddy list -- 3 users and recognizes that the 3rd one just
became "on" and wants to INVITE it to the session. In this case how is the CSeq
value propagated?

The reason I ask this is because from the draft:

Each IM also carries a CSeq, which is a sequence number plus the name of the
method of the request. The CSeq uniquely identifies each IM in the session.

Consider the following scenario (3 users - A, B, & C)

a. A sends MESSAGE to a centralized server for propagation to B - CSeq 1
b. A and B are communicating with monotonically increasing CSeq numbers.
c. When C gets invited by the centralized server, if the above mentioned
criteria is good, what should be the CSeq value in INVITE and how is it
syncrhonized between A, B, C for the same conference.

Obviously, there are various hacks to do this but was wondering if there is a
built-in mechanism I may have overlooked.

Regards,

Bobby.Sardana@mobilerain.com

Jonathan Rosenberg wrote:

> > -----Original Message-----
> > From: sip-admin@lists.bell-labs.com
> > [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Bobby Sardana
> > Sent: Tuesday, September 05, 2000 5:29 PM
> > To: sip@lists.bell-labs.com
> > Subject: [SIP] IM Questions
> >
> >
> > Greetings:
> >
> > I have been reading the draft
> > [draft-rosenberg-impp-im-00.txt] and have
> > the following questions:
> >
> > a. In section 4.1 Message flow, the message F4 has two "Via"
> > headers. Is
> > this an error since the proxy should have popped the topmost "Via"?
>
> Yes, it is an error.
>
> > b. The draft does not outline support for multiple users
> > (2+). How will
> > the communication happen? What will be the message flow?
>
> There are several models. One is the "reflector" approach; I can send an IM
> to sip:mybuddies@lists.com, and this would result in an IM being sent to
> each of the members of that group. Much like a centralized conference server
> in SIP. In fact, it works very well with that model.
>
> The other approach is a fully distributed conference, where I would send an
> IM to each of the other participants. Much like the fully distributed
> multiparty conference for voice.
>
> > c. How are dynamic users added to a buddy list? Can a REGISTER message
> > be generated to perform the dynamic addition?
>
> Yes, that is one way. It can also be done administratively from a web page
> or something.
>
> -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

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

--------------C1019CE014B4DD521A281AFE--




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


From sip-admin@lists.bell-labs.com  Tue Sep 19 19:27: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 TAA26373
	for ; Tue, 19 Sep 2000 19:27: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 6F15244359; Tue, 19 Sep 2000 18:27:19 -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 6D48A4434C
	for ; Tue, 19 Sep 2000 18:27:16 -0400 (EDT)
Received: from tate ([216.181.56.35]) by broadsoft.com (8.8.8) id TAA54715; Tue, 19 Sep 2000 19:27:13 -0400 (EDT)
Message-ID: <029e01c02291$40020390$3202a8c0@broadsoft.com>
From: "Brett Tate" 
To: "SIPbell-labs" 
Date: Tue, 19 Sep 2000 19:28:00 -0400
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_029B_01C0226F.B8B4E130"
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] draft-ietf-sip-mib-01: Why no response counters per method?
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com

This is a multi-part message in MIME format.

------=_NextPart_000_029B_01C0226F.B8B4E130
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Draft-ietf-sip-mib-01 (July 2000) does not define
a common object for obtaining response=20
counters based upon a SIP Method.

I was wondering which of the following was true:
1) I'm not reading the draft correctly.
2) It was deemed "not important enough" and
    excluded as part of a counter reduction process.=20
3) It was over looked, and may need to be added.

I assume that number 2 is the answer, but I just
wanted to make sure.

Thanks in advance for the response. =20

------=_NextPart_000_029B_01C0226F.B8B4E130
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable









Draft-ietf-sip-mib-01 (July 2000) does not =
define


a common object for obtaining response 


counters based upon a SIP Method.


 


I was wondering which of the following was =
true:


1) I'm not reading the draft=20
correctly.


2) It was deemed "not important enough" =
and


    excluded as part of a =
counter=20
reduction process. 


3) It was over looked, and may need to be =
added.


 


I assume that number 2 is the answer, but I =
just


wanted to make sure.


 


Thanks in advance for the response.  


------=_NextPart_000_029B_01C0226F.B8B4E130--



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


From sip-admin@lists.bell-labs.com  Tue Sep 19 21:15: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 VAA27430
	for ; Tue, 19 Sep 2000 21:15: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 DFD8044361; Tue, 19 Sep 2000 20:15:54 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from md3.vsnl.net.in (md3.vsnl.net.in [202.54.6.35])
	by lists.bell-labs.com (Postfix) with ESMTP id 358B84434C
	for ; Tue, 19 Sep 2000 20:15:49 -0400 (EDT)
Received: from jana ([203.197.131.45])
	by md3.vsnl.net.in (8.9.3/8.9.3) with SMTP id GAA29706;
	Wed, 20 Sep 2000 06:39:48 +0530 (IST)
Message-ID: <007f01c0229f$ffa4aaa0$38c9a8c0@labs>
From: "Pathangi N Janardhanan" 
To: "Francois-Xavier Guitton" ,
        "SIP" 
References: <39C723FA.D5C30BA9@ms.alcatel.fr>
Subject: Re: [SIP] Modify media during a call
Date: Wed, 20 Sep 2000 06:43:32 +0530
Organization: HCL Technologies India Ltd.
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_007C_01C022CE.183F8FC0"
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
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com

This is a multi-part message in MIME format.

------=_NextPart_000_007C_01C022CE.183F8FC0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,


All,
Just a quick question: Is it possible to modify a media codec type =
during a call thanks
 to a second INVITE ? ( I can not find in the spec RFC 2543 where that =
case is described)
Please see section B.5
e.g.: A INVITE B with media m=3Daudio 49170 RTP/AVP 0 , and the call is =
successfully established.
May A re-INVITE B in replacing the media line by m=3Daudio 49170 RTP/AVP =
2 (to replace PCMU by G721) ?

I guess the re-invite should look like:
m=3Daudio 0 RTP/AVP 0
m=3Daudio 49170 RTP/AVP 2

 The first line for deleting the original media stream selected
and the second line for adding the new one.

Jana


------=_NextPart_000_007C_01C022CE.183F8FC0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable









Hi,


  

All,
Just a quick question: Is it =
possible to modify a media codec type during a call thanks
 to =
a second INVITE ? ( I can not find in the spec RFC 2543 where =
that case is described)
Please see section B.5
e.g.: =
A INVITE B with media m=3Daudio 49170 RTP/AVP 0 , and =
the call is successfully established.
May A re-INVITE B in =
replacing the media line by m=3Daudio 49170 RTP/AVP 2 (to =
replace PCMU by G721) ?
I guess the re-invite =
should look like:
m=3Daudio 0 RTP/AVP 0
m=3Daudio =
49170 RTP/AVP 2
 
 The first line for deleting =
the original media stream selected
and the second line for =
adding the new =
one.
 
Jana


------=_NextPart_000_007C_01C022CE.183F8FC0--



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


From sip-admin@lists.bell-labs.com  Tue Sep 19 21:47: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 VAA28968
	for ; Tue, 19 Sep 2000 21:47: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 8514B4436C; Tue, 19 Sep 2000 20:47:23 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from md3.vsnl.net.in (md3.vsnl.net.in [202.54.6.35])
	by lists.bell-labs.com (Postfix) with ESMTP id 1DC494434C
	for ; Tue, 19 Sep 2000 20:47:17 -0400 (EDT)
Received: from jana ([203.197.131.45])
	by md3.vsnl.net.in (8.9.3/8.9.3) with SMTP id HAA08566;
	Wed, 20 Sep 2000 07:11:39 +0530 (IST)
Message-ID: <008a01c022a4$727931a0$38c9a8c0@labs>
From: "Pathangi N Janardhanan" 
To: "Aseem Agarwal" , "sip" 
References: <8BBD33A986C5D311804000902719FF5DC09A9E@aega.trillium.com>
Subject: Re: [SIP] Overlap dialing in SIP
Date: Wed, 20 Sep 2000 07:15:23 +0530
Organization: HCL Technologies India Ltd.
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

Hi Aseem,


> I need some clarification about overlap dialing in SIP as referred
in
> Section 4.2.1
>
> "A UAC MUST NOT issue another INVITE request for the same call leg
> before the previous transaction has completed"
>
> "A UAS acting as a gateway ..."
>
> The above two references are confusing. If a UAC can not initiate
> a reINVITE before receiving a definite response, how does a UAS at a
> GW get additional digits ? A Gateway can get additional digits once
> the call is established (may be for supplementary services)but not
> in call set up phase. Is this correct ?

 Please see draft-camarillo-sip-isup-bcp-00.txt for a detailed
call flow scenario of overlap dialing in SIP-ISUP mapping.

>
> Another source of confusion :
>
> "If the UAC wishes to modify the session after the call set up has
> begun, it MUST use another INVITE request"
>
> Can a UA after sending an INVITE, send another INVITE for modifying
the
> session parameters before getting a definite response ( in call set
up
> phase itself) ?

 A re-invite for the same call leg can be sent only after the first
INVITE
has got a definite response.

Jana




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


From sip-admin@lists.bell-labs.com  Tue Sep 19 22:09: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 WAA29184
	for ; Tue, 19 Sep 2000 22:09: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 083CB44376; Tue, 19 Sep 2000 21:09:34 -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 AEA564434C
	for ; Tue, 19 Sep 2000 21:09:31 -0400 (EDT)
Received: by div8.net
	via sendmail from stdin
	id  (Debian Smail3.2.0.102)
	for sip@lists.bell-labs.com; Tue, 19 Sep 2000 21:09:28 -0500 (CDT) 
Date: Tue, 19 Sep 2000 21:09:28 -0500
From: Billy Biggs 
To: sip@lists.bell-labs.com
Message-ID: <20000919210928.A14958@div8.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0.1i
Subject: [SIP] Methods in Allow header
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com

  Hi,

  Does a user agent need to include the ACK and CANCEL methods in an
Allow header?

  If INVITE is included, must BYE be included as well?  It seems like a
minimal SIP implementation which supports INVITE can get away with not
being able to generate BYEs, but wouldn't it still need to be able to
accept them?

-- 
Billy Biggs                         vektor@div8.net
http://www.div8.net/billy/      wbiggs@uwaterloo.ca


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


From sip-admin@lists.bell-labs.com  Tue Sep 19 23:22: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 XAA00807
	for ; Tue, 19 Sep 2000 23:22: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 32CA244376; Tue, 19 Sep 2000 22:21:37 -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 32AAD4434C
	for ; Tue, 19 Sep 2000 22: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 XAA22181;
	Tue, 19 Sep 2000 23:23:07 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id ; Tue, 19 Sep 2000 23:18:04 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'Billy Biggs'" ,
        "'sip@lists.bell-labs.com'" 
Subject: RE: [SIP] Methods in Allow header
Date: Tue, 19 Sep 2000 23:18:01 -0400
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-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com




> -----Original Message-----
> From: Billy Biggs [mailto:vektor@div8.net]
> Sent: Tuesday, September 19, 2000 10:09 PM
> To: sip@lists.bell-labs.com
> Subject: [SIP] Methods in Allow header
> 
> 
>   Hi,
> 
>   Does a user agent need to include the ACK and CANCEL methods in an
> Allow header?
> 
>   If INVITE is included, must BYE be included as well?  It 
> seems like a
> minimal SIP implementation which supports INVITE can get away with not
> being able to generate BYEs, but wouldn't it still need to be able to
> accept them?

It really doesn't make a big difference. But, for simplicities sake,
consistency is a good thing. In that case, you should do what the spec says
- list the methods supported by the server. That means ACK, CANCEL, as well
as BYE.

-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 Sep 19 23:24: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 XAA00819
	for ; Tue, 19 Sep 2000 23:24: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 197804438D; Tue, 19 Sep 2000 22:24:26 -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 0675144387
	for ; Tue, 19 Sep 2000 22:24: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 XAA22198;
	Tue, 19 Sep 2000 23:26:17 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id ; Tue, 19 Sep 2000 23:21:14 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'Francois-Xavier Guitton'" ,
        "'SIP'" 
Subject: RE: [SIP] Modify media during a call
Date: Tue, 19 Sep 2000 23:21:10 -0400
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-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com



-----Original Message-----
>From: Francois-Xavier Guitton
[mailto:francois-xavier.guitton@ms.alcatel.fr]
>Sent: Tuesday, September 19, 2000 4:30 AM
>To: SIP
>Subject: [SIP] Modify media during a call
>
>
>All,
>Just a quick question: Is it possible to modify a media codec type during a
call thanks to 
>a second INVITE ? ( I can not find in the spec RFC 2543 where that case is
described)
>e.g.: A INVITE B with media m=audio 49170 RTP/AVP 0 , and the call is
successfully >
established.
>May A re-INVITE B in replacing the media line by m=audio 49170 RTP/AVP 2
(to replace PCMU 
>by G721) ?
>
>Fx./.

Yes, I believe that is fine. On re-invite, you can update a media stream by
doing any of the following:

1. change the IP address or port
2. change the list of codecs
3. change any parameters in a lines

The only thing you probably should not do is change the type of the media
itself, that is, change from audio to video. Thats really adding a new media
stream.

-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 Sep 19 23:54: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 XAA01447
	for ; Tue, 19 Sep 2000 23:54: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 A75A644386; Tue, 19 Sep 2000 22:54:13 -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 078464434C
	for ; Tue, 19 Sep 2000 22:54:08 -0400 (EDT)
Received: from bigboy ([203.197.20.32])
	by hd2.dot.net.in (8.8.8/8.8.8) with SMTP id JAA11104
	for ; Wed, 20 Sep 2000 09:20:03 +0530 (IST)
Message-ID: <000001c022b6$bae165e0$2014c5cb@bigboy>
Reply-To: "farhan" 
From: "farhan" 
To: "sip" 
Subject: Re: [SIP] IM Questions
Date: Tue, 19 Sep 2000 23:44:39 +0530
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

my apologies for sending the last two mails from a colleagues email id. the
messages sent from diyanat's email id were mine.

back to u sean ...

>>                         each message is relayed twice.
>>                 if there are fifty memebers in a group,
>>                         each message is relyaed 50 times.
>
>If you are speaking about text messages, the bandwidth is minimal.
>This can be done in a stateless manner by the centralised server
>and so involves no state information per message (there is
>registration state of course).

if the server is stateless, then the error recovery is again the job of
MESSAGE orginator. this leads to an unelegent situation where the central
server is aware of group memberships and hence the state of a group but
refuses to deliver MESSAGEs. the state is now split between the sender and
the centralised server.
I guess that such a situation can lead to fragile states. a state ought to
be completely maintain at one node. Let me give u an example:
a sender has a list of five group members while the central server has six
in its list. now when the sender sends one copy to the server, the server
replicates this to the six members. as the server doesn't maintain the
state, it promptly forgets about the message and relays back responses from
six group members. the sender realises that the sixth new member of the list
is a sworn enemy of his and should never have received the message. however,
the group server didnt know nor did the sender know about this.

>> in our implementation, we did the following:
>> 1. new group starts it's life as a 1-1 chat between two users. this
>> essentially consists of MESSAGE requests flying back and forth with the
>> same Call-ID but different CSeq for each message.
>> 2. a new user is INVITEd to join the group by sending (hold your
>> breath!) and INVITE message with SDP specifying SIP/2.0/UDP MESSAGE as
>> the media description. multiple a=participant=userid specify the other
>> participants in the list.
>> 3. upon receiving an INVITE, the called user reacts just like a normal
>> SIP response and awaits an ACK from the caller.
>> 4. Once the MESSAGE session is established, the called user sends a
>> dummy MESSAGE with the group chat's Call-ID to update everyone's group
>> list.
>>
>
>Why not use the Call-ID of the INVITE and skip step 4. Other than
>that, this is basically what I had in mind as well (except for the
>media description :)


If A, B and C were a group and A INVITED D. then B and C should know that D
has joined (to put D on their group lists). Therefore, it is D who should
signal this to B and C. Using the Call-ID of the INIVTE, D now sends a dummy
message to B and C and gets onto their group lists.
I havent understood how I can skip this step. This step is as kludgy as it
gets and I would rather not do this at all.

>> the advantages of this scheme are:
>> 1. any member of the list can now choose between taking a text only or a
>> text+voice chat. this is especially important if the UA can handle only
>> one voice call while being able to handle multiple message sessions.
>> 2. a user can maintain (and it does in our UA) the list of banned userid
>> or refuse to receive messages from a particular user.
>
>This can be done with a centralized server as well.

The advantage of doing this with a central server is that a user could login
from anywhere and retrieve her original friends list (note that I didnt use
the patente word 'buddy'). I have tried to keep away from stout servers and
put more intelligence on the peers. This is the guiding principle enunciated
by Henning.

>> 3. while sending a message to all the group members, if a 200 OK
>> response doesnt arrive from a particular user, the user is removed from
>> the group list if it is a final response. thus, a userid is removed from
>> a list when a user returns with a 400+ final response.
>
>I'm not sure I would take this approach. There are many 400+ responses
>that might indicate just a transient error that might be recoverable
>on subsequent MESSAGE requests, especially since the routing of the
>MESSAGE might involve things like forking, DNS SRV lookups, etc.
>A 600 class response would clearly indicate that the user should be
>removed, but the other response codes I would look at individually.


Absolutely. you are right.

>> 4. as the scheme is completely peer-to-peer, the centralised chat server
>> bandwidth is conserved and the users have to pay (nominally though, text
>> is hardly bandwidth intensive) by bandwidth whenever they send a group
>> message.
>
>But the user ends up paying proportionally to the size of the group :(

Which is poetic justice of sorts. groups are usually about 5-4 each. bigger
groups are just a headache for everyone and usually a person ends up
chatting with just a couple of others in a packed room.

>> 6. this scheme will work well with the existing clients that understand
>> only MESSAGE, INVITE. we are only adding a new session type.INVITE is
>> interpreted the same way as before.
>
>With a new media type and the understanding that the first MESSAGE
>after the INVITE conveys the Call-ID for the chat session.

The Call-ID specified in the INVITE is the same as the Call-ID of the
subsequent messages for that session.
btw, this scheme makes it possible to have more than one sessions with
another user. most of the current crop of messengers drop all the messages
from a user into a single window. this makes it impossible to have a session
of a different context between two specific users in a group.

>> But are we moving towards IM domination or are we adding minimal IM for
>> functionality? the approach in would be different for the two aims. If
>> we are to provide a high class IM, then we cannot bifurcate the
>> SUBSCRIBE, MESSAGE and REGISTER into separate and independent proposals.
>> they all MUST be implemented and available together.
>
>Actually they all work quite well independently. MESSAGE does not
>rely on SUBSCRIBE or REGISTER. REGSITER obviously does not depend
>on MESSAGE or SUBSCRIBE. And SUBSCRIBE can be used for things far
>beyond IM. They do work wonderfully together though.


hmmm  "SUBSCRIBE can be used for things far beyond IM" . can i subscribe to
being invited for a session whenever it is on? for instance, i want to know
be invited to the soccer commentary whenever the game starts.



>> the main advantage of peer to peer messaging is that there are no
>> servers to crash out and attack. a trivial Redirect UDP server handling
>> REGISTER and MESSAGE is all that is required.
>
>You don't consider this a central server? Or do you intend to
>implement this on one of the peers?


My redirect server is about 1000 lines of code. It handles SIP messages as
fast as they come in. UAs just get each other's Contact: and go away. Thus,
the server is not really required to sustain sessions. I would have loved to
be able to implement this on a peer. the problem however is, how do u (a
fresh user, just logged in from a dialip) contact the first peer of the
network?


>
>> this is architecturally a
>> beautiful piece. the problem is that without a server, that you cannot
>> add more services and functionality to a network unless the UAs are
>> replaced. while in a server based messaging system, sky is the limit
>> (rather, the complexity and bandwidth are the limitations).
>> it would be best if you could leave out the decision of either of the
>> two to the implementors and have a protocol that will work well in both
>> cases. I think that MESSAGE is one such scheme. But SUBSCRIBE is not.
>
>I don't understand your argument regarding SUBSCRIBE vs. MESSAGE.
>[I'm making the bold assumption that you can send a NOTIFY without
>a prior SUBSCRIBE; not in the current draft, but a useful mechanism]


I meant that MESSAGE work both peer to peer as well as through centralised
servers.
However, SUBSCRIBE requires a presence server to be present so that offline
userids can be subscribed to. Thus, presence requires a presence server.

>> In
>> a steamy undernet server, i cant imagine sending SUBSCRIBE to over
>> hunderd users each time I join or leave a group.
>
>Vs. sending your MESSAGE to a hundred users?


ouch! that is true. but  can't a server consolidate the list of all the
joins and leaves of the past few seoncds and send a update of the userlist
to all the group members? this area does require a more optimal solution.




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


From sip-admin@lists.bell-labs.com  Tue Sep 19 23: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 XAA01493
	for ; Tue, 19 Sep 2000 23: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 66CEE4439A; Tue, 19 Sep 2000 22:55:37 -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 BB3F644391
	for ; Tue, 19 Sep 2000 22:55:23 -0400 (EDT)
Received: from bigboy ([203.197.20.32])
	by hd2.dot.net.in (8.8.8/8.8.8) with SMTP id JAA30574;
	Wed, 20 Sep 2000 09:20:11 +0530 (IST)
Message-ID: <000101c022b6$bfe4a980$2014c5cb@bigboy>
Reply-To: "farhan" 
From: "farhan" 
To: "Bobby Sardana" ,
        "Jonathan Rosenberg" 
Cc: 
Subject: Re: [SIP] IM Questions
Date: Wed, 20 Sep 2000 07:18:25 +0530
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

>a. Can a centralized server INVITE buddies on its own? e.g., if a
centralized
>server is managing a buddy list -- 3 users and recognizes that the 3rd one
just
>became "on" and wants to INVITE it to the session. In this case how is the
CSeq
>value propagated?


CSeq value is unique to a combination of Call-ID, To and From. Therefore,
the CSeq doesnt have to be unique among all the messages between all the
buddies and the centralised server.
For instance, if a UA always starts with sequnce 1, there is no problem if
the responding UA too starts a message in the opposite direction.
CSeq is used to differentiate between two separate messages within the same
Call-ID between two sip urls (To: and From:).

>Each IM also carries a CSeq, which is a sequence number plus the name of
the
>method of the request. The CSeq uniquely identifies each IM in the session.
>
>Consider the following scenario (3 users - A, B, & C)
>
>a. A sends MESSAGE to a centralized server for propagation to B - CSeq 1
>b. A and B are communicating with monotonically increasing CSeq numbers.
>c. When C gets invited by the centralized server, if the above mentioned
>criteria is good, what should be the CSeq value in INVITE and how is it
>syncrhonized between A, B, C for the same conference.


Cseq value can still be 1 for the invite to C. the Cseq values are between
the server and (lets say) A are in a different 'sequence space' from the
CSeq values between the server and C.
As agreed upon by sean in a mail of a few hours ago, it is the Call-ID that
remains unique in a session of IMs. the uniqueness of a message is derived
from the combination of Call-ID, CSeq, To: and From:. So, as long as a UA
keeps incrementing the CSeq of it's succesive outgoing  MESSAGEs, there is
no ambiguity at all.




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


From sip-admin@lists.bell-labs.com  Wed Sep 20 01: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 BAA07166
	for ; Wed, 20 Sep 2000 01: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 0C79944388; Wed, 20 Sep 2000 00:41: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 E0A374434C
	for ; Wed, 20 Sep 2000 00:41: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 BAA22399;
	Wed, 20 Sep 2000 01:43:18 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id ; Wed, 20 Sep 2000 01:38:15 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'Sunitha Kumar'" ,
        "'sip bell labs'" 
Subject: RE: [SIP] clarification o 302 message content.
Date: Wed, 20 Sep 2000 01:38:09 -0400
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-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com



-----Original Message-----
>From: Sunitha Kumar [mailto:skumar@vovida.com]
>Sent: Tuesday, September 19, 2000 2:38 PM
>To: sip bell labs
>Subject: [SIP] clarification o 302 message content.
>
>
> In the August 6th, draft ( draft-ietf-sip-rfc2543bis-01.ps), 
>pg 64 , section 7.3.3 states that UACs may add a branch to the new request,
keeping the 
>Cseq, to, from, call-id the same. 
>Now, isnt adding the branch a significance of forking?, which apparently
only the proxies 
>perform. 

To the outside world, a proxy and a UA look the same. I see no reason why
the act of recursion should be different for a UA and for a proxy. 

>Also, the text does not specify bumbing up the CSeq and maintaining all
other fields the 
>same for a re-INVITE. 

THis should be mentioned, since the CSeq is bumped in one case, and not in
the other.


>However, the example on page 108, the CSeq has been bumped up, with no
branch added. This 
>is inconsistant.. 

I suppose this is also allowed, but is not described in 7.3.3. To make
things simpler we should restrict the number of different ways to do this. I
suppose it should either be done like a proxy recursing (everything same,
new branch-ID), else a totally new call (new Call-ID).

-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  Wed Sep 20 08:13: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 IAA19906
	for ; Wed, 20 Sep 2000 08:13: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 EAC2C44339; Wed, 20 Sep 2000 07:12:52 -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 A247E4434C
	for ; Wed, 20 Sep 2000 04:13:25 -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 e8K9CV519294
	for ; Wed, 20 Sep 2000 12:12:32 +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 TBR2WNKN; Wed, 20 Sep 2000 12:12:31 +0300
Received: from kurma.research.nokia.com (IDENT:root@nokesa19371.europe.nokia.com [172.21.193.71])
	by loki.research.nokia.com (8.9.3/8.9.3) with ESMTP id MAA26166
	for ; Wed, 20 Sep 2000 12:12:28 +0300 (EETDST)
Received: (from ppessi@localhost)
	by kurma.research.nokia.com (8.9.3/8.9.3) id LAA11904;
	Wed, 20 Sep 2000 11:25:35 +0300
X-Authentication-Warning: kurma.research.nokia.com: ppessi set sender to Pekka.Pessi@nokia.com using -f
From: Pekka Pessi 
To: 
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
Date: 20 Sep 2000 11:25:27 +0300
In-Reply-To: Henning Schulzrinne's message of "Tue, 19 Sep 2000 09:13:42 -0400"
Message-ID: 
Lines: 53
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
Subject: [SIP] IPv6 addresses in SIP
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com

        Hello all,

        As you might know, textual represention of IPv6 addresses include
        non-token characters. The bis-0[012] spec uses common representation
        of IPv6 addresses (IPv6reference) both within SIP-URL and elsewhere.

        I believe that the original intent of RFC 2732 was to limit its
        notation only to URLs. Using square brackets elsewhere, like in Via
        or Warning headers is problematic as, e.g., the maddr and received
        parameters may now include non-token characters "[", "]", and ":".
        This contradicts the basic parsing rules found in Appendix C, is
        incompatible with RFC2543 and HTTP 1.1, and breaks existing
        implementations.

        In order to fully support IPv6 just allowing IPv6 addresses here and
        there is not enought, but an implementation should allow IPv6
        addresses in any parameter, including future extensions.

        I think SIP has three alternatives when supporting IPv6:

     1) use IPv6 addresses where colons are replaced with hyphens:

http-IPv6address = "-" http-hexpart ["-" IPv4address]
http-hexpart = http-hexseq | http-hexseq "--" http-hexseq | "--" http-hexseq
http-hexseq  = hex4 *("-" hex4)
       
        This is somewhat compatible with rfc2543 (like, http-IPv6address is
        a "token", but not a "host"). Downside (besides how ugly it looks)
        is that an implementation needs two special routines to handle IPv6
        addresses.

     2) when a IPv6 address is included as a parameter, it is quoted:

http-host    = hostname | IPv4address | DQUOTE "[" IPv6address "]" DQUOTE
via-maddr    = "maddr=" http-host
via-received = "received=" http-host

        Problem here is that the Via and Warning (not to mention Host from
        HTTP 1.1, or Call-ID from RFC 2543) that previously used "host"
        still need extra attention.

     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.

                                        Pekka Pessi



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


From sip-admin@lists.bell-labs.com  Wed Sep 20 08:29: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 IAA20386
	for ; Wed, 20 Sep 2000 08:29: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 756D34435F; Wed, 20 Sep 2000 07:29:34 -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 1F32944358
	for ; Wed, 20 Sep 2000 07:29:27 -0400 (EDT)
Received: from sampark.hss.hns.com (sampark.hss.hns.com [139.85.229.22])
	by mars.hss.co.in (8.10.0/8.10.0) with SMTP id e8KCTxC06232
	for ; Wed, 20 Sep 2000 18:00:09 +0530 (IST)
Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2  (651.2 6-10-1998))  id 65256960.0040445B ; Wed, 20 Sep 2000 17:11:57 +0530
X-Lotus-FromDomain: HSSBLR
From: pmurthy@hss.hns.com
To: sip@lists.bell-labs.com
Message-ID: <65256960.003FDDC5.00@sampark.hss.hns.com>
Date: Wed, 20 Sep 2000 17:07:35 +0530
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Subject: [SIP] A Clarification
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com




With reference to "http://www.cs.columbia.edu/~hgs/sip/notes.html", under
the Www-Authenticate and Authorization sub-heading, it has been mentioned
that the two headers could be Req & Response hdrs. But, in the SIP Grammar
link
http://www.cs.columbia.edu/~hgs/sip/syntax/draft-ietf-sip-rfc2543bis-01.htm
l, Authorization is included under "request-header" and Www-Authenticate
under "response-header" . Am I looking at the correct Grammar links ? Is
there a correction needed ?

Regards
Prashant




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


From sip-admin@lists.bell-labs.com  Wed Sep 20 08: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 IAA21101
	for ; Wed, 20 Sep 2000 08: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 34E014436C; Wed, 20 Sep 2000 07:49:33 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from md3.vsnl.net.in (md3.vsnl.net.in [202.54.6.35])
	by lists.bell-labs.com (Postfix) with ESMTP id 05BEC4435C
	for ; Wed, 20 Sep 2000 07:49:27 -0400 (EDT)
Received: from jana ([203.199.220.68])
	by md3.vsnl.net.in (8.9.3/8.9.3) with SMTP id SAA11057
	for ; Wed, 20 Sep 2000 18:13:52 +0530 (IST)
Message-ID: <031701c02300$f5823fe0$38c9a8c0@labs>
From: "Pathangi N Janardhanan" 
To: 
Date: Wed, 20 Sep 2000 18:17:35 +0530
Organization: HCL Technologies India Ltd.
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Subject: [SIP] question on receiving multiple invites
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

Hi,

  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?

Thanks
Jana




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


From sip-admin@lists.bell-labs.com  Wed Sep 20 09:15: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 JAA21884
	for ; Wed, 20 Sep 2000 09:14: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 1DB6F44376; Wed, 20 Sep 2000 08:14:41 -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 1F05244339
	for ; Wed, 20 Sep 2000 08:14:34 -0400 (EDT)
Received: from sampark.hss.hns.com (sampark.hss.hns.com [139.85.229.22])
	by mars.hss.co.in (8.10.0/8.10.0) with SMTP id e8KDFIC07412
	for ; Wed, 20 Sep 2000 18:45:20 +0530 (IST)
Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2  (651.2 6-10-1998))  id 65256960.0040445B ; Wed, 20 Sep 2000 17:11:57 +0530
X-Lotus-FromDomain: HSSBLR
From: pmurthy@hss.hns.com
To: sip@lists.bell-labs.com
Message-ID: <65256960.003FDDC5.00@sampark.hss.hns.com>
Date: Wed, 20 Sep 2000 17:07:35 +0530
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Subject: [SIP] A Clarification
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com




With reference to "http://www.cs.columbia.edu/~hgs/sip/notes.html", under
the Www-Authenticate and Authorization sub-heading, it has been mentioned
that the two headers could be Req & Response hdrs. But, in the SIP Grammar
link
http://www.cs.columbia.edu/~hgs/sip/syntax/draft-ietf-sip-rfc2543bis-01.htm
l, Authorization is included under "request-header" and Www-Authenticate
under "response-header" . Am I looking at the correct Grammar links ? Is
there a correction needed ?

Regards
Prashant




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


From sip-admin@lists.bell-labs.com  Wed Sep 20 09:19: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 JAA21988
	for ; Wed, 20 Sep 2000 09:19: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 52E194436C; Wed, 20 Sep 2000 08:18:57 -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 7FACE44357
	for ; Wed, 20 Sep 2000 08:18:24 -0400 (EDT)
Received: from armorse (PPP-189-133.bng.vsnl.net.in [203.197.189.133]) by mail.in.huawei.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21)
	id S7TKD31L; Wed, 20 Sep 2000 18:48:39 +0530
Reply-To: 
From: "Bodgey" 
To: 
Date: Wed, 20 Sep 2000 18:47:39 +0530
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.00.2919.6600
Subject: [SIP] About via-receieved:
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

Hi:
   I have a question. In RFC2543, there write" To prevent this, a proxy
SHOULD check the top-most Via header field to ensure that it contains the
sender's correct network address, as seen from that proxy", I don't know
whether every proxy will do this operation of "CHECK"? How do a proxy can
check that the address of previous hop is correct? There is not a method to
decribe it in RFC2543.

   Would some anwser this question? 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  Wed Sep 20 10:07: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 KAA23456
	for ; Wed, 20 Sep 2000 10:07: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 6E34D44368; Wed, 20 Sep 2000 09:06:49 -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 51F8844339
	for ; Wed, 20 Sep 2000 09:06:41 -0400 (EDT)
Received: from cisalpino.cs.columbia.edu (cisalpino.cs.columbia.edu [128.59.19.194])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id KAA04286;
	Wed, 20 Sep 2000 10:06:34 -0400 (EDT)
Received: from localhost (kns10@localhost)
	by cisalpino.cs.columbia.edu (8.9.3/8.9.3) with ESMTP id KAA04591;
	Wed, 20 Sep 2000 10:06:33 -0400 (EDT)
Date: Wed, 20 Sep 2000 10:06:33 -0400 (EDT)
From: Kundan Singh 
To: Bodgey 
Cc: sip@lists.bell-labs.com
Subject: Re: [SIP] About via-receieved:
In-Reply-To: 
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-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com


> Hi:
>    I have a question. In RFC2543, there write" To prevent this, a proxy
> SHOULD check the top-most Via header field to ensure that it contains the
> sender's correct network address, as seen from that proxy", I don't know
> whether every proxy will do this operation of "CHECK"? How do a proxy can
> check that the address of previous hop is correct? There is not a method to
> decribe it in RFC2543.

You can use the socket library (if using TCP or UDP) to get
the remote IP address (both accept() and recvfrom() can give that)
and compare it with Top-Via in received request (possibly after
some DNS lookup).

> 
>    Would some anwser this question? 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  Wed Sep 20 10:24: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 KAA23868
	for ; Wed, 20 Sep 2000 10:24: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 7B3FE44357; Wed, 20 Sep 2000 09:24:48 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72])
	by lists.bell-labs.com (Postfix) with ESMTP id 4633144339
	for ; Wed, 20 Sep 2000 09:24:42 -0400 (EDT)
Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef)
	id PAA20274; Wed, 20 Sep 2000 15:21:49 +0100 (BST)
From: "Jo Hornsby" 
To: "Pathangi N Janardhanan" ,
        
Subject: RE: [SIP] question on receiving multiple invites
Date: Wed, 20 Sep 2000 15:21:49 +0100
Message-ID: <000301c0230e$1d566750$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: <031701c02300$f5823fe0$38c9a8c0@labs>
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

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

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 Sep 20 11:24: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 LAA24929
	for ; Wed, 20 Sep 2000 11:24: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 CAA2A44378; Wed, 20 Sep 2000 10:17:40 -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 6D8FA44339
	for ; Wed, 20 Sep 2000 10:02:06 -0400 (EDT)
Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Wed Sep 20 11:00:59 EDT 2000
Received: by lists.bell-labs.com (Postfix)
	id 94E994437D; Wed, 20 Sep 2000 10:47: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 4949A44341
	for ; Wed, 20 Sep 2000 10:47:49 -0400 (EDT)
Received: by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2)
	id JAA07077; Wed, 20 Sep 2000 09:47:46 -0500
Cc: sip@lists.bell-labs.com
Received: from lucent.com by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2)
	id JAA07067; Wed, 20 Sep 2000 09:47:44 -0500
Message-ID: <39C8CE11.AC0CA8E1@lucent.com>
Date: Wed, 20 Sep 2000 09:47:45 -0500
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: bodgey@in.huawei.com
Original-CC: sip@lists.bell-labs.com
Subject: Re: [SIP] About via-receieved:
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-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

Bodgey wrote:
> 
> Hi:
>    I have a question. In RFC2543, there write" To prevent this, a 
> proxy SHOULD check the top-most Via header field to ensure that it 
> contains the sender's correct network address, as seen from that 
> proxy", I don't know whether every proxy will do this operation of 
> "CHECK"? 

Even though it is a SHOULD, it is fairly easy to do; so I would presume
most implementations actually do this.

> How do a proxy can check that the address of previous hop is 
> correct? There is not a method to decribe it in RFC2543.

If the SIP request was received from a UDP socket, recvfrom() system
call has parameters where the source address is stored.  If the SIP 
request was received via a TCP socket, you can figure out the peer's IP 
address during accept() or use getpeername() later.

- 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 Sep 20 12: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 MAA26100
	for ; Wed, 20 Sep 2000 12:19: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 584A344351; Wed, 20 Sep 2000 10:10:02 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from uzura.cisco.com (uzura.cisco.com [161.44.3.77])
	by lists.bell-labs.com (Postfix) with ESMTP id 5823B44339
	for ; Wed, 20 Sep 2000 10:09:59 -0400 (EDT)
Received: from cisco.com (klingle-ultra.cisco.com [161.44.53.27])
	by uzura.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id LAA10620;
	Wed, 20 Sep 2000 11:07:58 -0400 (EDT)
Message-ID: <39C8D2FC.A1B3148B@cisco.com>
Date: Wed, 20 Sep 2000 11:08:44 -0400
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: Brett Tate 
Cc: SIPbell-labs , sip-mib@egroups.com
Subject: Re: [SIP] draft-ietf-sip-mib-01: Why no response counters per method?
References: <029e01c02291$40020390$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-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

Brett,

If I understand the counters you speak of, I think it 
may have been number 3 with a tendancy toward number 2 ;)

So you are speaking of having counters that reflect
only response messages sent/received by the device
on a per method basis?

I think in the area of response messages we were naturally
more focused on the status code related statistics.  And in 
the area of per method stats we simply focused on general 
in/out counters.

The responses you speak of will be lumped into the
per method stats of sipMethodStatsTable.  I'm not sure
I see a need for providing anything more than that.

Kevin
> Brett Tate wrote:
> 
> Draft-ietf-sip-mib-01 (July 2000) does not define
> a common object for obtaining response
> counters based upon a SIP Method.
> 
> I was wondering which of the following was true:
> 1) I'm not reading the draft correctly.
> 2) It was deemed "not important enough" and
>     excluded as part of a counter reduction process.
> 3) It was over looked, and may need to be added.
> 
> I assume that number 2 is the answer, but I just
> wanted to make sure.
> 
> Thanks in advance for the response.

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 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  Wed Sep 20 14:14: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 OAA29712
	for ; Wed, 20 Sep 2000 14:14: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 5D68844351; Wed, 20 Sep 2000 13:13:42 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from bounty.cisco.com (bounty.cisco.com [161.44.3.204])
	by lists.bell-labs.com (Postfix) with ESMTP id 1278844339
	for ; Wed, 20 Sep 2000 13:13:39 -0400 (EDT)
Received: from cisco.com (rtp-xdm1.cisco.com [161.44.3.80])
	by bounty.cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id OAA28010;
	Wed, 20 Sep 2000 14:12:58 -0400 (EDT)
Message-ID: <39C8FE14.3665D32E@cisco.com>
Date: Wed, 20 Sep 2000 14:12:36 -0400
From: Shail Bhatnagar 
X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Henning Schulzrinne 
Cc: SIP@lists.bell-labs.com
Subject: Re: [SIP] A question about Request-URI:
References: <30B58D519274D41187630050BAD918AF073AD4@mail.in.huawei.com> <39B503D5.E34EDF0E@dynamicsoft.com> <39B50A68.DC5192A1@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-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

On a related note, when a proxy does a successful SRV lookup for
domain.com and gets bigmachine.domain.com,5055 and 
bigm2.domain.com,6000 and it selects bigmachine.domain.com,5055.
Should it change the incoming 
sip:abc@domain.com 
to 
sip:abc@bigmachine.domain.com:5055 ??

I believe, it should.

Also, when forwarding a request using the Route header, should 
the outgoing Request-URI always be the addr-spec portion of the Route
header or it can be different due to SRV lookup on the maddr ??

Thanks,
Shail



Henning Schulzrinne wrote:
> 
> Attempt at a paragraph for the introduction:
> 
> SIP requests are forwarded by proxies. User agents send requests either
> directly to the address indicated in the request URI or to a designated
> proxy (``outbound proxy'').  Each proxy can forward the request based
> on
> any combination of local policy decisions and information in the
> request. It {\MAY} rewrite the the request URI. A proxy {\MAY} also
> forward the request to another designated proxy regardless of the
> request URI. For example, a departmental proxy could forward all
> authorized requests to a corporate-wide proxy which then forwards it
> to
> the proxy operated by the Internet service provider, which finally
> routes the request based on the request URI.
> 
> ----
> 
> The introduction already has the more formal:
> 
> When a client wishes to send a request, the client either sends it to
> a locally configured SIP proxy server (as in HTTP), independent of the
> \header{Request-URI}, or sends it to the IP address and port
> corresponding to the \header{Request-URI}.
> 
> --
> 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 Sep 20 14:43: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 OAA00306
	for ; Wed, 20 Sep 2000 14:43: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 5D5B144351; Wed, 20 Sep 2000 13:43:13 -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 5D1AF44339
	for ; Wed, 20 Sep 2000 13:03:52 -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 LAA29774;
	Wed, 20 Sep 2000 11:04:14 -0700
Message-ID: <39C8FC1E.970C76E8@mobilerain.com>
Date: Wed, 20 Sep 2000 11:04:14 -0700
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: farhan 
Cc: sip 
Subject: Re: [SIP] IM Questions
References: <000001c022b6$bae165e0$2014c5cb@bigboy>
Content-Type: multipart/mixed;
 boundary="------------5D9EF92C72C9641EC69979E5"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com

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

Greetings:

farhan wrote:

> my apologies for sending the last two mails from a colleagues email id. the
> messages sent from diyanat's email id were mine.
>
> back to u sean ...
>
> >>                         each message is relayed twice.
> >>                 if there are fifty memebers in a group,
> >>                         each message is relyaed 50 times.
> >
> >If you are speaking about text messages, the bandwidth is minimal.
> >This can be done in a stateless manner by the centralised server
> >and so involves no state information per message (there is
> >registration state of course).
>
> if the server is stateless, then the error recovery is again the job of
> MESSAGE orginator. this leads to an unelegent situation where the central
> server is aware of group memberships and hence the state of a group but
> refuses to deliver MESSAGEs. the state is now split between the sender and
> the centralised server.
> I guess that such a situation can lead to fragile states. a state ought to
> be completely maintain at one node. Let me give u an example:
> a sender has a list of five group members while the central server has six
> in its list. now when the sender sends one copy to the server, the server
> replicates this to the six members. as the server doesn't maintain the
> state, it promptly forgets about the message and relays back responses from
> six group members. the sender realises that the sixth new member of the list
> is a sworn enemy of his and should never have received the message. however,
> the group server didnt know nor did the sender know about this.

I was wondering if here one can use "Caller preferences" to indicate the
centralized server to perform Accept-Contact or Reject-Contact per IM message.
This essentially will involve sending a new REGISTER with the mentioned
headers. This raises a question:

How can an individual message be marked for distribution to only a subset of
buddy list without the overhead of sending a new REGISTER to indicate so?

>
>
> >> in our implementation, we did the following:
> >> 1. new group starts it's life as a 1-1 chat between two users. this
> >> essentially consists of MESSAGE requests flying back and forth with the
> >> same Call-ID but different CSeq for each message.
> >> 2. a new user is INVITEd to join the group by sending (hold your
> >> breath!) and INVITE message with SDP specifying SIP/2.0/UDP MESSAGE as
> >> the media description. multiple a=participant=userid specify the other
> >> participants in the list.
> >> 3. upon receiving an INVITE, the called user reacts just like a normal
> >> SIP response and awaits an ACK from the caller.
> >> 4. Once the MESSAGE session is established, the called user sends a
> >> dummy MESSAGE with the group chat's Call-ID to update everyone's group
> >> list.
> >>
> >
> >Why not use the Call-ID of the INVITE and skip step 4. Other than
> >that, this is basically what I had in mind as well (except for the
> >media description :)
>
> If A, B and C were a group and A INVITED D. then B and C should know that D
> has joined (to put D on their group lists). Therefore, it is D who should
> signal this to B and C.

There are constraints here:

a. Is D a part of the group? If not add it -- should be performed by the
centralized server. INVITE D.
b. Propagate the notification that D is on-line -- should be performed by the
centralized server.
c. Add D to the buddy list inbox for distribution of originating MESSAGEs --
should be performed by the centralized server.

This essentailly leads to a thin UAC and intelligent central control -- the
server.

Regards,

Bobby.Sardana@mobilerain.com

> Using the Call-ID of the INIVTE, D now sends a dummy
> message to B and C and gets onto their group lists.
> I havent understood how I can skip this step. This step is as kludgy as it
> gets and I would rather not do this at all.
>
> >> the advantages of this scheme are:
> >> 1. any member of the list can now choose between taking a text only or a
> >> text+voice chat. this is especially important if the UA can handle only
> >> one voice call while being able to handle multiple message sessions.
> >> 2. a user can maintain (and it does in our UA) the list of banned userid
> >> or refuse to receive messages from a particular user.
> >
> >This can be done with a centralized server as well.
>
> The advantage of doing this with a central server is that a user could login
> from anywhere and retrieve her original friends list (note that I didnt use
> the patente word 'buddy'). I have tried to keep away from stout servers and
> put more intelligence on the peers. This is the guiding principle enunciated
> by Henning.
>
> >> 3. while sending a message to all the group members, if a 200 OK
> >> response doesnt arrive from a particular user, the user is removed from
> >> the group list if it is a final response. thus, a userid is removed from
> >> a list when a user returns with a 400+ final response.
> >
> >I'm not sure I would take this approach. There are many 400+ responses
> >that might indicate just a transient error that might be recoverable
> >on subsequent MESSAGE requests, especially since the routing of the
> >MESSAGE might involve things like forking, DNS SRV lookups, etc.
> >A 600 class response would clearly indicate that the user should be
> >removed, but the other response codes I would look at individually.
>
> Absolutely. you are right.
>
> >> 4. as the scheme is completely peer-to-peer, the centralised chat server
> >> bandwidth is conserved and the users have to pay (nominally though, text
> >> is hardly bandwidth intensive) by bandwidth whenever they send a group
> >> message.
> >
> >But the user ends up paying proportionally to the size of the group :(
>
> Which is poetic justice of sorts. groups are usually about 5-4 each. bigger
> groups are just a headache for everyone and usually a person ends up
> chatting with just a couple of others in a packed room.
>
> >> 6. this scheme will work well with the existing clients that understand
> >> only MESSAGE, INVITE. we are only adding a new session type.INVITE is
> >> interpreted the same way as before.
> >
> >With a new media type and the understanding that the first MESSAGE
> >after the INVITE conveys the Call-ID for the chat session.
>
> The Call-ID specified in the INVITE is the same as the Call-ID of the
> subsequent messages for that session.
> btw, this scheme makes it possible to have more than one sessions with
> another user. most of the current crop of messengers drop all the messages
> from a user into a single window. this makes it impossible to have a session
> of a different context between two specific users in a group.
>
> >> But are we moving towards IM domination or are we adding minimal IM for
> >> functionality? the approach in would be different for the two aims. If
> >> we are to provide a high class IM, then we cannot bifurcate the
> >> SUBSCRIBE, MESSAGE and REGISTER into separate and independent proposals.
> >> they all MUST be implemented and available together.
> >
> >Actually they all work quite well independently. MESSAGE does not
> >rely on SUBSCRIBE or REGISTER. REGSITER obviously does not depend
> >on MESSAGE or SUBSCRIBE. And SUBSCRIBE can be used for things far
> >beyond IM. They do work wonderfully together though.
>
> hmmm  "SUBSCRIBE can be used for things far beyond IM" . can i subscribe to
> being invited for a session whenever it is on? for instance, i want to know
> be invited to the soccer commentary whenever the game starts.
>
> >> the main advantage of peer to peer messaging is that there are no
> >> servers to crash out and attack. a trivial Redirect UDP server handling
> >> REGISTER and MESSAGE is all that is required.
> >
> >You don't consider this a central server? Or do you intend to
> >implement this on one of the peers?
>
> My redirect server is about 1000 lines of code. It handles SIP messages as
> fast as they come in. UAs just get each other's Contact: and go away. Thus,
> the server is not really required to sustain sessions. I would have loved to
> be able to implement this on a peer. the problem however is, how do u (a
> fresh user, just logged in from a dialip) contact the first peer of the
> network?
>
> >
> >> this is architecturally a
> >> beautiful piece. the problem is that without a server, that you cannot
> >> add more services and functionality to a network unless the UAs are
> >> replaced. while in a server based messaging system, sky is the limit
> >> (rather, the complexity and bandwidth are the limitations).
> >> it would be best if you could leave out the decision of either of the
> >> two to the implementors and have a protocol that will work well in both
> >> cases. I think that MESSAGE is one such scheme. But SUBSCRIBE is not.
> >
> >I don't understand your argument regarding SUBSCRIBE vs. MESSAGE.
> >[I'm making the bold assumption that you can send a NOTIFY without
> >a prior SUBSCRIBE; not in the current draft, but a useful mechanism]
>
> I meant that MESSAGE work both peer to peer as well as through centralised
> servers.
> However, SUBSCRIBE requires a presence server to be present so that offline
> userids can be subscribed to. Thus, presence requires a presence server.
>
> >> In
> >> a steamy undernet server, i cant imagine sending SUBSCRIBE to over
> >> hunderd users each time I join or leave a group.
> >
> >Vs. sending your MESSAGE to a hundred users?
>
> ouch! that is true. but  can't a server consolidate the list of all the
> joins and leaves of the past few seoncds and send a update of the userlist
> to all the group members? this area does require a more optimal solution.
>
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip

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

--------------5D9EF92C72C9641EC69979E5--




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


From sip-admin@lists.bell-labs.com  Wed Sep 20 14:57: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 OAA02094
	for ; Wed, 20 Sep 2000 14:57: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 4A6C444369; Wed, 20 Sep 2000 13:57:30 -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 0829A44364
	for ; Wed, 20 Sep 2000 13:57:27 -0400 (EDT)
Received: from tate ([216.181.56.35]) by broadsoft.com (8.8.8) id OAA93246; Wed, 20 Sep 2000 14:57:11 -0400 (EDT)
Message-ID: <02fa01c02334$b4137720$3202a8c0@broadsoft.com>
From: "Brett Tate" 
To: "Kevin Lingle" 
Cc: "SIPbell-labs" , 
References: <029e01c02291$40020390$3202a8c0@broadsoft.com> <39C8D2FC.A1B3148B@cisco.com>
Subject: Re: [SIP] draft-ietf-sip-mib-01: Why no response counters per method?
Date: Wed, 20 Sep 2000 14:57:59 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.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-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

> If I understand the counters you speak of, I think it 
> may have been number 3 with a tendancy toward number 2 ;)
> 
> So you are speaking of having counters that reflect
> only response messages sent/received by the device
> on a per method basis?
> 
> I think in the area of response messages we were naturally
> more focused on the status code related statistics.  And in 
> the area of per method stats we simply focused on general 
> in/out counters.
> 
> The responses you speak of will be lumped into the
> per method stats of sipMethodStatsTable.  I'm not sure
> I see a need for providing anything more than that.

The main benefit is to enable a correlation of 
method count to a success or failure count.  
For example, it might be nice to know that 
every time a BYE was sent a Request Failure 
was received.

I assume that it would be nice to know that
every time an INVITE was sent, a Request
Failure was received.  

I assume that it would also be nice to 
know how often a REFER was rejected 
because of a Request Failure.  

A similar counter was added for REGISTER.  
I just thought it might be nice to define these
at a global level to avoid having to individually
add success and failure counters for each
new method which might want it.

Just a thought...

-Brett




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


From sip-admin@lists.bell-labs.com  Wed Sep 20 15:19: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 PAA02384
	for ; Wed, 20 Sep 2000 15:19: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 3878F44378; Wed, 20 Sep 2000 14:19:24 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from sundns.transnexus.com (unknown [216.162.34.201])
	by lists.bell-labs.com (Postfix) with ESMTP id 7238344351
	for ; Wed, 20 Sep 2000 14:19:19 -0400 (EDT)
Received: from notebook.transnexus.com ([192.168.1.198])
	by sundns.transnexus.com (8.9.3+Sun/8.9.3) with ESMTP id TAA27197
	for ; Wed, 20 Sep 2000 19:19:16 GMT
Message-Id: <5.0.0.25.2.20000920151500.00a8ad40@mail.transnexus.com>
X-Sender: sthomas@mail.transnexus.com
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Wed, 20 Sep 2000 15:21:43 -0400
To: sip@lists.bell-labs.com
From: Stephen Thomas 
Subject: Re: [SIP] SIP gateways and authentication
In-Reply-To: <4.3.1.2.20000902094940.030e9a40@shell11.ba.best.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-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com

Relatively far from the topic, but it seemed worthwhile to clear up any 
potential misinformation.

At 12:51 PM 2000-09-02, James A. Donald wrote:
>A single https web page takes many public key operations, typically eight 
>to twelve per web page

This is simply not true. For the first Web page retrieved from a server, 
the client (browser) has to do at least one decryption to validate the 
server's certificate and one encryption to encrypt the session key. The 
server then has to do one decryption to recover the session key. (The 
client may have to do more than one decryption if it needs to validate 
multiple levels in a certificate hierarchy.) That's it, and once the 
session key has been exchanged, it can be used for subsequent pages (either 
through HTTP persistence or SSL session re-use).

Stephen


____________________________________________________________________
Stephen Thomas                                       +1 404 872 4887
TransNexus, Chief Technical Officer    stephen.thomas@transnexus.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 Sep 20 15:21: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 PAA02401
	for ; Wed, 20 Sep 2000 15: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 D610244384; Wed, 20 Sep 2000 14:19:27 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from sundns.transnexus.com (unknown [216.162.34.201])
	by lists.bell-labs.com (Postfix) with ESMTP id 64F3144338
	for ; Wed, 20 Sep 2000 14:19:19 -0400 (EDT)
Received: from notebook.transnexus.com ([192.168.1.198])
	by sundns.transnexus.com (8.9.3+Sun/8.9.3) with ESMTP id TAA27194
	for ; Wed, 20 Sep 2000 19:19:15 GMT
Message-Id: <5.0.0.25.2.20000920150259.00a6fb78@mail.transnexus.com>
X-Sender: sthomas@mail.transnexus.com
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Wed, 20 Sep 2000 15:11:35 -0400
To: sip@lists.bell-labs.com
From: Stephen Thomas 
Subject: Re: [SIP] Re: SIP gateways and authentication
In-Reply-To: <39AE728D.AE5AAF81@cs.columbia.edu>
References: <89866A7EC9C0D1119C950000F8BCC282016352E9@zrtpd00n.us.nortel.com>
 <39A6035E.4DDC74C0@dynamicsoft.com>
 <14758.38134.851139.496078@thomasm-u1.cisco.com>
 <39A6B1C4.E424802F@cs.columbia.edu>
 <14758.48066.388917.988364@thomasm-u1.cisco.com>
 <39A6C0C3.7BEC4838@cs.columbia.edu>
 <14758.49815.427708.431582@thomasm-u1.cisco.com>
 <39A6C49E.9844FF65@cs.columbia.edu>
 <14758.51787.331133.132625@thomasm-u1.cisco.com>
 <39A6D968.647FBFDB@cs.columbia.edu>
 <14765.12335.868273.287866@thomasm-u1.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-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com


Finally getting around to reading old email and noticed no one had answered 
this.

At 10:58 AM 2000-08-31, Henning Schulzrinne wrote:
> >
> >  > Are there statistics on the typical cert size?
> >
> >    Probably, but I don't have any handy. I've
> >    heard that typical certs are ~500 bytes and
> >    that you need to ship part of the hierarchy
> >    which may include a cert or two more. Even if
> >    it's half, it's still problematic for multiple
> >    realms.
>
>Statistics would be most helpful here. If you have the model used by
>today's web browsers, it would be presumably one certificate (with
>pre-configured CA certificates). Given 512 bit public keys (64 bytes),
>the estimate sounds close.


X.509 certificates can vary a lot in size, as CAs like to stuff all sorts 
of things within them. (Even, for example, Certification Practice 
Statements.) As a rule of thumb, Verisign certificates are around 1500 
bytes. For anyone wants to see the gory details, _SSL_and_TLS_Essentials_ 
http://www.amazon.com/exec/obidos/ASIN/0471383546/ breaks down a real 
Verisign Global Site ID byte by tedious byte; the example is 1384 bytes.




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


From sip-admin@lists.bell-labs.com  Wed Sep 20 15:42: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 PAA02776
	for ; Wed, 20 Sep 2000 15:42: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 D777A44376; Wed, 20 Sep 2000 14:42:16 -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 AAB6344338
	for ; Wed, 20 Sep 2000 14:42:13 -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 PAA00568;
	Wed, 20 Sep 2000 15:37:56 -0400 (EDT)
Message-ID: <39C91311.B6ADC910@nist.gov>
Date: Wed, 20 Sep 2000 15:42:10 -0400
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: Jonathan Rosenberg 
Subject: Re: [SIP] A question on forwarding INVITES
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-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit



Based on your response to the first question, I am assuming that it is OK to
forward INVITEs to unregistered UAS's  as well.  The proxy can extract username
and host from the  SIP Url that is part of the request and use this to forward
the request. Of course,  this could result in servers sending unsolicited
invites (which are ignored by the UAS).

I have a follow-up question regarding user locaton and forwarding of invites.
( These are newbie questions so put the kid gloves on).

In my design, I  am making  the following assumptions:

1. If the target of the invite has not REGISTERed, then the invite is forwarded
based on address imbedded in the SIP url.

2, If the targetted user HAS a valid REGISTER, then  the addresses in the
registration record is used to forward the INVITE.

If 1 and 2 fail  then

3  Do a  lookup via LDAP or rwho etc (i.e. use a  location server) to figure
out where to send the invite where the information needed to do the lookup is
available as SIP URL parameters (name, value pairs).

Is item 3 the responsibility of the SIP proxy server? The RFC seems to indicate
that the SIP server MAY talk to a locaton server in addition to using REGISTER
(and there must be a good reason for it).  I realize that this is a design
choice but it affects the complexity of the system.   Why not let it be the
caller's responsibility to locate the user by talking directly to location
services if need be?

Thank you for answering  both my  previous questions.

Regards,
Ranga.


Jonathan Rosenberg wrote:

> > -----Original Message-----
> > From: M. Ranganathan [mailto:mranga@nist.gov]
> > Sent: Monday, September 18, 2000 5:59 PM
> > To: sip@lists.bell-labs.com
> > Subject: [SIP] A question on forwarding INVITES
> >
> >
> > Hello!
> >
> > When a proxy server forwards an invite,  does it need to have a
> > registration from the server that it is forwarding it to (or
> > is this an
> > implementation choice)?
>
> No, it doesn't need to have a registration.
>
> Routing is a matter of local policy. A proxy can use whatever means it sees
> fit to determine what next hop to forward to.
>
> >
> > Second,  it would appear to be a good idea to periodically propagate
> > user location information  between proxy's  to reduce latency  in  for
> > user location.  If so, is there a  recommended method to do this? (and
> > if not, is there a good argument against it?)
>
> Let me make sure I am understanding what you are proposing. Lets say I
> register to engineering.dynamicsoft.com. Your proposal is that my
> registration basically be propagated to dynamicsoft.com as well, so that
> calls for me (jdrosen@dynamicsoft.com) can go directly to my PC, rather than
> first to engineering and then to my PC?
>
> There is no way for this to be done now; its close in concept to what TRIP
> provides, but in this case its intra-domain and not phone numbers.
>
> I don't think its a good idea in any case, as it presents a monstrous
> scalability problem. I'll also note that in many cases proxies exist on the
> call establishment path for useful purposes, and bypassing them is not
> necessarily a good thing.
>
> -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

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





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


From sip-admin@lists.bell-labs.com  Wed Sep 20 15:55: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 PAA03553
	for ; Wed, 20 Sep 2000 15:55: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 23ED744386; Wed, 20 Sep 2000 14:55:14 -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 85B9144351
	for ; Wed, 20 Sep 2000 14:55:11 -0400 (EDT)
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 MAA05126
	for ; Wed, 20 Sep 2000 12:55:25 -0700 (PDT)
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 PAA04681 for ; Wed, 20 Sep 2000 15:54:34 -0400 (EDT)
Message-ID: <39C915FA.C9A1C4AB@cisco.com>
Date: Wed, 20 Sep 2000 15:54:34 -0400
From: Sudipto Mukherjee 
Organization: Cisco
X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: sip@lists.bell-labs.com
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: [SIP] Content-Disposition Header questions
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

In Sec 6.15, Content-Disposition of draft-ietf-sip-rfc2543bis-02.ps,
the following is stated -

disposition-type = "render" "session" "Icon" "alert"
disp-extension-token

I need clarification on the usage of the above disposition-types for
early media and preconditions. 

In my understanding -

"alert" is used in 18X responses to convey early cut-thru or early media
cases.

To indicate preconditions such as qos / security in 183 as defined in
manyfolks draft, disposition-type is set to "session". Additionally, the
attribute line in SDP such a=qos:mandatory or a=security ... specifies
the
type of precondition. 

Please comment on the above.

Thanks
-- Sudipto


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


From sip-admin@lists.bell-labs.com  Thu Sep 21 00:06: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 AAA16630
	for ; Thu, 21 Sep 2000 00: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 AFFF644351; Wed, 20 Sep 2000 23:06:19 -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 9831544338
	for ; Wed, 20 Sep 2000 23:06:10 -0400 (EDT)
Received: from sampark.hss.hns.com (sampark.hss.hns.com [139.85.229.22])
	by mars.hss.co.in (8.10.0/8.10.0) with SMTP id e8L46UC15833;
	Thu, 21 Sep 2000 09:36:37 +0530 (IST)
Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2  (651.2 6-10-1998))  id 65256961.0016EA43 ; Thu, 21 Sep 2000 09:40:17 +0530
X-Lotus-FromDomain: HSSBLR
From: airoy@hss.hns.com
To: Pekka Pessi 
Cc: sip@lists.bell-labs.com
Message-ID: <65256961.0016E94F.00@sampark.hss.hns.com>
Date: Thu, 21 Sep 2000 09:37:35 +0530
Subject: Re: [SIP] IPv6 addresses in SIP
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-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com








Pekka Pessi  on 09/20/2000 01:55:27 PM

To:   sip@lists.bell-labs.com
cc:    (bcc: Ashok I Roy/HSSBLR)

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.
Instead it might be more prudent to change the definition of generic param
to  something like
                    generic param =   token  [ (= token | quoted string |
ipv6addr) ]

this definition might have problems in certain headers where an ipv6
address or any address is not acceptable.....howevre  this  approach might
just be easier to imnplement and may be more desirable  than the suggested
approach. We can leave it to the application to decide the validity of an
ipv6 address being present in the generic param after it is parsed by the
parser or a simple lcheck might just suffice.


regards,
ashok
-------------
ashok roy @ 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 Sep 21 04:27: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 EAA01349
	for ; Thu, 21 Sep 2000 04:27: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 6257744351; Thu, 21 Sep 2000 03:27:01 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72])
	by lists.bell-labs.com (Postfix) with ESMTP id 3412744338
	for ; Thu, 21 Sep 2000 03:26:57 -0400 (EDT)
Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef)
	id JAA04576; Thu, 21 Sep 2000 09:24:45 +0100 (BST)
From: "Jo Hornsby" 
To: "Shail Bhatnagar" ,
        "Henning Schulzrinne" 
Cc: 
Subject: RE: [SIP] A question about Request-URI:
Date: Thu, 21 Sep 2000 09:24:45 +0100
Message-ID: <000601c023a5$663c0780$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: <39C8FE14.3665D32E@cisco.com>
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

> On a related note, when a proxy does a successful SRV lookup for
> domain.com and gets bigmachine.domain.com,5055 and 
> bigm2.domain.com,6000 and it selects bigmachine.domain.com,5055.
> Should it change the incoming 
> sip:abc@domain.com 
> to 
> sip:abc@bigmachine.domain.com:5055 ??
> 
> I believe, it should.

Interesting.  I believe it should not. &:)

If you look at the rules of Section 1.4.2, all the magic done
is _based on the Request-URI_; suggesting that the Request-URI
is already well-defined at that point.

Imagine a case where you have a Large Corporation, the ubiquitous
example.com.  Now example.com has two divisions: division1 and
division2.  If there were two distinct Smith's working for
example.com, one in division1 and one in division2, then they
might have the SIP URLs
sip:smith@division1.example.com,
sip:smith@division2.example.com,
respectively.  Now if there's a large SIP proxy sitting "at the
edge" of example.com, sip.example.com, and this proxy can be
found via SRV, then changing the Request-URI could potentially
result in a fatal loss of information.  Not good.

Of course, as always, proxies are free to do what they want --
it's their birthright; thus there may well be situations where
this is exactly what you want.  In general, however, I would
argue that it is not what you want.

> Also, when forwarding a request using the Route header, should 
> the outgoing Request-URI always be the addr-spec portion of the Route
> header or it can be different due to SRV lookup on the maddr ??

The whole Request-URI in the Route is copied into the Request-URI
proper; maddr, transport (although this should never appear in
a Record-Route/Route), etc., parameters are no-longer illegal here.

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 Sep 21 05:01: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 FAA01579
	for ; Thu, 21 Sep 2000 05:01: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 43E5D44380; Thu, 21 Sep 2000 04:01:21 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72])
	by lists.bell-labs.com (Postfix) with ESMTP id E5E6144338
	for ; Thu, 21 Sep 2000 04:01:13 -0400 (EDT)
Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef)
	id JAA19307; Thu, 21 Sep 2000 09:59:14 +0100 (BST)
From: "Jo Hornsby" 
To: , 
Cc: "Jonathan Rosenberg" 
Subject: RE: [SIP] A question on forwarding INVITES
Date: Thu, 21 Sep 2000 09:59:15 +0100
Message-ID: <000701c023aa$37f7e7e0$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: <39C91311.B6ADC910@nist.gov>
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

> Based on your response to the first question, I am assuming that it
> is OK to forward INVITEs to unregistered UAS's as well.  The proxy
> can extract username and host from the SIP Url that is part of the
> request and use this to forward the request. Of course, this could
> result in servers sending unsolicited invites (which are ignored by
> the UAS).

Very much so.  If a SIP URL is specific enough that it can be
resolved to an IP:port, for instance, it is completely reasonable
for a SIP client (be it UA or proxy) to try that address "directly".

> I have a follow-up question regarding user locaton and forwarding of
> invites.  ( These are newbie questions so put the kid gloves on).
> 
> In my design, I am making the following assumptions:
> 
> 1. If the target of the invite has not REGISTERed, then the invite
> is forwarded based on address imbedded in the SIP url.
> 
> 2, If the targetted user HAS a valid REGISTER, then the addresses in
> the registration record is used to forward the INVITE.
> 
> If 1 and 2 fail then
> 
> 3 Do a lookup via LDAP or rwho etc (i.e. use a location server) to
> figure out where to send the invite where the information needed to
> do the lookup is available as SIP URL parameters (name, value
> pairs).
> 
> Is item 3 the responsibility of the SIP proxy server? The RFC seems
> to indicate that the SIP server MAY talk to a locaton server in
> addition to using REGISTER (and there must be a good reason for it).
> I realize that this is a design choice but it affects the complexity
> of the system.  Why not let it be the caller's responsibility to
> locate the user by talking directly to location services if need be?

As Jonathan said, a proxy can use whatever means it sees fit to
route.

I might be mistaken, but it seems to me that you're unnecessarily
separating the database "used" by a REGISTER, and a Location
Server.  Basically, these are the same thing.  The RFC uses the
term "Location Server" to abstract the entity that is responsible
for resolving one URI into zero or more URIs.  In simple proxies
that have co-located registrars, a "Location Server" will simply
be a database of all active registrations.

In your steps above, item 1 is interesting, because typically it
always has to be done (okay, I've got a SIP URL, how do I
proceed?).  In general, it's going to consist of steps similar
to those specified in Section 1.4.2.  However, that is totally
up to the proxy.

Thus I would fold item 2 into item 3 (i.e., REGISTERs modify
the Location Server"), and then in a simple implementation you
might get the following:
 a) Apply item 3 to the Request-URI.
 b) If a) yields no results, apply item 1 to the Request-URI,
    and if this resolves to some network address, forward the
    Request there.
 c) If a) yields one or more results, apply item 1 to each
    URI in turn, and forward the Request to each URI that
    resolves to a routable network address.

Other implementations may apply item 1 recursively, or perform
b) regardless of the result of a), or never apply item 3 at
all...the possibilities are endless.

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 Sep 21 08:34: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 IAA04191
	for ; Thu, 21 Sep 2000 08: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 A0CAF44376; Thu, 21 Sep 2000 07:33:08 -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 068DF44338
	for ; Thu, 21 Sep 2000 05:46:43 -0400 (EDT)
Received: by esebh02nok with Internet Mail Service (5.5.2650.10)
	id ; Thu, 21 Sep 2000 13:46:33 +0300
Message-ID: <25B79E9476BAD211811B0008C7894CDC040240C2@treis04nok>
From: petri.koskelainen@nokia.com
To: sip@lists.bell-labs.com
Date: Thu, 21 Sep 2000 13:46:32 +0300
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.10)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [SIP] Re: IPv6 addresses in SIP
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com

Hi,

It is true that the IPv6 extensions to host and parameters are not
compatible with HTTP 1.1 but 
there are also other incompatibilies between SIP syntax and HTTP syntax. 
Therefore, this new incompatibility is not valid reason for changing the SIP
syntax.

The bis-01 syntax works fine as it is.

It should be enough to modify the implementation of parameter parsing in
exactly one place in a parser, 
e.g change the syntax from:

  generic-parameter-for-all-headers = token "=" token

to

  generic-parameter-for-all-headers = token "=" (token | host)

Then, implementing support for IPv6 addresses elsewhere in the syntax should
be done similarly by just modifying
the host syntax according to the bis-01 draft.


--
Petri



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


From sip-admin@lists.bell-labs.com  Thu Sep 21 11:17: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 LAA07526
	for ; Thu, 21 Sep 2000 11:17: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 B45ED44351; Thu, 21 Sep 2000 10:17:20 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from bounty.cisco.com (bounty.cisco.com [161.44.3.204])
	by lists.bell-labs.com (Postfix) with ESMTP id B92A344343
	for ; Thu, 21 Sep 2000 10:17:16 -0400 (EDT)
Received: from cisco.com (rtp-xdm1.cisco.com [161.44.3.80])
	by bounty.cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id LAA15175;
	Thu, 21 Sep 2000 11:17:03 -0400 (EDT)
Message-ID: <39CA2659.E281C432@cisco.com>
Date: Thu, 21 Sep 2000 11:16:41 -0400
From: Shail Bhatnagar 
X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: SIP@lists.bell-labs.com
Subject: Post-SRV Request-URI (was - [[SIP] A question about Request-URI:])
Content-Type: multipart/mixed;
 boundary="------------26098666D87250F7CFDD57BF"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com

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

Forwarding the email using different subject, since this was an
old thread.
--------------26098666D87250F7CFDD57BF
Content-Type: message/rfc822
Content-Disposition: inline

Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88])
	by bounty.cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id EAA29666
	for ; Thu, 21 Sep 2000 04:26:30 -0400 (EDT)
Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130])
	by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id BAA11023
	for ; Thu, 21 Sep 2000 01:26:36 -0700 (PDT)
Received: from proxy3.cisco.com (localhost [127.0.0.1])
	by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id e8L8Qcc29149
	for ; Thu, 21 Sep 2000 01:26:39 -0700 (PDT)
Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72])
	by proxy3.cisco.com (8.9.1b+Sun/8.9.3) with ESMTP id BAA09281
	for ; Thu, 21 Sep 2000 01:26:33 -0700 (PDT)
Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef)
	id JAA04576; Thu, 21 Sep 2000 09:24:45 +0100 (BST)
From: "Jo Hornsby" 
To: "Shail Bhatnagar" ,
        "Henning Schulzrinne" 
Cc: 
Subject: RE: [SIP] A question about Request-URI:
Date: Thu, 21 Sep 2000 09:24:45 +0100
Message-ID: <000601c023a5$663c0780$4e34c3c1@ubiquity.co.uk>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
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: <39C8FE14.3665D32E@cisco.com>
X-Mozilla-Status2: 00000000
Content-Transfer-Encoding: 7bit

> On a related note, when a proxy does a successful SRV lookup for
> domain.com and gets bigmachine.domain.com,5055 and 
> bigm2.domain.com,6000 and it selects bigmachine.domain.com,5055.
> Should it change the incoming 
> sip:abc@domain.com 
> to 
> sip:abc@bigmachine.domain.com:5055 ??
> 
> I believe, it should.

Interesting.  I believe it should not. &:)

If you look at the rules of Section 1.4.2, all the magic done
is _based on the Request-URI_; suggesting that the Request-URI
is already well-defined at that point.

Imagine a case where you have a Large Corporation, the ubiquitous
example.com.  Now example.com has two divisions: division1 and
division2.  If there were two distinct Smith's working for
example.com, one in division1 and one in division2, then they
might have the SIP URLs
sip:smith@division1.example.com,
sip:smith@division2.example.com,
respectively.  Now if there's a large SIP proxy sitting "at the
edge" of example.com, sip.example.com, and this proxy can be
found via SRV, then changing the Request-URI could potentially
result in a fatal loss of information.  Not good.

Of course, as always, proxies are free to do what they want --
it's their birthright; thus there may well be situations where
this is exactly what you want.  In general, however, I would
argue that it is not what you want.

> Also, when forwarding a request using the Route header, should 
> the outgoing Request-URI always be the addr-spec portion of the Route
> header or it can be different due to SRV lookup on the maddr ??

The whole Request-URI in the Route is copied into the Request-URI
proper; maddr, transport (although this should never appear in
a Record-Route/Route), etc., parameters are no-longer illegal here.

HTH,


 - Jo.



--------------26098666D87250F7CFDD57BF--



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


From sip-admin@lists.bell-labs.com  Thu Sep 21 11: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 LAA08538
	for ; Thu, 21 Sep 2000 11:54: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 164AD44392; Thu, 21 Sep 2000 10:53:02 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72])
	by lists.bell-labs.com (Postfix) with ESMTP id B9B3F44343
	for ; Thu, 21 Sep 2000 10:52:57 -0400 (EDT)
Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef)
	id QAA24855; Thu, 21 Sep 2000 16:21:22 +0100 (BST)
From: "Jo Hornsby" 
To: 
Date: Thu, 21 Sep 2000 16:21:22 +0100
Message-ID: <000c01c023df$99b29270$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
Subject: [SIP] Record-Route and port
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

Hi,

In the thread "Record-Route and maddr" (around July 21), we had
the following:

> Shail Bhatnagar wrote:
> >
> > Let us say proxy "proxy.domain.com" listening at port 5060 receives 
> > this request : 
> > 
> > INVITE sip:abc@xyz.com SIP/2.0 
> > 
> > and it introduces a Record-Route header. 
> > My question is should the Record-Route look like : 
> > 
> >  
> > 
> > or 
> > 
> >  
>
> Actually, neither. Its: 
>
>  
>
> i.e., you *copy* the request URI into the record-route, and add
> your own address into the port, maddr, transport parameters.

The bit about copying the port does not seem to have made it into
bis02?  (Note that "transport" was a typo.)


 - Jo.
-- 
  Jo Hornsby; IT Professional         --       mailto:jhornsby@ubiquity.net
 Ubiquity Software Corporation        --         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  Thu Sep 21 12:07: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 MAA08935
	for ; Thu, 21 Sep 2000 12: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 7FF4744399; Thu, 21 Sep 2000 11:05:37 -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 EE1B844343
	for ; Thu, 21 Sep 2000 11:05:33 -0400 (EDT)
Received: from zrtpd004.us.nortel.com (actually zrtpd004) 
          by ertpg14e1.nortelnetworks.com; Thu, 21 Sep 2000 12:04:06 -0400
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) 
          id ; Thu, 21 Sep 2000 12:02:51 -0400
Message-ID: <28560036253BD41191A10000F8BCBD11480DBD@zcard00g.ca.nortel.com>
From: "Tom-PT Taylor" 
To: sip 
Subject: RE: [SIP] Overlap dialing in SIP
Date: Thu, 21 Sep 2000 12:02:48 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C023E5.62F6FA90"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com

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_01C023E5.62F6FA90
Content-Type: text/plain;
	charset="iso-8859-1"

Is it truly the consensus that you can't do a re-INVITE before the final
response is received on an earlier INVITE?  I'm looking at a blind call
transfer situation where the controlling party hangs up while the transfer
target is still ringing.  In my particular scenario it would be useful to
redirect media from the target to the transferred party within the context
of the original call from the controlling party.  (Sounds strange, but it
has to do with support of legacy billing models.)  If I can't do a re-INVITE
I'll have to initiate another call-leg instead.

> -----Original Message-----
> From: Pathangi N Janardhanan [mailto:janar@netlab.hcltech.com]
> Sent: Tuesday, September 19, 2000 9:45 PM
> To: Aseem Agarwal; sip
> Subject: Re: [SIP] Overlap dialing in SIP
> 
> 
> Hi Aseem,
> 
> 
> > I need some clarification about overlap dialing in SIP as referred
> in
> > Section 4.2.1
> >
> > "A UAC MUST NOT issue another INVITE request for the same call leg
> > before the previous transaction has completed"
> >
> > "A UAS acting as a gateway ..."
> >
> > The above two references are confusing. If a UAC can not initiate
> > a reINVITE before receiving a definite response, how does a UAS at a
> > GW get additional digits ? A Gateway can get additional digits once
> > the call is established (may be for supplementary services)but not
> > in call set up phase. Is this correct ?
> 
>  Please see draft-camarillo-sip-isup-bcp-00.txt for a detailed
> call flow scenario of overlap dialing in SIP-ISUP mapping.
> 
> >
> > Another source of confusion :
> >
> > "If the UAC wishes to modify the session after the call set up has
> > begun, it MUST use another INVITE request"
> >
> > Can a UA after sending an INVITE, send another INVITE for modifying
> the
> > session parameters before getting a definite response ( in call set
> up
> > phase itself) ?
> 
>  A re-invite for the same call leg can be sent only after the first
> INVITE
> has got a definite response.
> 
> Jana
> 
> 
> 
> 
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip
> 

------_=_NextPart_001_01C023E5.62F6FA90
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: [SIP] Overlap dialing in SIP




Is it truly the consensus that you can't do a =
re-INVITE before the final response is received on an earlier =
INVITE?  I'm looking at a blind call transfer situation where the =
controlling party hangs up while the transfer target is still =
ringing.  In my particular scenario it would be useful to redirect =
media from the target to the transferred party within the context of =
the original call from the controlling party.  (Sounds strange, =
but it has to do with support of legacy billing models.)  If I =
can't do a re-INVITE I'll have to initiate another call-leg =
instead.



> -----Original Message-----

> From: Pathangi N Janardhanan [mailto:janar@netlab.hcltech.com=
]

> Sent: Tuesday, September 19, 2000 9:45 =
PM

> To: Aseem Agarwal; sip

> Subject: Re: [SIP] Overlap dialing in =
SIP

> 

> 

> Hi Aseem,

> 

> 

> > I need some clarification about overlap =
dialing in SIP as referred

> in

> > Section 4.2.1

> >

> > "A UAC MUST NOT issue another INVITE =
request for the same call leg

> > before the previous transaction has =
completed"

> >

> > "A UAS acting as a gateway =
..."

> >

> > The above two references are confusing. If =
a UAC can not initiate

> > a reINVITE before receiving a definite =
response, how does a UAS at a

> > GW get additional digits ? A Gateway can =
get additional digits once

> > the call is established (may be for =
supplementary services)but not

> > in call set up phase. Is this correct =
?

> 

>  Please see =
draft-camarillo-sip-isup-bcp-00.txt for a detailed

> call flow scenario of overlap dialing in =
SIP-ISUP mapping.

> 

> >

> > Another source of confusion :

> >

> > "If the UAC wishes to modify the =
session after the call set up has

> > begun, it MUST use another INVITE =
request"

> >

> > Can a UA after sending an INVITE, send =
another INVITE for modifying

> the

> > session parameters before getting a =
definite response ( in call set

> up

> > phase itself) ?

> 

>  A re-invite for the same call leg can be =
sent only after the first

> INVITE

> has got a definite response.

> 

> Jana

> 

> 

> 

> 

> =
_______________________________________________

> SIP mailing list

> SIP@lists.bell-labs.com

> http://lists.bell-labs.com/mailman/listinfo/sip

> 





------_=_NextPart_001_01C023E5.62F6FA90--


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


From sip-admin@lists.bell-labs.com  Thu Sep 21 12: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 MAA09529
	for ; Thu, 21 Sep 2000 12:37: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 84FB04438E; Thu, 21 Sep 2000 11:37: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 0B38244338
	for ; Thu, 21 Sep 2000 11:37:02 -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; 21 Sep 2000 16:37:18 UT
Received: from jundery.ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef)
	id RAA19644; Thu, 21 Sep 2000 17:28:04 +0100 (BST)
Received: from localhost (jundery@localhost)
	by jundery.ubiquity.net (8.9.3/8.9.3) with ESMTP id RAA03347
	for ; Thu, 21 Sep 2000 17:28:03 GMT
X-Authentication-Warning: jundery.ubiquity.net: jundery owned process doing -bs
Date: Thu, 21 Sep 2000 17:28:03 +0000 (GMT)
From: James Undery 
To: sip@lists.bell-labs.com
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: [SIP] More problems with SRV
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com

Hi,
	It has just been suggested to me SRV must be mandatory or
otherwise it's useless. The problem arises when a proxy running on a port
other than 5060 is referred to in a Request URI. 

In my example a proxy is pointed to by SRV records it has two options
when providing its URI for use by others;

Firstly it can assume SRV records are going to be used and not give the
port, this is obviously flawed as not every one uses SRV records.

Secondly it can provide the port to use, in this case the other proxy
SHOULD use A or AAAA records negating the SRV records.

This means that for proxys not listening on 5060 SRV won't be used. As
using SRV requires the port to be 5060 it's only going to provide load
balancing, we have a more flexible load balancing system that can use a
single IP address, what advantage does SRV offer? (I've ignored the
fallover as this is solved also by having multiple IP addresses in the
A/AAAA record.)

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  Thu Sep 21 13:33: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 NAA10656
	for ; Thu, 21 Sep 2000 13:33: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 E9AF844338; Thu, 21 Sep 2000 12:33:32 -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 9F2D444380
	for ; Thu, 21 Sep 2000 11:47:04 -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 MAA23784;
	Thu, 21 Sep 2000 12:43:03 -0400 (EDT)
Message-ID: <39CA3A97.F21209FC@cs.columbia.edu>
Date: Thu, 21 Sep 2000 12:43:03 -0400
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
Subject: Re: [SIP] More problems with SRV
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-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

James Undery wrote:
> 
> Hi,
>         It has just been suggested to me SRV must be mandatory or
> otherwise it's useless. The problem arises when a proxy running on a port
> other than 5060 is referred to in a Request URI.
> 
> In my example a proxy is pointed to by SRV records it has two options
> when providing its URI for use by others;
> 
> Firstly it can assume SRV records are going to be used and not give the
> port, this is obviously flawed as not every one uses SRV records.
> 
> Secondly it can provide the port to use, in this case the other proxy
> SHOULD use A or AAAA records negating the SRV records.
> 
> This means that for proxys not listening on 5060 SRV won't be used. As

Making support for SRV mandatory may not be a bad solution. However,
given the overwhelming fraction of web servers that run on port 80, I
can't see a reason why somebody would put a production SIP server on a
port other than 5060. (And most of the non-port-80 web servers use
another port just because they can't use a reserved port; that problem
doesn't apply for SIP.) You don't want to have a business card that says

sip:jundery@ubiquity.net:48783

Somebody might think you never graduated from Compuserve...


> using SRV requires the port to be 5060 it's only going to provide load
> balancing, we have a more flexible load balancing system that can use a
> single IP address, what advantage does SRV offer? (I've ignored the
> fallover as this is solved also by having multiple IP addresses in the
> A/AAAA record.)
> 
> James Undery
> 
> _______________________________________________
> 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  Thu Sep 21 17:48: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 RAA14996
	for ; Thu, 21 Sep 2000 17:48: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 89A3C44370; Thu, 21 Sep 2000 16:47:58 -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 C1A5A44338
	for ; Thu, 21 Sep 2000 16:47: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 ;
 Thu, 21 Sep 2000 14:45:52 -0700
From: "Simon Barber" 
To: 
Cc: "'Sip@Lists. Bell-Labs. Com'" 
Subject: RE: [SIP] Outbound call routing
Date: Thu, 21 Sep 2000 14:49:06 -0700
Message-ID: 
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----=_NextPart_000_0184_01C023DB.17A1BEE0"
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: <39C63AD6.E411F47B@ipdialog.com>
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com

This is a multi-part message in MIME format.

------=_NextPart_000_0184_01C023DB.17A1BEE0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

I'm not quite sure if this is what you mean, but I do see a possible
solution to the problem:

Currently SIP has a mechanism for routing outbound requests via a local
proxy - to solve the problem of routing through firewalls, or other network
partitions. This is either a manually configured outbound proxy (just like
HTTP requests, or first hop SMTP) or configured via DHCP.

This first local hop must be maintained.

When a SIP message is first sent out from a UAC the requestURI could be set
to the contents of the DNS SRV record "sipoutbound". When the INVITE reaches
the user's outbound server, then the request URI would be set to the
contents of the to: header. This assumes that the UA always wants the
request routed to the to: header. Is this always true? This also changes the
handling of the to: header. It is now not interpreted by the proxy servers
between the terminal and the user's outbound server. This means that local
semantics will not be applied. I guess sometimes this is good, sometimes
bad!

The closest system in the real world to current SIP outbound routing is
outbound routing of calls from a roaming GSM subscriber. This routing has
been a big barrier to deployment of roaming pre-pay on GSM, since outbound
calls are routed out without the knowledge of the user's home network, it is
not possible to control outbound calling according to a billing function.
One aspect that is both an advantage and a disadvantage is that the number
dialled is interpreted in the local network, hence local numbers can be
dialled without codes. It does mean, however that the user's numbers from
their home network (recorded in their phone book) are wrong, and the user
must apply some codes to dial. Of course this is probably irrelevant for the
future vision of SIP, where the identifier is the same as an e-mail address
and globally significant. Interpretation of tel: urls remains an open
question though.

Using the SRV record has the advantage that the UA does not need to be
registered before outbound calling will work correctly. I see this
decoupling of outbound and inbound calling as an important advantage.

Simon


-----Original Message-----
From: hch@ipdialog.com [mailto:hch@ipdialog.com]
Sent: Monday, September 18, 2000 8:55 AM
To: Simon Barber
Cc: 'Sip@Lists. Bell-Labs. Com'
Subject: Re: [SIP] Outbound call routing


I won't speak for the second part, but the first part could probably be
addressed with a new DNS SRV record, say "sipoutbound". The roaming user
would
do a SRV lookup on his new, DHCP-derived local domain, and if "sipoutbound"
exists, use that as the first hop.

Howard Hart
ipDialog, Inc.

Simon Barber wrote:

> I'm asking for a bit more than that.
>
> The big problem is that the user may be roaming away from his home
network,
> and be logged in to a SIP phone not only outside of the firewall of his
home
> network, but also behind the firewall of a foreign network. Because of
this
> second firewall all SIP requests have to be routed through the local SIP
> proxy to get to the outside world. However the user would also like his
> requests to be routed through a proxy server from his home domain - so his
> services can be provided. This requires that the SIP request have some
> routing at the SIP protocol layer, not just the internetwork layer.
>
> More simply - any of the user's home proxy servers may not be directly
> reachable from the client, if the user is behind a foreign firewall. Hence
> simply passing an IP address back in the register reply that the client
> should send future requests to is not sufficient. We must provide a
> mechanism whereby the SIP network can transport the requests to a server
in
> the user's home domain.
>
> Simon
>
> -----Original Message-----
> From: Wayne Cutler [mailto:Wayne.Cutler@marconi.com]
> Sent: Friday, September 15, 2000 2:09 AM
> To: Jonathan Rosenberg
> Cc: 'Simon Barber'; 'sip
> Subject: RE: [SIP] Outbound call routing
>
> I believe that what Simon is asking for (please shout up if I'm
> misrepresenting
> you)  is the abiltiy for the registrar/proxy to be able to explicitly
assign
> an
> address to be used by the SIP user for all future requests during this
> registration.
>
> An analogue would be the h323 GK scenario where there may be a well know
RAS
> (h323 registration) address which may be used by a h323 user to register
> with
> his "home" GK. For a succesful registration, the response provides a
> completely
> separate address to be used for h225 (call) signalling. The allocation of
> the
> h225 address is subject to local policy in the GK - e.g. the GK may be
> composed
> of several physical platforms and the allocation may be done on the basis
of
> dynamicaly sharing work/load amongst the platforms and therefore
> avoiding/minimising pre-provisioning.
>
> In the SIP case, there doesn't seem to be a way (at least not one that's
> explicitly stated) for a Registrar to accept a registration request and
tell
> the
> recipient an address that the registrar/proxy requires to be used for all
> future
> requests. Such a capability would be useful, I believe.
>
> Regards, Wayne.


------=_NextPart_000_0184_01C023DB.17A1BEE0
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_0184_01C023DB.17A1BEE0--



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


From sip-admin@lists.bell-labs.com  Fri Sep 22 02:11: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 CAA03186
	for ; Fri, 22 Sep 2000 02:11: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 8DCFA44351; Fri, 22 Sep 2000 01:11:16 -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 B895244338
	for ; Fri, 22 Sep 2000 01:11: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 e8M6B4Z19090;
	Fri, 22 Sep 2000 08:11:05 +0200 (MEST)
Received: from ericsson.fi (E0080C7FA22D6.lmf.ericsson.se [131.160.30.48])
	by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id JAA14824;
	Fri, 22 Sep 2000 09:11:03 +0300 (EET DST)
Message-ID: <39CAF7F1.A77622D4@ericsson.fi>
Date: Fri, 22 Sep 2000 09:10:57 +0300
From: Hisham Khartabil 
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Simon Barber 
Cc: hch@ipdialog.com, "'Sip@Lists. Bell-Labs. Com'" 
Subject: Re: [SIP] Outbound call routing
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-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit



Simon Barber wrote:

> I'm not quite sure if this is what you mean, but I do see a possible
> solution to the problem:
>
> Currently SIP has a mechanism for routing outbound requests via a local
> proxy - to solve the problem of routing through firewalls, or other network
> partitions. This is either a manually configured outbound proxy (just like
> HTTP requests, or first hop SMTP) or configured via DHCP.
>
> This first local hop must be maintained.
>
> When a SIP message is first sent out from a UAC the requestURI could be set
> to the contents of the DNS SRV record "sipoutbound". When the INVITE reaches
> the user's outbound server, then the request URI would be set to the
> contents of the to: header. This assumes that the UA always wants the
> request routed to the to: header. Is this always true? This also changes the
> handling of the to: header. It is now not interpreted by the proxy servers
> between the terminal and the user's outbound server. This means that local
> semantics will not be applied. I guess sometimes this is good, sometimes
> bad!

This is not quite right,  the UAC sets the request-uri to the address of the UAS
(which, in most cases, is the same as the URI in the to: header) and not the
out-bound proxy. The UAC is configured to send the request to that proxy.  The
out-bound proxy then performs the SRV lookup etc.  according to the request-uri
to find the UAS and routes the request.

regards,
Hisham



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


From sip-admin@lists.bell-labs.com  Fri Sep 22 04:19: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 EAA04048
	for ; Fri, 22 Sep 2000 04:19: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 B17B344370; Fri, 22 Sep 2000 03:19:39 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72])
	by lists.bell-labs.com (Postfix) with ESMTP id 1B42544338
	for ; Fri, 22 Sep 2000 03:19:29 -0400 (EDT)
Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef)
	id JAA09839; Fri, 22 Sep 2000 09:17:23 +0100 (BST)
Message-ID: <39CB1595.700EB65F@ubiquity.net>
Date: Fri, 22 Sep 2000 09:17:25 +0100
From: James Undery 
X-Mailer: Mozilla 4.73 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Henning Schulzrinne 
Cc: sip@lists.bell-labs.com
Subject: Re: [SIP] More problems with SRV
References:  <39CA3A97.F21209FC@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-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit



Henning Schulzrinne wrote:

> James Undery wrote:

>
> >         It has just been suggested to me SRV must be mandatory or
> > otherwise it's useless. The problem arises when a proxy running on a port
> > other than 5060 is referred to in a Request URI.
>

[snip]

>
> Making support for SRV mandatory may not be a bad solution. However,
> given the overwhelming fraction of web servers that run on port 80, I
> can't see a reason why somebody would put a production SIP server on a
> port other than 5060. (And most of the non-port-80 web servers use
> another port just because they can't use a reserved port; that problem
> doesn't apply for SIP.) You don't want to have a business card that says
>
> sip:jundery@ubiquity.net:48783
>
> Somebody might think you never graduated from Compuserve...

Yes agreed it is rare but as I said the problem is in proxies so my address
would be sip:james@ubiquity.net, however, sip.magic-service.ubiquity.net may
want to add itself to the record route and this is where the problem occurs.
(Especially as in small office environments I can see the potential for
multiple sip servers to be running on one machine, e.g. outbound proxy and some
specialised service proxy.)

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  Fri Sep 22 05:33: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 FAA04500
	for ; Fri, 22 Sep 2000 05:33: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 64FDB44370; Fri, 22 Sep 2000 04:33:25 -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 C1AFE44338
	for ; Fri, 22 Sep 2000 04:33:17 -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 e8M9XCZ03994;
	Fri, 22 Sep 2000 11:33:12 +0200 (MEST)
Received: from ericsson.fi (E0080C7FA22D6.lmf.ericsson.se [131.160.30.48])
	by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id MAA29498;
	Fri, 22 Sep 2000 12:33:12 +0300 (EET DST)
Message-ID: <39CB2751.A1FC1C3@ericsson.fi>
Date: Fri, 22 Sep 2000 12:33:05 +0300
From: Hisham Khartabil 
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: James Undery 
Cc: Henning Schulzrinne , sip@lists.bell-labs.com
Subject: Re: [SIP] More problems with SRV
References:  <39CA3A97.F21209FC@cs.columbia.edu> <39CB1595.700EB65F@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-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit



James Undery wrote:

> Henning Schulzrinne wrote:
>
> > James Undery wrote:
>
> >
> > >         It has just been suggested to me SRV must be mandatory or
> > > otherwise it's useless. The problem arises when a proxy running on a port
> > > other than 5060 is referred to in a Request URI.
> >
>
> [snip]
>
> >
> > Making support for SRV mandatory may not be a bad solution. However,
> > given the overwhelming fraction of web servers that run on port 80, I
> > can't see a reason why somebody would put a production SIP server on a
> > port other than 5060. (And most of the non-port-80 web servers use
> > another port just because they can't use a reserved port; that problem
> > doesn't apply for SIP.) You don't want to have a business card that says
> >
> > sip:jundery@ubiquity.net:48783
> >
> > Somebody might think you never graduated from Compuserve...
>
> Yes agreed it is rare but as I said the problem is in proxies so my address
> would be sip:james@ubiquity.net, however, sip.magic-service.ubiquity.net may
> want to add itself to the record route and this is where the problem occurs.
> (Especially as in small office environments I can see the potential for
> multiple sip servers to be running on one machine, e.g. outbound proxy and some
> specialised service proxy.)

I would think that if you know the port number of a proxy, then you would know its
exact location or host (you find out the exact same way you found the port
number).  If all you know about the proxy is that it is at ubiquity.net, then you
do an SRV record lookup on that.

when a proxy wants to add itself in the record-route, then it puts its exact
location and port, not the key to use for SRV records.  I don't think you are
supposed to do SRV lookups on a route header, all you do is route using a normal
DNS A query.

Regards,
Hisham



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


From sip-admin@lists.bell-labs.com  Fri Sep 22 06:13: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 GAA04785
	for ; Fri, 22 Sep 2000 06: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 21E7444370; Fri, 22 Sep 2000 05:12:42 -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 C8A6444338
	for ; Fri, 22 Sep 2000 05:12:39 -0400 (EDT)
Received: from cvis01.gpt.co.uk (unverified) by cvis29.marconicomms.com
 (Content Technologies SMTPRS 4.1.5) with ESMTP id ;
 Fri, 22 Sep 2000 11:12:30 +0100
Received: from marconicomms.com by cvis01.gpt.co.uk with SMTP
 (8.8.8+Sun/cvms-28) id LAA09380; Fri, 22 Sep 2000 11:12:31 +0100 (BST)
Received: by marconicomms.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id 80256962.00380287 ; Fri, 22 Sep 2000 11:11:46 +0100
X-Lotus-FromDomain: MCMAIN@MCEXT
From: "Wayne Cutler" 
To: Henning Schulzrinne 
Cc: sip@lists.bell-labs.com
Message-ID: <80256962.0037DF9C.00@marconicomms.com>
Date: Fri, 22 Sep 2000 11:10:09 +0100
Subject: Re: [SIP] Outbound call routing
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-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com



Henning Schulzrinne wrote :-
>Forcing routing seems yet another user configuration parameter, along
>with other service parameters that I'd like to keep even as I change
>terminals. Thus, this is probably best addressed as user configuration
>data downloaded from the REGISTER server, along with things like
>speed-dial buttons or, say, CFB/CFNA end system behavior. If we define
>an extension of CPL that's tailored to user agents, this might be a
>useful feature to have, as one may want to make this feature
>conditional.

This just feels like a misuse of CPL. CPL is about describing internet telephony
features whereas
what is being proposed is a mechanism by which the Registrar can mandate an
address/hostname
to be used for future requests. SIP has a number of headers which are used to
influence/mandate future
routing of requests/responses. Isn't this just another example of a header that
influences message routing?
I believe that there  should be an explicit  mechanism in the registration
response (e.g. a new header?) to
enable this functionality.

Regards, Wayne.






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


From sip-admin@lists.bell-labs.com  Fri Sep 22 06: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 GAA04901
	for ; Fri, 22 Sep 2000 06:41: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 CDE2144386; Fri, 22 Sep 2000 05:40:33 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72])
	by lists.bell-labs.com (Postfix) with ESMTP id B03DF44338
	for ; Fri, 22 Sep 2000 05:40:26 -0400 (EDT)
Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef)
	id LAA24547; Fri, 22 Sep 2000 11:34:39 +0100 (BST)
From: "Jo Hornsby" 
To: "Simon Barber" , 
Cc: "'Sip@Lists. Bell-Labs. Com'" 
Subject: RE: [SIP] Outbound call routing
Date: Fri, 22 Sep 2000 11:34:39 +0100
Message-ID: <001f01c02480$b64ae7b0$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-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

> Currently SIP has a mechanism for routing outbound requests via a
> local proxy - to solve the problem of routing through firewalls, or
> other network partitions. This is either a manually configured
> outbound proxy (just like HTTP requests, or first hop SMTP) or
> configured via DHCP.
> 
> This first local hop must be maintained.
> 
> When a SIP message is first sent out from a UAC the requestURI could
> be set to the contents of the DNS SRV record "sipoutbound". When the
> INVITE reaches the user's outbound server, then the request URI
> would be set to the contents of the to: header. This assumes that
> the UA always wants the request routed to the to: header. Is this
> always true?

I would say very likely to be true, for an initial INVITE.  I
would stay away from "always", however. &:)

> This also changes the handling of the to: header. It is
> now not interpreted by the proxy servers between the terminal and
> the user's outbound server. This means that local semantics will not
> be applied. I guess sometimes this is good, sometimes bad!

This is slightly problematic; how does a proxy know that it is
supposed to be interpreting the To: instead of the Request-URI?
Although I guess it's only the first proxy (the "home" proxy?)
after the firewall prox(y|ies) that needs to know that To is
overriding.  Hmmm...

[...]
> Using the SRV record has the advantage that the UA does not need to
> be registered before outbound calling will work correctly. I see
> this decoupling of outbound and inbound calling as an important
> advantage.

Using the SRV record also has the disadvantage that someone has to
be responsible for configuring the record for a user's address,
and since the granularity is at a domain level, this isn't that
flexible (I might like to have my own "outbound" proxy, that I'd
written with my own funky features, for instance).

The notion of using source routing mentioned earlier in this
thread, by embedding a Route header, as Anders and Sean suggested,
would seem to solve all of these problems, and it reuses existing
syntax quite nicely.  Plus -- as Sean pointed out -- it generalises
to multiple proxies; not to mention the possibilities with implying
other headers (State perhaps?).

Do you forsee any problems with this approach?

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 Sep 22 07:08: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 HAA05478
	for ; Fri, 22 Sep 2000 07:08: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 261CC44386; Fri, 22 Sep 2000 06:07:57 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72])
	by lists.bell-labs.com (Postfix) with ESMTP id F2EEB44338
	for ; Fri, 22 Sep 2000 06:07:52 -0400 (EDT)
Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef)
	id MAA04377; Fri, 22 Sep 2000 12:06:04 +0100 (BST)
From: "Jo Hornsby" 
To: "Hisham Khartabil" ,
        "James Undery" 
Cc: "Henning Schulzrinne" ,
        
Subject: RE: [SIP] More problems with SRV
Date: Fri, 22 Sep 2000 12:06:03 +0100
Message-ID: <002001c02485$19012690$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: <39CB2751.A1FC1C3@ericsson.fi>
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

> when a proxy wants to add itself in the record-route, then it 
> puts its exact location and port, not the key to use for SRV
> records.  I don't think you are supposed to do SRV lookups on
> a route header, all you do is route using a normal DNS A query.

This is incorrect.  Since Route values are effectively popped into
the Request-URI, a proxy would typically follow the normal 1.4.2
procedures for the next hop; thus SRV SHOULD be utilised unless
the maddr contains an IP, or the port is specified and is not 5060.

In some ways, I would agree that putting an IP into the maddr
is the best approach, but SRV can then no-longer be used to
load-balance, or what-have-you, for the requests in some Call
Leg.  Maybe this isn't a problem -- I don't know -- but what is
problematic is assuming that SRV _will_ work.  I can accept the
idea that 99% of proxies are going to run on 5060 (maybe this
should be pointed out?), but that's not the end of the story:
_sip._udp.example.com has A records, but example.com does not...

Looking at the 5th Bake-Off Statistics, I note that only 12
implementations (UAs, proxies, whatever) reckoned they could do
SRV.  This is out of over 50 implementations!  I find this
worrying.

In any case, it would be nice for the 6th Bake-Off if attendees
could have their own domains -- we could "create" a new TLD to
prevent collisions with their "real" domains -- then it would
be possible (given a suitable version of BIND running locally)
to really test this.

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 Sep 22 10:11: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 KAA14549
	for ; Fri, 22 Sep 2000 10:11:53 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id E18754438E; Fri, 22 Sep 2000 09:11:31 -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 4FA4C44338
	for ; Fri, 22 Sep 2000 09:11:28 -0400 (EDT)
Received: from mailhost.ubiquity.net by drago1.ubiquity.net
          via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 22 Sep 2000 14:11:45 UT
Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef)
	id PAA08387; Fri, 22 Sep 2000 15:09:39 +0100 (BST)
From: "Jo Hornsby" 
To: 
Cc: 
Date: Fri, 22 Sep 2000 15:09:38 +0100
Message-ID: <002301c0249e$be705740$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: <200009221254.NAA27665@fm381.facility.pipex.com>
Subject: [SIP] RE: [Test Bed Technical Forum:] Determining the length of the SIP message body
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

This question is more appropriate on the SIP List; Cc:d.

>  MESSAGE:  (#45) Determining the length of the SIP message body 
>           
>  
>  AUTHOR:   Duke Snyder 
>  DATE:     Friday, 22 September 2000, at 1:54 p.m. 
>
> If there is a content-length header then no problem - but the 
> content-length header is optional (according to the rfc in
> section 6.17).

This is true -- Content-Length is indeed specified as optional
in the RFC; however, the bis02 draft, which trackes current
state of the art, makes it mandatory.

> If no content-length header, how do the servers determine if 
> there is a body: 
> 1. There is a body if there is a content-type header - is this true? 

Although it would be odd for there to be a Content-Type header
and no body, I don't see this technically illegal (especially
if Content-Length was specified as 0).  I wouldn't rely on
Content-Type to imply the presence or otherwise of a body.

> If no content-length header and there is a body, how do you determine
> its length? 
> 1. The body goes to the end of the udp packet - is this true?. 

Yes.

> 2. The body goes to the first CRLF after decoding - but the rfc does
> not mention a CRLF after the message body. 

No, since it is perfectly legal to have one or more CRLFs in a
body (think SDP).

> 3. The content-length field must be used if tcp - is this true? 

Yes, well, it's true pretty much universally true nowadays.
(There is some leniency towards Content-Length in responses;
this is to make stuff like SIP CGI easier, for instance.)

See Table 4 and Section 6.19 of bis02 (available from Henning's
site) for the definitive rules.

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 Sep 22 15:58: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 PAA25752
	for ; Fri, 22 Sep 2000 15:58: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 6E49E44380; Fri, 22 Sep 2000 14:58:36 -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 7544B44338
	for ; Fri, 22 Sep 2000 14:58:32 -0400 (EDT)
Received: from ind.cs.columbia.edu (ind.cs.columbia.edu [128.59.19.27])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id PAA19305;
	Fri, 22 Sep 2000 15:58:02 -0400 (EDT)
Received: (from lennox@localhost)
	by ind.cs.columbia.edu (8.9.3/8.9.3) id PAA27357;
	Fri, 22 Sep 2000 15:57:58 -0400 (EDT)
From: Jonathan Lennox 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14795.47557.713284.85520@ind.cs.columbia.edu>
Date: Fri, 22 Sep 2000 15:57:57 -0400 (EDT)
To: "Jo Hornsby" 
Cc: "Simon Barber" , ,
        "'Sip@Lists. Bell-Labs. Com'" 
Subject: RE: [SIP] Outbound call routing
In-Reply-To: <001f01c02480$b64ae7b0$4e34c3c1@ubiquity.co.uk>
References: 
	<001f01c02480$b64ae7b0$4e34c3c1@ubiquity.co.uk>
X-Mailer: VM 6.75 under Emacs 19.34.1
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

On Friday, September 22 2000, "Jo Hornsby" wrote to "Simon Barber, , 'Sip@Lists. Bell-Labs. Com'" saying:

> > Currently SIP has a mechanism for routing outbound requests via a
> > local proxy - to solve the problem of routing through firewalls, or
> > other network partitions. This is either a manually configured
> > outbound proxy (just like HTTP requests, or first hop SMTP) or
> > configured via DHCP.
> > 
> > This first local hop must be maintained.
> > 
> > When a SIP message is first sent out from a UAC the requestURI could
> > be set to the contents of the DNS SRV record "sipoutbound". When the
> > INVITE reaches the user's outbound server, then the request URI
> > would be set to the contents of the to: header. This assumes that
> > the UA always wants the request routed to the to: header. Is this
> > always true?

I have a suggestion here: use the 'maddr' parameter of the Request-URI.
I.e. to the local proxy server, I send a request with the Request-URI
'sip:friend@destination.example;maddr=outbound-services.home-isp.example'.
The local proxy server does whatever magic it needs to do, and then sends
the request, with the URI 'sip:friend@destination.example', to the machine
'outbound-services.home-isp.example'.

How that maddr is provisioned is a separate issue; it could be statically
configured in the UA, or specified in the registration response like Henning
suggested.

I believe that under a strict reading of 2543bis this is already the defined
behavior of proxy servers, but it could be made a lot more explicit.  I
don't think there are currently any examples with an maddr in a Request-URI.

One thing to note is that the 'From' header of the outgoing request needs to
be correct (and, probably, authenticated) in order for the
'outbound-services' machine to be able to tell whose services to apply.
This means that the UA can't proxy other people's calls and expect to
receive its outbound services, but I don't think that's a huge restriction.

Note that this means that the UA can always choose *not* to use the
outbound-services server as a proxy, by not including an maddr parameter.
So you can't use this for billing and the like.  This is true in general in
an IP environment, though -- users see administrative restrictions as
damage, and route around them.

-- 
Jonathan Lennox
lennox@cs.columbia.edu


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


From sip-admin@lists.bell-labs.com  Fri Sep 22 17:06: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 RAA26479
	for ; Fri, 22 Sep 2000 17: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 E99F24439C; Fri, 22 Sep 2000 16:06:28 -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 5874544338
	for ; Fri, 22 Sep 2000 16:06:25 -0400 (EDT)
Received: from dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id RAA17103
	for ; Fri, 22 Sep 2000 17:08:21 -0400 (EDT)
Message-ID: <39CBCA33.4B1B63D0@dynamicsoft.com>
Date: Fri, 22 Sep 2000 17:08:03 -0400
From: Igor Slepchin 
Organization: dynamicsoft Inc.
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en,ru
MIME-Version: 1.0
Cc: sip@lists.bell-labs.com
Subject: Re: [SIP] More problems with SRV
References:  <39CA3A97.F21209FC@cs.columbia.edu> <39CB1595.700EB65F@ubiquity.net>
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

James Undery wrote:
> 
> (Especially as in small office environments I can see the potential for
> multiple sip servers to be running on one machine, e.g. outbound proxy and some
> specialised service proxy.)

What's the point of using SRV then? There is nothing to load balance
across...

In general, a proxy Record-Routes only if it wants to store some state
throughout the call. Doing load balancing for consecutive signaling
means that the state has to be shared. This is possible but I see little
reason for having those load balanced proxies not to run on 5060, given
that all ports (above 1024) are created equal and it's very unlikely
that one would want to run multiple instances of a SIP proxy on a
machine that's so overloaded or mission critical as to warrant state
sharing.

---
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  Fri Sep 22 20:47: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 UAA29372
	for ; Fri, 22 Sep 2000 20:47: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 95B904439C; Fri, 22 Sep 2000 19:47:12 -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 DF87544338
	for ; Fri, 22 Sep 2000 19:47: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 ;
 Fri, 22 Sep 2000 17:45:06 -0700
From: "Simon Barber" 
To: "Jo Hornsby" , 
Cc: "'Sip@Lists. Bell-Labs. Com'" 
Subject: RE: [SIP] Outbound call routing
Date: Fri, 22 Sep 2000 17:48:23 -0700
Message-ID: 
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----=_NextPart_000_01EF_01C024BD.4DE5F970"
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: <001f01c02480$b64ae7b0$4e34c3c1@ubiquity.co.uk>
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com

This is a multi-part message in MIME format.

------=_NextPart_000_01EF_01C024BD.4DE5F970
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

> > When a SIP message is first sent out from a UAC the requestURI could
> > be set to the contents of the DNS SRV record "sipoutbound". When the
> > INVITE reaches the user's outbound server, then the request URI
> > would be set to the contents of the to: header. This assumes that
> > the UA always wants the request routed to the to: header. Is this
> > always true?
>
> I would say very likely to be true, for an initial INVITE.  I
> would stay away from "always", however. &:)

A valid argument. We should maintain the ability of the UAC to set
the requestURI of the invite to whatever it wants.

>
> > This also changes the handling of the to: header. It is
> > now not interpreted by the proxy servers between the terminal and
> > the user's outbound server. This means that local semantics will not
> > be applied. I guess sometimes this is good, sometimes bad!
>
> This is slightly problematic; how does a proxy know that it is
> supposed to be interpreting the To: instead of the Request-URI?
> Although I guess it's only the first proxy (the "home" proxy?)
> after the firewall prox(y|ies) that needs to know that To is
> overriding.  Hmmm...
>
> [...]
> > Using the SRV record has the advantage that the UA does not need to
> > be registered before outbound calling will work correctly. I see
> > this decoupling of outbound and inbound calling as an important
> > advantage.
>
> Using the SRV record also has the disadvantage that someone has to
> be responsible for configuring the record for a user's address,
> and since the granularity is at a domain level, this isn't that
> flexible (I might like to have my own "outbound" proxy, that I'd
> written with my own funky features, for instance).

Hisham - Apologies, I have misunderstood your meaning for outbound server.
By outbound server I mean a server that is part of my domain, that all my
outbound requests will pass though (whether I am originating those requests
from part of the network within my domain or not).

I would suggest the sipoutbound SRV record is domain wide, not user
specific - just like the SIP SRV record for incoming calls. If you
want to use a specific server for your particular user, then you
should have the server that handles the domain direct the request to
a server that handles your particular user.

Using a domain wide SRV record means that it's all or nothing for that
domain, of course. This forces outbound requests to be routed like this for
all users. Using the response to REGISTER means this is configurable on a
user by user basis, but it does require the user be registered.

>
> The notion of using source routing mentioned earlier in this
> thread, by embedding a Route header, as Anders and Sean suggested,
> would seem to solve all of these problems, and it reuses existing
> syntax quite nicely.  Plus -- as Sean pointed out -- it generalises
> to multiple proxies; not to mention the possibilities with implying
> other headers (State perhaps?).
>

Route does seem to be a neat solution. Excuse my ignorance, but why does it
have to be embedded in the requestURI?

Indeed I am not sure that we even need a separate SRV record for
outbound and inbound calls at all. Why not simply say that a Route:
header for initial requests should be set to the sip URL for the
user making the request (normally also the contents of the From:
header.).

This way all outbound requests pass through the same server that
handles the user's inbound calls. This should be completely compatible
with current procedures. It does tie the server which handles services
for outbound calls to the same server that handles services for inbound
calls, but is this a problem?

This also means that this form of outbound routing is used for all SIP
requests, irrespective of whether this is required for services or not.

In summary, 3 approaches:

1) configuration using REGISTER
- outbound routing can be controlled on a per specific registration basis

2) configuration using SRV record
- outbound routing can be controlled on a per domain basis

3) always route through user's home server
- no option not to route through user's home server

or

4) other method?



> Do you forsee any problems with this approach?

Seems very sensible!

>
> Cheers,
>
>
>  - Jo.

------=_NextPart_000_01EF_01C024BD.4DE5F970
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_01EF_01C024BD.4DE5F970--



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


From sip-admin@lists.bell-labs.com  Sat Sep 23 01:08: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 BAA06155
	for ; Sat, 23 Sep 2000 01:08: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 39AC244340; Sat, 23 Sep 2000 00:08:24 -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 53BB5443A0
	for ; Fri, 22 Sep 2000 20:10:04 -0400 (EDT)
Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Fri Sep 22 21:09:09 EDT 2000
Received: by lists.bell-labs.com (Postfix)
	id F3B4C4437D; Fri, 22 Sep 2000 20:56:00 -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 C5FED44341
	for ; Fri, 22 Sep 2000 20:55:59 -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 UAA20431;
	Fri, 22 Sep 2000 20:55:58 -0400 (EDT)
Message-ID: <39CBFF9F.FB8F0446@cs.columbia.edu>
Date: Fri, 22 Sep 2000 20:55:59 -0400
From: Henning Schulzrinne 
X-Mailer: Mozilla 4.05 [en] (WinNT; U)
MIME-Version: 1.0
To: Jonathan Lennox 
Cc: Jo Hornsby , Simon Barber ,
        hch@ipdialog.com,
        "'Sip@Lists. Bell-Labs. Com'" 
Subject: Re: [SIP] Outbound call routing
References: 
		<001f01c02480$b64ae7b0$4e34c3c1@ubiquity.co.uk> <14795.47557.713284.85520@ind.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-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

> 
> I have a suggestion here: use the 'maddr' parameter of the Request-URI.
> I.e. to the local proxy server, I send a request with the Request-URI
> 'sip:friend@destination.example;maddr=outbound-services.home-isp.example'.

> I believe that under a strict reading of 2543bis this is already the defined
> behavior of proxy servers, but it could be made a lot more explicit. 

It already says that 'maddr overrides the host port' in the URL
description and in the first bullet item for the introduction.



 I
> don't think there are currently any examples with an maddr in a Request-URI.

Given that this is a somewhat specialized case, this probably belongs in
the call-flows document.

---

This approach has one subtle problem. The maddr parameter can't specify
a port number, so that if the destination URL has a non-5060 port number
(or the home proxy has a non-5060 port), things don't work right.

Henning



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


From sip-admin@lists.bell-labs.com  Sun Sep 24 17:46: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 RAA10777
	for ; Sun, 24 Sep 2000 17:46:53 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id D541844337; Sun, 24 Sep 2000 16:46:51 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from granger.mail.mindspring.net (granger.mail.mindspring.net [207.69.200.148])
	by lists.bell-labs.com (Postfix) with ESMTP id A8D3E44336
	for ; Sun, 24 Sep 2000 16:46:47 -0400 (EDT)
Received: from gamma (user-1054j4b.biz.mindspring.com [64.82.76.139])
	by granger.mail.mindspring.net (8.9.3/8.8.5) with SMTP id RAA08922
	for ; Sun, 24 Sep 2000 17:46:34 -0400 (EDT)
Reply-To: 
From: "Raja Sekhar" 
To: 
Date: Sun, 24 Sep 2000 17:43:44 -0400
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.00.2615.200
Subject: [SIP] reg Proxy authorization and authentication
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

Hai
 Please any body calrify me  the problem I faced with  the authorization
header and authentication header
In my UAC code  I am adding the Proxy authoirization header  to   the
register request consists

But still I am getting the 407 proxy authentication required . I am using
the type DIGEST and relam and user name pawd of my service provider

1.Is it any sequence where the porxy authorization  header to be added   in
the register message . Is it any document availble for the order of the
header in the request message .
rajasekhar -voicecore



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


From sip-admin@lists.bell-labs.com  Sun Sep 24 22:42: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 WAA14009
	for ; Sun, 24 Sep 2000 22:42: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 8C27344346; Sun, 24 Sep 2000 21:42:34 -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 8CFAA44336
	for ; Sun, 24 Sep 2000 21:42:31 -0400 (EDT)
Received: from eagle (1Cust6.tnt3.freehold.nj.da.uu.net [63.25.172.6])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with SMTP id WAA01584;
	Sun, 24 Sep 2000 22:44:12 -0400 (EDT)
From: "Jonathan Rosenberg" 
To: , 
Subject: RE: [SIP] reg Proxy authorization and authentication
Date: Sun, 24 Sep 2000 22:43:06 -0400
Message-ID: <000201c0269a$55f1c160$6427fea9@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
In-Reply-To: 
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit




> -----Original Message-----
> From: Raja Sekhar [mailto:rpasumarty@voicecore.com]
> Sent: Sunday, September 24, 2000 5:44 PM
> To: SIP@lists.bell-labs.com
> Subject: [SIP] reg Proxy authorization and authentication
>
>
> Hai
>  Please any body calrify me  the problem I faced with  the
> authorization
> header and authentication header
> In my UAC code  I am adding the Proxy authoirization header  to   the
> register request consists
>
> But still I am getting the 407 proxy authentication required
> . I am using
> the type DIGEST and relam and user name pawd of my service provider
>
> 1.Is it any sequence where the porxy authorization  header to
> be added   in
> the register message . Is it any document availble for the
> order of the
> header in the request message .
> rajasekhar -voicecore

Ordering of headers in requests is not important, unless requests are being
signed using PGP. Since thats not the case here, it doesn't matter.

I would recommend you check the call flows draft:
http://www.ietf.org/internet-drafts/draft-ietf-sip-call-flows-01.txt

which has examples for e2e authentication (401, not 407), but the message
formatting is pretty much the same.

-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 Sep 25 02:09: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 CAA27763
	for ; Mon, 25 Sep 2000 02:09: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 05A9F44346; Mon, 25 Sep 2000 01:09: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 F372644336
	for ; Mon, 25 Sep 2000 01:09: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 CAA02102;
	Mon, 25 Sep 2000 02:04:43 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id ; Mon, 25 Sep 2000 01:59:30 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: Henning Schulzrinne ,
        Jonathan Lennox 
Cc: Jo Hornsby , Simon Barber ,
        hch@ipdialog.com,
        "'Sip@Lists. Bell-Labs. Com'" 
Subject: RE: [SIP] Outbound call routing
Date: Mon, 25 Sep 2000 01:59:28 -0400
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-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com




> -----Original Message-----
> From: Henning Schulzrinne [mailto:schulzrinne@cs.columbia.edu]
> Sent: Friday, September 22, 2000 8:56 PM
> To: Jonathan Lennox
> Cc: Jo Hornsby; Simon Barber; hch@ipdialog.com; 'Sip@Lists. Bell-Labs.
> Com'
> Subject: Re: [SIP] Outbound call routing
> 
> 
> > 
> > I have a suggestion here: use the 'maddr' parameter of the 
> Request-URI.
> > I.e. to the local proxy server, I send a request with the 
> Request-URI
> > 
> 'sip:friend@destination.example;maddr=outbound-services.home-i
> sp.example'.
> 
> ---
> 
> This approach has one subtle problem. The maddr parameter 
> can't specify
> a port number, so that if the destination URL has a non-5060 
> port number
> (or the home proxy has a non-5060 port), things don't work right.
> 
> Henning

Well, there is also a not-so-subtle problem that this will cause a loop.

To summarize, we have a user agent A, local proxy PL, home proxy PH:


A----->PL----->PH

The proposal is that the request URI in the A->PL request be
sip:uas@uasdomain;maddr=PH. THus, when it arrives to PL, PL will forward it
to the URL in the request URI, arriving at PH. 

Now, PH looks at the request. The domain in the request URI (uasdomain), is
not its own, so it forwards it to the URL in the request URI. Problem is,
that will cause the request to loop back to itself.

This could be fixed by having PH basically discard the maddr parameter. Sort
of like popping the top route. I would argue, in fact, that you really
should be using the Route mechanism instead of trying to hack that mechanism
into the maddr parameter.

The Route mechanism will probably work. The primary issue is one of
configuration; how does my UA determine the Route? Thats a separate
question, and one that requires a lot of discussion. I think you would find
its application specific, and that there are numerous scenarios, each of
which is valid.

-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 Sep 25 08:58: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 IAA02194
	for ; Mon, 25 Sep 2000 08:58: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 7D6204434A; Mon, 25 Sep 2000 07:57:43 -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 6CF4D44337
	for ; Sun, 24 Sep 2000 08:46:53 -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 JAA02111
	for ; Sun, 24 Sep 2000 09:46:50 -0400 (EDT)
Message-ID: <39CE05C9.DEB256F4@cs.columbia.edu>
Date: Sun, 24 Sep 2000 09:46:50 -0400
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] The Null authentication scheme
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

Following some internal discussions, I wrote up a very short I-D on the
Null authentication scheme. Motivation is in the draft:

http://www.cs.columbia.edu/~hgs/sip/drafts/draft-schulzrinne-sip-null-00.txt

Before I submit this as an I-D, I'd like to know if this is a completely
brain-dead idea.
-- 
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 Sep 25 08:59: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 IAA02216
	for ; Mon, 25 Sep 2000 08:59: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 81C9F44355; Mon, 25 Sep 2000 07:57:56 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from mailctr.marben.fr (mailctr.marben.fr [193.105.113.5])
	by lists.bell-labs.com (Postfix) with ESMTP id 2A13644336
	for ; Mon, 25 Sep 2000 02:23:42 -0400 (EDT)
Received: from copernic.marben.fr by mailctr.marben.fr with ESMTP (8.9.3/1.2-eef)
	id IAA17051; Mon, 25 Sep 2000 08:23:51 GMT
Received: from pipo by copernic.marben.fr with SMTP (8.9.3/1.2-eef)
	id HAA08342; Mon, 25 Sep 2000 07:20:43 GMT
Message-ID: <002201c026c1$81374300$5a040237@it.atosgroup.com>
From: =?iso-8859-1?Q?G=E9rard_GONNET?= 
To: 
Cc: , "SEVESTRE Thibaut" 
Date: Mon, 25 Sep 2000 09:23:30 +0200
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_001F_01C026D2.4496E020"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2014.211
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211
Subject: [SIP] rfc 2543bis-01 SIP syntax
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com

This is a multi-part message in MIME format.

------=_NextPart_000_001F_01C026D2.4496E020
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

rfc 2543bis-01 SIP syntax revisited

Some definitions of the SIP syntax can introduce undesirable side =
effects. For exemple :

the user element is defined as *(unreserved | escaped | "&"| "=3D" | "+" =
| "$" | "," | ";" | "?" | "/" ) .
The application of the * operator tell us that a user element is =
represented as a succession of 0 (the default value) or more chars =
belonging to the enumerated set.
Giving a 0 value to the low limit of the repetition factor results in an =
"empty" user element, which is an authorized syntax.
This can introduce some trouble :
1/ what is the meaning of an "empty" user ?
2/ because the given syntax is equivalent to [user] (cf. C part of the =
draft, page 116), how to ensure the definition of a mandatory user ?

The same remark applies to the password element, defined as
password =3D  *(unreserved |escaped | "&" | "=3D" | "+" | "$" | ","), =
because the notation [":" password] of the user-info element is =
significant enough to declare password as an optional child element. =
Furthermore, this syntax could reduce the [":" password] to a lone ":" =
char only when used with an "empty" password.
=20
The same remark applies to the url-parameters element . This mandatory =
child element of the SIP-URL element can be emptied by the given =
definition :
url-parameters =3D * (";" url-parameter).

The same remark applies to the hvalue element defined as :
hvalue =3D *(hnv-unreserved | unrerserved | escaped) .
Using this definition in the header element=20
header =3D hname "=3D" hvalue
can reduce the header to a  hname "=3D"  not terminated form. (notice =
that the hname left element is declared as hname =3D 1*(hnv-unreserved | =
unrerserved | escaped) ...

To avoid side effects in the definition of an element, it seems =
mandatory to apply the following rules :

1/ a mandatory element CANNOT be defined with the *something notation, =
but MUST use the n*something notation, with n > 0.

2/ an optional element MUST be defined with the ambiguity free =
[an-optional-element] notation, by opposite to the *may-be-optional =
form.

3/ an optional element CANNOT be defined with the *may-be-optional =
notation, to avoid the possible side-effects between the two =
definitions.

Application of these rules gives :
=20
userinfo =3D (user | telephone-subscriber) [":"password]  (former =
proposition of modification)
user =3D 1*(unreserved | escaped | "&"| "=3D" | "+" | "$" | "," | ";" | =
"?" | "/" )
password =3D  1*(unreserved |escaped | "&" | "=3D" | "+" | "$" | "," )

header =3D hname "=3D" hvalue
hname =3D 1*(hnv-unreserved | unrerserved | escaped)
hvalue =3D 1*(hnv-unreserved | unrerserved | escaped)
=20
SIP-URL =3D "sip:" [userinfo "@"] hostport url-parameters [headers]
url-parameters =3D 1*(";" url-parameter).

A remark about the escaped element, declared as :
escaped =3D "%" hex hex
I cannot find a definition for hex in the ABNF specification. I suppose =
that a typographic error has occured and hex has to be translated into =
HEX, which is well defined and seems to be the right element ?

------=_NextPart_000_001F_01C026D2.4496E020
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











rfc 2543bis-01 SIP syntax=20
revisited


 


Some definitions of the SIP syntax =
can=20
introduce undesirable side effects. For=20
exemple :


 


the =
user element=20
is defined as *(unreserved | escaped | "&"| "=3D" | "+" =
| "$" |=20
"," | ";" | "?" | "/" ) .


The application of the * operator =
tell us that=20
a user element is =
represented as a=20
succession of 0 (the default value) or more chars belonging to the =
enumerated=20
set.


Giving a 0 value to the low limit =
of the=20
repetition factor results in an "empty" user element, which is an =
authorized=20
syntax.


This can introduce some trouble=20
:


1/ what is the meaning of =
an "empty"=20
user ?


2/ because the given syntax is =
equivalent=20
to [user] (cf. C part of the draft, page =
116),=20
how to ensure the definition of a =
mandatory user=20
?


 


The same remark applies to the =

password element, defined as


password =3D  *(unreserved =
|escaped |=20
"&" | "=3D" | "+" | "$" | ","), because =
the notation=20
[":" password] of the user-info=20
element is significant enough to declare =
password=20
as an optional child element. Furthermore, this =
syntax=20
could reduce the [":" password] to a lone =

":" char only when used with an "empty"=20
password.


 


The same remark applies to the=20
url-parameters element . This mandatory =
child=20
element of the SIP-URL element can be emptied =
by the=20
given definition :


url-parameters =3D * (";"=20
url-parameter).


 


The same remark applies to the=20
hvalue element defined as :


hvalue =3D *(hnv-unreserved | =
unrerserved |=20
escaped) .


Using this definition in the=20
header element 


header =3D hname "=3D"=20
hvalue


can reduce the header=20
to a  hname=20
"=3D"  not terminated =
form. (notice that the hname =
left=20
element is declared as hname =3D 1*(hnv-unreserved | =
unrerserved |=20
escaped) ...


 


To avoid side effects in the =
definition of an=20
element, it seems mandatory to apply the following rules =
:


 


1/ a mandatory=20
element CANNOT be defined with the =
*something=20
notation, but MUST use the =
n*something=20
notation, with n > 0.


 


2/ an optional element =
MUST be=20
defined with the ambiguity free=20
[an-optional-element] notation, by =
opposite to=20
the *may-be-optional form.


 


3/ an optional=20
element CANNOT be defined with the =
*may-be-optional=20
notation, to avoid the possible side-effects between the two=20
definitions.


 


Application of these rules gives=20
:


 


userinfo =3D (user | =
telephone-subscriber)=20
[":"password]  (former proposition of =
modification)




user =3D 1*(unreserved | =
escaped |=20
"&"| "=3D" | "+" | "$" | "," | ";" | "?" | "/"=20
)


password =3D =20
1*(unreserved |escaped | "&" | "=3D" | "+" | "$" | ","=20
)


 


header =3D hname "=3D" hvalue




hname =3D 1*(hnv-unreserved | =
unrerserved |=20
escaped)


hvalue =3D 1*(hnv-unreserved | =
unrerserved |=20
escaped)




 


SIP-URL =3D "sip:" [userinfo "@"] hostport url-parameters=20
[headers]


url-parameters =3D 1*(";"=20
url-parameter).


 


A remark about the escaped element, =
declared=20
as :


escaped =3D "%" hex hex


I cannot find a definition for hex in =
the=20
ABNF specification. I suppose that a typographic error has occured and=20
hex has to be translated into=20
HEX, which is well defined and seems to be the =
right=20
element ?


------=_NextPart_000_001F_01C026D2.4496E020--




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


From sip-admin@lists.bell-labs.com  Mon Sep 25 09:27: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 JAA03024
	for ; Mon, 25 Sep 2000 09:27: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 F319E4434F; Mon, 25 Sep 2000 08:27:28 -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 199E94434A
	for ; Mon, 25 Sep 2000 08:27:11 -0400 (EDT)
Received: from sampark.hss.hns.com (sampark.hss.hns.com [139.85.229.22])
	by mars.hss.co.in (8.10.0/8.10.0) with SMTP id e8PDQRC18800;
	Mon, 25 Sep 2000 18:56:34 +0530 (IST)
Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2  (651.2 6-10-1998))  id 65256965.004A2CBF ; Mon, 25 Sep 2000 19:00:11 +0530
X-Lotus-FromDomain: HSSBLR
From: archow@hss.hns.com
To: Henning Schulzrinne 
Cc: sip@lists.bell-labs.com
Message-ID: <65256965.004A2C92.00@sampark.hss.hns.com>
Date: Mon, 25 Sep 2000 19:00:10 +0530
Subject: Re: [SIP] The Null authentication scheme
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-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com



Hi, this seems to be useful if its the server who prompts the question of
"I support Null, if you care".
However, if I take the approach of the client saying "Here is an
unauthenticated request, process as you may" to
the server:

A client passes its authentication info to the server if it wants to. If it
does not, and the server supports 'no authentication'
scheme, it anyway proceeds to treat this request as an unknown.

So then , if we say its really a clients wish if it wants to authenticate
itself, and the servers descision thereof to accept him
or reject him with a final response, do we really need this scheme ?

Regds
Arjun

--
Arjun Roychowdhury @ Hughes Software Systems





Henning Schulzrinne  on 09/24/2000 07:16:50 PM

To:   sip@lists.bell-labs.com
cc:

Subject:  [SIP] The Null authentication scheme




Following some internal discussions, I wrote up a very short I-D on the
Null authentication scheme. Motivation is in the draft:

http://www.cs.columbia.edu/~hgs/sip/drafts/draft-schulzrinne-sip-null-00.tx
t

Before I submit this as an I-D, I'd like to know if this is a completely
brain-dead idea.
--
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 Sep 25 09:45: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 JAA03398
	for ; Mon, 25 Sep 2000 09:45: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 2848944359; Mon, 25 Sep 2000 08:44:55 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from smtp6.mindspring.com (smtp6.mindspring.com [207.69.200.110])
	by lists.bell-labs.com (Postfix) with ESMTP id BD61C4434A
	for ; Mon, 25 Sep 2000 08:44:52 -0400 (EDT)
Received: from gamma (user-1054j4b.biz.mindspring.com [64.82.76.139])
	by smtp6.mindspring.com (8.9.3/8.8.5) with SMTP id JAA13184
	for ; Mon, 25 Sep 2000 09:44:46 -0400 (EDT)
Reply-To: 
From: "Raja Sekhar" 
To: 
Subject: RE: [SIP] reg Proxy authorization and authentication
Date: Mon, 25 Sep 2000 09:41:56 -0400
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: <000201c0269a$55f1c160$6427fea9@dynamicsoft.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

Hello
But I am sending the Proxy autherization header in my register message . The
proxy authorization header consists of the authtype and credentials
1.But when I try to display the registrar message I am except user name ,I
am able to view the rest like type relam and nonce etc
2. How the proxy is going to resolve username and password
3. My register message  useing MD5 algorithm .
reegards
rajasekhar


-----Original Message-----
From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
Sent: Sunday, September 24, 2000 10:43 PM
To: rpasumarty@voicecore.com; SIP@lists.bell-labs.com
Subject: RE: [SIP] reg Proxy authorization and authentication





> -----Original Message-----
> From: Raja Sekhar [mailto:rpasumarty@voicecore.com]
> Sent: Sunday, September 24, 2000 5:44 PM
> To: SIP@lists.bell-labs.com
> Subject: [SIP] reg Proxy authorization and authentication
>
>
> Hai
>  Please any body calrify me  the problem I faced with  the
> authorization
> header and authentication header
> In my UAC code  I am adding the Proxy authoirization header  to   the
> register request consists
>
> But still I am getting the 407 proxy authentication required
> . I am using
> the type DIGEST and relam and user name pawd of my service provider
>
> 1.Is it any sequence where the porxy authorization  header to
> be added   in
> the register message . Is it any document availble for the
> order of the
> header in the request message .
> rajasekhar -voicecore

Ordering of headers in requests is not important, unless requests are being
signed using PGP. Since thats not the case here, it doesn't matter.

I would recommend you check the call flows draft:
http://www.ietf.org/internet-drafts/draft-ietf-sip-call-flows-01.txt

which has examples for e2e authentication (401, not 407), but the message
formatting is pretty much the same.

-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 Sep 25 09:48:22 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA03473
	for ; Mon, 25 Sep 2000 09:48: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 5EF7444361; Mon, 25 Sep 2000 08:47:58 -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 DAFD34434A
	for ; Mon, 25 Sep 2000 08:47: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; 25 Sep 2000 13:48:12 UT
Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef)
	id OAA13162; Mon, 25 Sep 2000 14:45:30 +0100 (BST)
From: "Jo Hornsby" 
To: , "Henning Schulzrinne" 
Cc: 
Subject: RE: [SIP] The Null authentication scheme
Date: Mon, 25 Sep 2000 14:45:28 +0100
Message-ID: <000001c026f6$dd847670$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: <65256965.004A2C92.00@sampark.hss.hns.com>
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

> Hi, this seems to be useful if its the server who prompts the
> question of "I support Null, if you care".  However, if I take the
> approach of the client saying "Here is an unauthenticated request,
> process as you may" to the server:
>
> A client passes its authentication info to the server if it wants
> to. If it does not, and the server supports 'no authentication'
> scheme, it anyway proceeds to treat this request as an unknown.

Hmmm... I'm not sure that this is necessarily true.

Imagine the following scenario:
I make a SIP call from my UA, which is challenged.  The Realm of
the challenge is unrecognised by my UA, so it gives me some sort
of way to enter my credentials.  I have no credentials for this
Realm, but I would like to try the call anyway.  With the normal
"OK"/"Cancel" (use-this-username-password/hang-up-call) approach,
what can I possibly do?  Having a `Null' scheme allows the UA
to add an extra button: "Please take my call even though you don't
know me".

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  Mon Sep 25 09:54: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 JAA03626
	for ; Mon, 25 Sep 2000 09: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 791674435C; Mon, 25 Sep 2000 08:53:31 -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 EE3F444362
	for ; Mon, 25 Sep 2000 08:45:09 -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 IAA16431;
	Mon, 25 Sep 2000 08:44:59 -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 IAA17998;
	Mon, 25 Sep 2000 08:44:39 -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 IAA01996; Mon, 25 Sep 2000 08:44:37 -0500 (CDT)
Message-ID: <39CF56BF.9F718186@ericsson.com>
Date: Mon, 25 Sep 2000 15:44:32 +0200
From: Sean Olson 
Organization: Ericsson Inc.
X-Mailer: Mozilla 4.75 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: =?iso-8859-1?Q?G=E9rard?= GONNET 
Cc: sip@lists.bell-labs.com, lsteffan@atos-group.com,
        SEVESTRE Thibaut 
Subject: Re: [SIP] rfc 2543bis-01 SIP syntax
References: <002201c026c1$81374300$5a040237@it.atosgroup.com>
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-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 8bit

This may be an issue of trying to express semantics with syntax.
The user, password, url-parameters and headers are not mandatory
elements of the SIP URI.
As an example, the user is always empty in the Request-URI of a REGISTER

request. The ABNF does a good job of expressing syntax, but you need
to augment this with a description of the semantics. Otherwise, the SIP
spec.
would be just one big grammar :) Perhaps I'm missing the point of your
posting.
I do find the possibility of a lone ":" in the password interesting ...
no real harm
done in my opinion, but I'm interested to know how many implementations
handle
this ;)

--
Sean Olson 



Gérard GONNET wrote:

> rfc 2543bis-01 SIP syntax revisited Some definitions of the SIP syntax
> can introduce undesirable side effects. For exemple : the user element
> is defined as *(unreserved | escaped | "&"| "=" | "+" | "$" | "," |
> ";" | "?" | "/" ) .The application of the * operator tell us that a
> user element is represented as a succession of 0 (the default value)
> or more chars belonging to the enumerated set.Giving a 0 value to the
> low limit of the repetition factor results in an "empty" user element,
> which is an authorized syntax.This can introduce some trouble :1/ what
> is the meaning of an "empty" user ?2/ because the given syntax is
> equivalent to [user] (cf. C part of the draft, page 116), how to
> ensure the definition of a mandatory user ? The same remark applies to
> the password element, defined aspassword =  *(unreserved |escaped |
> "&" | "=" | "+" | "$" | ","), because the notation [":" password] of
> the user-info element is significant enough to declare password as an
> optional child element. Furthermore, this syntax could reduce the [":"
> password] to a lone ":" char only when used with an "empty"
> password. The same remark applies to the url-parameters element . This
> mandatory child element of the SIP-URL element can be emptied by the
> given definition :url-parameters = * (";" url-parameter). The same
> remark applies to the hvalue element defined as :hvalue =
> *(hnv-unreserved | unrerserved | escaped) .Using this definition in
> the header elementheader = hname "=" hvaluecan reduce the header to a
> hname "="  not terminated form. (notice that the hname left element is
> declared as hname = 1*(hnv-unreserved | unrerserved | escaped) ... To
> avoid side effects in the definition of an element, it seems mandatory
> to apply the following rules : 1/ a mandatory element CANNOT be
> defined with the *something notation, but MUST use the n*something
> notation, with n > 0. 2/ an optional element MUST be defined with the
> ambiguity free [an-optional-element] notation, by opposite to the
> *may-be-optional form. 3/ an optional element CANNOT be defined with
> the *may-be-optional notation, to avoid the possible side-effects
> between the two definitions. Application of these rules gives
> : userinfo = (user | telephone-subscriber) [":"password]  (former
> proposition of modification)user = 1*(unreserved | escaped | "&"| "="
> | "+" | "$" | "," | ";" | "?" | "/" )password =  1*(unreserved
> |escaped | "&" | "=" | "+" | "$" | "," ) header = hname "="
> hvaluehname = 1*(hnv-unreserved | unrerserved | escaped)hvalue =
> 1*(hnv-unreserved | unrerserved | escaped) SIP-URL = "sip:" [userinfo
> "@"] hostport url-parameters [headers]url-parameters = 1*(";"
> url-parameter). A remark about the escaped element, declared as
> :escaped = "%" hex hexI cannot find a definition for hex in the ABNF
> specification. I suppose that a typographic error has occured and hex
> has to be translated into HEX, which is well defined and seems to be
> the right element ?




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


From sip-admin@lists.bell-labs.com  Mon Sep 25 10:01: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 KAA03803
	for ; Mon, 25 Sep 2000 10:01: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 B207D4435E; Mon, 25 Sep 2000 08:59:37 -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 A71374434F
	for ; Mon, 25 Sep 2000 08:59: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 KAA03524;
	Mon, 25 Sep 2000 10:01:27 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id ; Mon, 25 Sep 2000 09:56:13 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'Henning Schulzrinne'" ,
        "'sip@lists.bell-labs.com'" 
Subject: RE: [SIP] The Null authentication scheme
Date: Mon, 25 Sep 2000 09:56:12 -0400
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-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com

I think its a good idea. It allows a server to distinguish:

1. I haven't provided credentials yet,
2. I don't have any valid credentials for this domain

The treatment of these two will, in many cases, be different. Case (1)
usually results in a challenge. Case 2 might allow the call to proceed, or
be rejected definitively, or something.

-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: Henning Schulzrinne [mailto:schulzrinne@cs.columbia.edu]
> Sent: Sunday, September 24, 2000 9:47 AM
> To: sip@lists.bell-labs.com
> Subject: [SIP] The Null authentication scheme
> 
> 
> Following some internal discussions, I wrote up a very short 
> I-D on the
> Null authentication scheme. Motivation is in the draft:
> 
> http://www.cs.columbia.edu/~hgs/sip/drafts/draft-schulzrinne-s
> ip-null-00.txt
> 
> Before I submit this as an I-D, I'd like to know if this is a 
> completely
> brain-dead idea.
> -- 
> 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 Sep 25 10: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 KAA04082
	for ; Mon, 25 Sep 2000 10:17: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 75DBC44375; Mon, 25 Sep 2000 09:16:38 -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 DA2FB4434F
	for ; Mon, 25 Sep 2000 09:16:32 -0400 (EDT)
Received: from tate ([216.181.56.35]) by broadsoft.com (8.8.8) id KAA96343; Mon, 25 Sep 2000 10:16:24 -0400 (EDT)
Message-ID: <004e01c026fb$4ea42180$3202a8c0@broadsoft.com>
From: "Brett Tate" 
To: "Henning Schulzrinne" 
Cc: 
References: <65256965.004A2C92.00@sampark.hss.hns.com>
Subject: Re: [SIP] The Null authentication scheme
Date: Mon, 25 Sep 2000 10:17:16 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.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-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit


----- Original Message -----
From: 
To: Henning Schulzrinne 
Cc: 
Sent: Monday, September 25, 2000 9:30 AM
Subject: Re: [SIP] The Null authentication scheme


>
>
> Hi, this seems to be useful if its the server who prompts the question of
> "I support Null, if you care".
> However, if I take the approach of the client saying "Here is an
> unauthenticated request, process as you may" to
> the server:
>
> A client passes its authentication info to the server if it wants to. If
it
> does not, and the server supports 'no authentication'
> scheme, it anyway proceeds to treat this request as an unknown.
>
> So then , if we say its really a clients wish if it wants to authenticate
> itself, and the servers descision thereof to accept him
> or reject him with a final response, do we really need this scheme ?
>

The draft basically provides an early way to
know that authentication will fail.  I like the
mechanism since it avoids the second INVITE
when authentication is not possible.  I assume
that some phones would not respond to 401/407
when it couldn't authenticate; thus they wouldn't
truly allow for a service that prefers authenticated
but allows unauthenticated calls.

I like the intent of the draft.  However instead of
the mechanism proposed by the draft, I'd rather
see the use of the Supported header or
something else that identifies the types of
Authentication that is expected to currently pass
by the originator.

> 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 Sep 25 12:00: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 MAA06959
	for ; Mon, 25 Sep 2000 12: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 CCA4F44346; Mon, 25 Sep 2000 11:00:18 -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 D98D944346
	for ; Mon, 25 Sep 2000 10:32: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 LAA04493;
	Mon, 25 Sep 2000 11:02:49 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id ; Mon, 25 Sep 2000 10:57:35 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'Sudipto Mukherjee'" ,
        "'sip@lists.bell-labs.com'" 
Subject: RE: [SIP] Content-Disposition Header 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, 25 Sep 2000 10:57:34 -0400




> -----Original Message-----
> From: Sudipto Mukherjee [mailto:sudiptom@cisco.com]
> Sent: Wednesday, September 20, 2000 3:55 PM
> To: sip@lists.bell-labs.com
> Subject: [SIP] Content-Disposition Header questions
> 
> 
> In Sec 6.15, Content-Disposition of draft-ietf-sip-rfc2543bis-02.ps,
> the following is stated -
> 
> disposition-type = "render" "session" "Icon" "alert"
> disp-extension-token
> 
> I need clarification on the usage of the above disposition-types for
> early media and preconditions. 
> 
> In my understanding -
> 
> "alert" is used in 18X responses to convey early cut-thru or 
> early media
> cases.
> 

Yes; although I am confused as well by the wording. From the text, it would
seem that if the content itself contains the media (i.e., a wave file), then
you use alert. I am not sure if this is meant to imply that a 183 with SDP
used for early media would use "session" or "alert". Henning?



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

-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 Sep 25 12:01: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 MAA06996
	for ; Mon, 25 Sep 2000 12:01: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 23C0F44350; Mon, 25 Sep 2000 11:00:33 -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 2A1DC44348
	for ; Mon, 25 Sep 2000 10:32:56 -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 KAA04352;
	Mon, 25 Sep 2000 10:51:42 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id ; Mon, 25 Sep 2000 10:46:28 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'Shail Bhatnagar'" ,
        "'SIP@lists.bell-labs.com'" 
Subject: RE: Post-SRV Request-URI (was - [[SIP] A question about Request-U
	RI:])
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, 25 Sep 2000 10:46:28 -0400

I concur with Jo here.

The SRV processing is post URI construction. The existence of intermediate
host names is an artifact of the SRV procedure. Future lookup procedures,
based on enum, for example, might involve multiple intermediate steps, but I
would not propose that you set the request URI based on them.

-Jonathan R.

> -----Original Message-----
> From: Shail Bhatnagar [mailto:shbhatna@cisco.com]
> Sent: Thursday, September 21, 2000 11:17 AM
> To: SIP@lists.bell-labs.com
> Subject: Post-SRV Request-URI (was - [[SIP] A question about
> Request-URI:])
> 
> 
> Forwarding the email using different subject, since this was an
> old thread.
>> -----Original Message-----
> From: Jo Hornsby [mailto:jhornsby@ubiquity.net]
> Sent: Thursday, September 21, 2000 4:25 AM
> To: Shail Bhatnagar; Henning Schulzrinne
> Cc: SIP@lists.bell-labs.com
> Subject: RE: [SIP] A question about Request-URI:
> 
> 
> > On a related note, when a proxy does a successful SRV lookup for
> > domain.com and gets bigmachine.domain.com,5055 and 
> > bigm2.domain.com,6000 and it selects bigmachine.domain.com,5055.
> > Should it change the incoming 
> > sip:abc@domain.com 
> > to 
> > sip:abc@bigmachine.domain.com:5055 ??
> > 
> > I believe, it should.
> 
> Interesting.  I believe it should not. &:)
> 
> If you look at the rules of Section 1.4.2, all the magic done
> is _based on the Request-URI_; suggesting that the Request-URI
> is already well-defined at that point.
> 
> Imagine a case where you have a Large Corporation, the ubiquitous
> example.com.  Now example.com has two divisions: division1 and
> division2.  If there were two distinct Smith's working for
> example.com, one in division1 and one in division2, then they
> might have the SIP URLs
> sip:smith@division1.example.com,
> sip:smith@division2.example.com,
> respectively.  Now if there's a large SIP proxy sitting "at the
> edge" of example.com, sip.example.com, and this proxy can be
> found via SRV, then changing the Request-URI could potentially
> result in a fatal loss of information.  Not good.
> 
> Of course, as always, proxies are free to do what they want --
> it's their birthright; thus there may well be situations where
> this is exactly what you want.  In general, however, I would
> argue that it is not what you want.
> 
> > Also, when forwarding a request using the Route header, should 
> > the outgoing Request-URI always be the addr-spec portion of 
> the Route
> > header or it can be different due to SRV lookup on the maddr ??
> 
> The whole Request-URI in the Route is copied into the Request-URI
> proper; maddr, transport (although this should never appear in
> a Record-Route/Route), etc., parameters are no-longer illegal here.
> 
> HTH,
> 
> 
>  - Jo.
> 
> 
> 

---
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 Sep 25 12: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 MAA07155
	for ; Mon, 25 Sep 2000 12: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 E105A44358; Mon, 25 Sep 2000 11:00:47 -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 7496244349
	for ; Mon, 25 Sep 2000 10:32:56 -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 KAA04433;
	Mon, 25 Sep 2000 10:56:46 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id ; Mon, 25 Sep 2000 10:51:32 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'Jo Hornsby'" ,
        "'mranga@nist.gov'" ,
        "'sip@lists.bell-labs.com'" 
Cc: Jonathan Rosenberg 
Subject: RE: [SIP] A question on forwarding INVITES
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, 25 Sep 2000 10:51:30 -0400



> -----Original Message-----
> From: Jo Hornsby [mailto:jhornsby@ubiquity.net]
> Sent: Thursday, September 21, 2000 4:59 AM
> To: mranga@nist.gov; sip@lists.bell-labs.com
> Cc: Jonathan Rosenberg
> Subject: RE: [SIP] A question on forwarding INVITES
> 
> > I have a follow-up question regarding user locaton and forwarding of
> > invites.  ( These are newbie questions so put the kid gloves on).
> > 
> > In my design, I am making the following assumptions:
> > 
> > 1. If the target of the invite has not REGISTERed, then the invite
> > is forwarded based on address imbedded in the SIP url.
> > 
> > 2, If the targetted user HAS a valid REGISTER, then the addresses in
> > the registration record is used to forward the INVITE.
> > 
> > If 1 and 2 fail then
> > 
> > 3 Do a lookup via LDAP or rwho etc (i.e. use a location server) to
> > figure out where to send the invite where the information needed to
> > do the lookup is available as SIP URL parameters (name, value
> > pairs).
> > 
> > Is item 3 the responsibility of the SIP proxy server? The RFC seems
> > to indicate that the SIP server MAY talk to a locaton server in
> > addition to using REGISTER (and there must be a good reason for it).
> > I realize that this is a design choice but it affects the complexity
> > of the system.  Why not let it be the caller's responsibility to
> > locate the user by talking directly to location services if need be?
> 
> Thus I would fold item 2 into item 3 (i.e., REGISTERs modify
> the Location Server"), and then in a simple implementation you
> might get the following:
>  a) Apply item 3 to the Request-URI.
>  b) If a) yields no results, apply item 1 to the Request-URI,
>     and if this resolves to some network address, forward the
>     Request there.
>  c) If a) yields one or more results, apply item 1 to each
>     URI in turn, and forward the Request to each URI that
>     resolves to a routable network address.
> 
> Other implementations may apply item 1 recursively, or perform
> b) regardless of the result of a), or never apply item 3 at
> all...the possibilities are endless.

Right. Processing at a proxy which owns the namespace indicated in the
request URI really is a matter of local operation. Often this involves
checking the location server database for a registration, in many other
cases it won't.

However, the processing of a proxy of a request for a request whose URI is
NOT in the namespace of the server is a different story; generally, it
should forward the request to that domain using a DNS lookup.

Also note that server processing is different when a Route header is present
in a request. In this case, it should pop the top Route into the request URI
and forward it to the server listed in the domain of the request URI.

-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 Sep 25 12:14: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 MAA07388
	for ; Mon, 25 Sep 2000 12:14: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 E83CC44362; Mon, 25 Sep 2000 11:01: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 D2C7F44346
	for ; Mon, 25 Sep 2000 10:32:56 -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 KAA04006;
	Mon, 25 Sep 2000 10:30:44 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id ; Mon, 25 Sep 2000 10:25:30 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'Jo Hornsby'" ,
        "'dukes@inin.com'" 
Cc: "'sip@lists.bell-labs.com'" 
Subject: RE: [SIP] RE: [Test Bed Technical Forum:] Determining the length 
	of the SIP message body
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, 25 Sep 2000 10:25:29 -0400




> -----Original Message-----
> From: Jo Hornsby [mailto:jhornsby@ubiquity.net]
> Sent: Friday, September 22, 2000 10:10 AM
> To: dukes@inin.com
> Cc: sip@lists.bell-labs.com
> Subject: [SIP] RE: [Test Bed Technical Forum:] Determining 
> the length of
> the SIP message body
> 
> 
> This question is more appropriate on the SIP List; Cc:d.
> 
> >  MESSAGE:  (#45) Determining the length of the SIP message body 
> >           
> > 
>  
> >  AUTHOR:   Duke Snyder 
> >  DATE:     Friday, 22 September 2000, at 1:54 p.m. 
> >
> > If there is a content-length header then no problem - but the 
> > content-length header is optional (according to the rfc in
> > section 6.17).
> 
> This is true -- Content-Length is indeed specified as optional
> in the RFC; however, the bis02 draft, which trackes current
> state of the art, makes it mandatory.
> 
> > If no content-length header, how do the servers determine if 
> > there is a body: 
> > 1. There is a body if there is a content-type header - is 
> this true? 
> 
> Although it would be odd for there to be a Content-Type header
> and no body, I don't see this technically illegal (especially
> if Content-Length was specified as 0).  I wouldn't rely on
> Content-Type to imply the presence or otherwise of a body.
> 
> > If no content-length header and there is a body, how do you 
> determine
> > its length? 
> > 1. The body goes to the end of the udp packet - is this true?. 
> 
> Yes.
> 
> > 2. The body goes to the first CRLF after decoding - but the rfc does
> > not mention a CRLF after the message body. 
> 
> No, since it is perfectly legal to have one or more CRLFs in a
> body (think SDP).
> 
> > 3. The content-length field must be used if tcp - is this true? 
> 
> Yes, well, it's true pretty much universally true nowadays.
> (There is some leniency towards Content-Length in responses;
> this is to make stuff like SIP CGI easier, for instance.)

RFC2543 does not mandate it for tcp. Without one, the body continues until
the connection is closed.

-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 Sep 25 12:21: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 MAA07683
	for ; Mon, 25 Sep 2000 12:21: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 4CF414437F; Mon, 25 Sep 2000 11:01:28 -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 180EF4433C
	for ; Mon, 25 Sep 2000 10:52: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 LAA05338;
	Mon, 25 Sep 2000 11:54:09 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id ; Mon, 25 Sep 2000 11:48:55 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'pmurthy@hss.hns.com'" ,
        "'sip@lists.bell-labs.com'" 
Subject: RE: [SIP] A 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: Mon, 25 Sep 2000 11:48:54 -0400

You bring up something we need to discuss.

TH reason they are listed as both request and response headers is that we
wanted to support response authentication and signing. However, the use of
challenge-response authentication for responses worries me, as it has never
been implemented, as far as I know, and I think we would find there are lots
of issues.

Response signing is important, however, as it prevents certain attacks.

It might be time to revisit this issue. We can:

1. support only non-challenge-response (i.e., just  a pure signature)
authentication of responses
2. keep the challenge response stuff for responses, but we better test it
and run through it
3. ditch response signing end to end completely

Comments?

-Jonathan R.


> -----Original Message-----
> From: pmurthy@hss.hns.com [mailto:pmurthy@hss.hns.com]
> Sent: Wednesday, September 20, 2000 7:38 AM
> To: sip@lists.bell-labs.com
> Subject: [SIP] A Clarification
> 
> 
> 
> 
> 
> With reference to 
> "http://www.cs.columbia.edu/~hgs/sip/notes.html", under
> the Www-Authenticate and Authorization sub-heading, it has 
> been mentioned
> that the two headers could be Req & Response hdrs. But, in 
> the SIP Grammar
> link
> http://www.cs.columbia.edu/~hgs/sip/syntax/draft-ietf-sip-rfc2
> 543bis-01.htm
> l, Authorization is included under "request-header" and 
> Www-Authenticate
> under "response-header" . Am I looking at the correct Grammar 
> links ? Is
> there a correction needed ?
> 
> Regards
> Prashant
> 
> 
> 
> 
> _______________________________________________
> 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  Mon Sep 25 12:25: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 MAA07770
	for ; Mon, 25 Sep 2000 12:25: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 D79DF4438B; Mon, 25 Sep 2000 11:01:41 -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 F007D4433E
	for ; Mon, 25 Sep 2000 10:58:22 -0400 (EDT)
Received: from CINQUECENTO (DYN001-DA02A03-95.arcommunications.net [64.17.132.224])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with SMTP id MAA05506;
	Mon, 25 Sep 2000 12:00:13 -0400 (EDT)
From: "Robert Sparks" 
To: "Henning Schulzrinne" ,
        
Subject: RE: [SIP] The Null authentication scheme
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: <39CE05C9.DEB256F4@cs.columbia.edu>
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: Mon, 25 Sep 2000 10:55:08 -0500
Content-Transfer-Encoding: 7bit

I like this on an inital read.

It provides a fairly clean mechanism for a service provider
to allow "anonymous" access to a defined subset of its services.

RjS

> -----Original Message-----
> From: sip-admin@lists.bell-labs.com
> [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Henning Schulzrinne
> Sent: Sunday, September 24, 2000 8:47 AM
> To: sip@lists.bell-labs.com
> Subject: [SIP] The Null authentication scheme
> 
> 
> Following some internal discussions, I wrote up a very short I-D on the
> Null authentication scheme. Motivation is in the draft:
> 
> http://www.cs.columbia.edu/~hgs/sip/drafts/draft-schulzrinne-sip-n
ull-00.txt

Before I submit this as an I-D, I'd like to know if this is a completely
brain-dead idea.
-- 
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 Sep 25 12:32: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 MAA07916
	for ; Mon, 25 Sep 2000 12: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 1B6974437E; Mon, 25 Sep 2000 11:30: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 B895244359
	for ; Mon, 25 Sep 2000 09:20:17 -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 KAA26456
	for ; Mon, 25 Sep 2000 10:20:14 -0400 (EDT)
Message-ID: <39CF5F1E.36E7B4B2@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] Attempt at summarizing current SIP 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: Mon, 25 Sep 2000 10:20:14 -0400
Content-Transfer-Encoding: 7bit

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


From sip-admin@lists.bell-labs.com  Mon Sep 25 13:13: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 NAA08722
	for ; Mon, 25 Sep 2000 13:13: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 62C594433E; Mon, 25 Sep 2000 12:13:11 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from godzilla.ipdialog.com (mail.ipdialog.com [208.238.222.66])
	by lists.bell-labs.com (Postfix) with ESMTP id 879554433C
	for ; Mon, 25 Sep 2000 12:12:53 -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 KAA08608;
	Mon, 25 Sep 2000 10:11:36 -0700
Message-ID: <39CF8748.A4E51935@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: Simon Barber 
Cc: Jo Hornsby ,
        "'Sip@Lists. Bell-Labs. Com'" 
Subject: Re: [SIP] Outbound call routing
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, 25 Sep 2000 10:11:36 -0700
Content-Transfer-Encoding: 7bit

Simon Barber wrote:

> This way all outbound requests pass through the same server that
> handles the user's inbound calls. This should be completely compatible
> with current procedures. It does tie the server which handles services
> for outbound calls to the same server that handles services for inbound
> calls, but is this a problem?

Depends on the installation size, and whether you want to guarantee outbound
calls with a dedicated server versus sharing cycles with a possibly overloaded
(or DDoS'ed) inbound server.

>
>
> This also means that this form of outbound routing is used for all SIP
> requests, irrespective of whether this is required for services or not.
>
> In summary, 3 approaches:
>
> 1) configuration using REGISTER
> - outbound routing can be controlled on a per specific registration basis

>
> 2) configuration using SRV record
> - outbound routing can be controlled on a per domain basis
>
> 3) always route through user's home server
> - no option not to route through user's home server
>
> or
>
> 4) other method?
>

Only possible issue I see for 1) is early deployments may only use remote
public Registrars that are outside local control and can't be preloaded with
Route: info on local outbound proxies. Of course, 2) has the same problem if
you don't own your local domain. 3) is always the fallback. 4) Someone
mentioned SIP DHCP extensions.


Howard Hart
ipDialog, Inc.



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


From sip-admin@lists.bell-labs.com  Mon Sep 25 13:40: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 NAA09167
	for ; Mon, 25 Sep 2000 13:40: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 2C44B4433E; Mon, 25 Sep 2000 12:40:11 -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 AF5B24433C
	for ; Mon, 25 Sep 2000 12:39: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 NAA19211;
	Mon, 25 Sep 2000 13:39:07 -0400 (EDT)
Message-ID: <39CF8DBB.834AE255@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: "'Sudipto Mukherjee'" ,
        "'sip@lists.bell-labs.com'" 
Subject: Re: [SIP] Content-Disposition Header questions
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, 25 Sep 2000 13:39:07 -0400
Content-Transfer-Encoding: 7bit

Jonathan Rosenberg wrote:
> 

> 
> Yes; although I am confused as well by the wording. From the text, it would
> seem that if the content itself contains the media (i.e., a wave file), then
> you use alert. I am not sure if this is meant to imply that a 183 with SDP
> used for early media would use "session" or "alert". Henning?

The wave attachment (verbatim media, instead of pointer) idea is what I
had in mind, with 'session' for anything describing a session. The fact
that the session description is part of 18x indicates that it's early
media, so I don't think a separate indication is needed. If that's
acceptable, I'll try to clarify.


-- 
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 Sep 25 14:25: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 OAA10128
	for ; Mon, 25 Sep 2000 14: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 E8FC94433C; Mon, 25 Sep 2000 13:25:10 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by lists.bell-labs.com (Postfix) with ESMTP id F1D754433C
	for ; Mon, 25 Sep 2000 13:07:55 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA21709;
	Mon, 25 Sep 2000 14:07:49 -0400 (EDT)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA21663;
	Mon, 25 Sep 2000 14:07:49 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id ; Mon, 25 Sep 2000 14:07:49 -0400
Message-ID: <4FBEA8857476D311A03300204840E1CF01A6E71B@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" 
To: "'Jonathan Rosenberg'" ,
        "'pmurthy@hss.hns.com'" ,
        "'sip@lists.bell-labs.com'" 
Subject: RE: [SIP] A 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: Mon, 25 Sep 2000 14:07:41 -0400

While I like 1), I think we may need to do 2).
If the requestor doesn't need to challenge, but the
responder does....

I'm a bit off from being able to sign up to implement such
a feature, but that looks like what we have to do.

I could probably live with 1) if there were a lot of problems.

Brian

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> Sent: Monday, September 25, 2000 11:49 AM
> To: 'pmurthy@hss.hns.com'; 'sip@lists.bell-labs.com'
> Subject: RE: [SIP] A Clarification
> 
> 
> You bring up something we need to discuss.
> 
> TH reason they are listed as both request and response 
> headers is that we
> wanted to support response authentication and signing. 
> However, the use of
> challenge-response authentication for responses worries me, 
> as it has never
> been implemented, as far as I know, and I think we would find 
> there are lots
> of issues.
> 
> Response signing is important, however, as it prevents 
> certain attacks.
> 
> It might be time to revisit this issue. We can:
> 
> 1. support only non-challenge-response (i.e., just  a pure signature)
> authentication of responses
> 2. keep the challenge response stuff for responses, but we 
> better test it
> and run through it
> 3. ditch response signing end to end completely
> 
> Comments?
> 
> -Jonathan R.
> 
> 
> > -----Original Message-----
> > From: pmurthy@hss.hns.com [mailto:pmurthy@hss.hns.com]
> > Sent: Wednesday, September 20, 2000 7:38 AM
> > To: sip@lists.bell-labs.com
> > Subject: [SIP] A Clarification
> > 
> > 
> > 
> > 
> > 
> > With reference to 
> > "http://www.cs.columbia.edu/~hgs/sip/notes.html", under
> > the Www-Authenticate and Authorization sub-heading, it has 
> > been mentioned
> > that the two headers could be Req & Response hdrs. But, in 
> > the SIP Grammar
> > link
> > http://www.cs.columbia.edu/~hgs/sip/syntax/draft-ietf-sip-rfc2
> > 543bis-01.htm
> > l, Authorization is included under "request-header" and 
> > Www-Authenticate
> > under "response-header" . Am I looking at the correct Grammar 
> > links ? Is
> > there a correction needed ?
> > 
> > Regards
> > Prashant
> > 
> > 
> > 
> > 
> > _______________________________________________
> > 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  Mon Sep 25 15:12: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 PAA11481
	for ; Mon, 25 Sep 2000 15:12: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 4C3114433C; Mon, 25 Sep 2000 14:12:10 -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 D16084433C
	for ; Mon, 25 Sep 2000 13:59:57 -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 LAA23018;
	Mon, 25 Sep 2000 11:59:07 -0700 (PDT)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA03997; Mon, 25 Sep 2000 11:59:00 -0700 (PDT)
From: Michael Thomas 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14799.41076.784063.944519@thomasm-u1.cisco.com>
To: "Jo Hornsby" 
Cc: , "Henning Schulzrinne" ,
        
Subject: RE: [SIP] The Null authentication scheme
In-Reply-To: <000001c026f6$dd847670$4e34c3c1@ubiquity.co.uk>
References: <65256965.004A2C92.00@sampark.hss.hns.com>
	<000001c026f6$dd847670$4e34c3c1@ubiquity.co.uk>
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, 25 Sep 2000 11:59:00 -0700 (PDT)
Content-Transfer-Encoding: 7bit


I guess I don't understand why the desire for a "guest account"
in SIP is in more need of standardization than the same for
HTTP. This seems much more like a BCP to me...

		 Mike

Jo Hornsby writes:
 > > Hi, this seems to be useful if its the server who prompts the
 > > question of "I support Null, if you care".  However, if I take the
 > > approach of the client saying "Here is an unauthenticated request,
 > > process as you may" to the server:
 > >
 > > A client passes its authentication info to the server if it wants
 > > to. If it does not, and the server supports 'no authentication'
 > > scheme, it anyway proceeds to treat this request as an unknown.
 > 
 > Hmmm... I'm not sure that this is necessarily true.
 > 
 > Imagine the following scenario:
 > I make a SIP call from my UA, which is challenged.  The Realm of
 > the challenge is unrecognised by my UA, so it gives me some sort
 > of way to enter my credentials.  I have no credentials for this
 > Realm, but I would like to try the call anyway.  With the normal
 > "OK"/"Cancel" (use-this-username-password/hang-up-call) approach,
 > what can I possibly do?  Having a `Null' scheme allows the UA
 > to add an extra button: "Please take my call even though you don't
 > know me".
 > 
 > 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  Mon Sep 25 16:24: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 QAA12833
	for ; Mon, 25 Sep 2000 16:24: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 F3B1A4433C; Mon, 25 Sep 2000 15:24:09 -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 CAEA14433A
	for ; Mon, 25 Sep 2000 15:23:04 -0400 (EDT)
Received: from zrchb213.us.nortel.com (actually zrchb213) 
          by smtprch2.nortel.com; Mon, 25 Sep 2000 14:58:07 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2652.35) 
          id ; Mon, 25 Sep 2000 15:01:57 -0500
Message-ID: <28560036253BD41191A10000F8BCBD11480DE0@zcard00g.ca.nortel.com>
From: "Tom-PT Taylor" 
To: sip 
X-Mailer: Internet Mail Service (5.5.2652.35)
X-Orig: 
Subject: [SIP] Re-direct of Media During Ringing
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
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, 25 Sep 2000 15:01:53 -0500

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


From sip-admin@lists.bell-labs.com  Mon Sep 25 17:30: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 RAA14846
	for ; Mon, 25 Sep 2000 17:30: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 9B3A244346; Mon, 25 Sep 2000 16:30:10 -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 B32A64433E
	for ; Mon, 25 Sep 2000 16:29:52 -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 VAA19326
	for ; Mon, 25 Sep 2000 21:29:49 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 PAA05138
	for ; Mon, 25 Sep 2000 15:29:41 -0600 (MDT)
Received: by n0195idc1.oss.level3.com with Internet Mail Service (5.5.2650.21)
	id ; Mon, 25 Sep 2000 15:31:31 -0600
Message-ID: <87A245E94948D3118DE30008C716B01301523B63@c0005v1idc1.oss.level3.com>
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] Expressing multiple choices in 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: Mon, 25 Sep 2000 15:29:38 -0600


I've been shopping around for a mechanism in SIP that will allow me to send
multiple target URIs in a single INVITE message to a UA. Consider, for
example:

UA1 sends out a SIP INVITE that eventually hits a redirect server which
sends back a 300 with four Contact URIs. The first three URIs identify users
(with qvalues) at UA2: harpo@ua2;q=0.1, chico@ua2;q=0.2, and
groucho@ua2;q=0.5. Let's say that UA1 understands that it will perform a
recursive sequential search. And also, for this to make sense, UA2 has to be
an entity that manages multiple discrete users (like a PBX or some kind of
gateway), and it must have made sense for the URI in the original INVITE to
be mapped onto multiple possible termination URIs.

Ordinarily, UA1 would first send an INVITE to groucho@ua2. If UA2 is unable
to accept the session for any reason, it would return an appropriate status
code, and then (if appropriate given the status) UA1 would send a new INVITE
to UA2 for chico@ua2. If Chico weren't available Harpo would be tried in
turn.

What I'm looking for is a mechanism by which UA1 could send a single INVITE
to UA2 containing the URIs for Groucho, Harpo and Chico, with their qvalues,
in order to allow UA2 to try them all without any intermediate signaling as
it traverses the choices. Presumably, only if none of the three were
available would UA2 return a failure code to UA1. This could result in
consideration optimization of signaling message exchange (hence cutting down
on session setup time and whatnot) for relevant applications.

It has been suggested to me that the Accept-Contact header specified in the
callerprefs draft:
http://www.ietf.org/internet-drafts/draft-ietf-sip-callerprefs-02.txt
is relatively close to what is desired here. Using that header, one could
construct a message like:

INVITE sip:ua2.level3.net SIP/2.0
...
Accept-Contact: sip:groucho@ua2.level3.net;q=0.5,
                  sip:chico@ua2.level3.net;q=0.2,
                  sip:harpo@ua2.level3.net;q=0.1

This differs in a couple of ways from the assumptions of the callerprefs doc
- the most salient difference being that in this example the target of this
INVITE is a UA rather than a PS. Also, the user portion of the Request-URI
is left unspecified - all destination addresses for the session are assumed
to be in the Accept-Contact header.

Does anyone have strong feelings for or against this method of expressing
multiple choices in an INVITE? Any other suggestions for implementing this
functionality?

Jon Peterson
Level(3) Communications

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


From sip-admin@lists.bell-labs.com  Mon Sep 25 18:47: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 SAA16733
	for ; Mon, 25 Sep 2000 18:47: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 EEFE844346; Mon, 25 Sep 2000 17:47:10 -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 188424433E
	for ; Mon, 25 Sep 2000 17:46:46 -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 WAA19996
	for ; Mon, 25 Sep 2000 22:46:42 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 QAA20548
	for ; Mon, 25 Sep 2000 16:46:34 -0600 (MDT)
Received: by n0195idc1.oss.level3.com with Internet Mail Service (5.5.2650.21)
	id ; Mon, 25 Sep 2000 16:48:23 -0600
Message-ID: <87A245E94948D3118DE30008C716B01301523B64@c0005v1idc1.oss.level3.com>
To: sip@lists.bell-labs.com
Subject: RE: [SIP] Outbound call routing
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, 25 Sep 2000 16:46:25 -0600


It seems to me that this discussion is considering two issues - firstly, how
does a UA discover that it should use a particular PS as an outbound proxy,
and secondly, how does the UA signal the first-hop and final destinations of
the session in an INVITE. I think the second question can and should be
considered independently from the first, as it has bearing on other
architectures that require a very similar mechanism.

For example, consider a case in which a UA sends an INVITE that reaches a
local PS which then performs some sort of lookup and decides to forward the
call to a remote PS in another administrative domain. In order to reach the
remote PS, however, the local PS must send the call through a specific
firewall - perhaps there are several firewalls in the local administrative
domain, and one is a better way to reach the remote domain than the others.
When it has made its decision about which specific firewall is the right one
to traverse (which could have been discovered in any of a number of ways),
it must use some mechanism in its signaling to the firewall to describe the
first-hop server (the firewall itself) and the final destination (the remote
PS). I see no reason why we couldn't use the same signaling mechanism for
this that we would use in the UA-to-outbound-proxy case. It could be as
simple as just sending the INVITE to the first-hop server with a Request-URI
indicating the final destination. Or it could be, as has been suggested
here, an early Route header (an idea that's fairly attractive to me). I'm
not sure how this could be made compatible with DNS SRV records (for reasons
similar to those brought up by Jo@ubiquity earlier in the thread), but I
think SRV speaks more to the first issue than to the second anyway.

As a bit of an aside, I'd also like to suggest that a UA should not break
Record-Route regardless of any internally configured PS for outbound
requests. That is, the outbound proxy routing mechanism should be consulted
for new session requests only, not for requests associated with a
pre-existing session. When the UA is the -caller-, if the outbound proxy
chooses to add itself to the Record-Route, all future requests for the
session will cross the outbound proxy, so this shouldn't be broken. What
concerns me here are cases in which a UA is the -callee-, a Record-Route
exists for the call that does not include the outbound proxy (for whatever
reason), and the UA decides to a issue, say, a BYE, and is forced to break
Record-Route in order to send it to the outbound proxy. This could lead to
various problems. Ultimately, the inbound routing procedures should
guarantee that the outbound proxy has the opportunity to Record-Route itself
on the initial INVITE if this is appropriate; this shouldn't be
retroactively enforced by a UA.

Jon Peterson
Level(3) Communications

-----Original Message-----
From: Simon Barber [mailto:simon@firetalk.com]
Sent: Friday, September 22, 2000 6:48 PM
To: Jo Hornsby; hch@ipdialog.com
Cc: 'Sip@Lists. Bell-Labs. Com'
Subject: RE: [SIP] Outbound call routing


> > When a SIP message is first sent out from a UAC the requestURI could
> > be set to the contents of the DNS SRV record "sipoutbound". When the
> > INVITE reaches the user's outbound server, then the request URI
> > would be set to the contents of the to: header. This assumes that
> > the UA always wants the request routed to the to: header. Is this
> > always true?
>
> I would say very likely to be true, for an initial INVITE.  I
> would stay away from "always", however. &:)

A valid argument. We should maintain the ability of the UAC to set
the requestURI of the invite to whatever it wants.

>
> > This also changes the handling of the to: header. It is
> > now not interpreted by the proxy servers between the terminal and
> > the user's outbound server. This means that local semantics will not
> > be applied. I guess sometimes this is good, sometimes bad!
>
> This is slightly problematic; how does a proxy know that it is
> supposed to be interpreting the To: instead of the Request-URI?
> Although I guess it's only the first proxy (the "home" proxy?)
> after the firewall prox(y|ies) that needs to know that To is
> overriding.  Hmmm...
>
> [...]
> > Using the SRV record has the advantage that the UA does not need to
> > be registered before outbound calling will work correctly. I see
> > this decoupling of outbound and inbound calling as an important
> > advantage.
>
> Using the SRV record also has the disadvantage that someone has to
> be responsible for configuring the record for a user's address,
> and since the granularity is at a domain level, this isn't that
> flexible (I might like to have my own "outbound" proxy, that I'd
> written with my own funky features, for instance).

Hisham - Apologies, I have misunderstood your meaning for outbound server.
By outbound server I mean a server that is part of my domain, that all my
outbound requests will pass though (whether I am originating those requests
from part of the network within my domain or not).

I would suggest the sipoutbound SRV record is domain wide, not user
specific - just like the SIP SRV record for incoming calls. If you
want to use a specific server for your particular user, then you
should have the server that handles the domain direct the request to
a server that handles your particular user.

Using a domain wide SRV record means that it's all or nothing for that
domain, of course. This forces outbound requests to be routed like this for
all users. Using the response to REGISTER means this is configurable on a
user by user basis, but it does require the user be registered.

>
> The notion of using source routing mentioned earlier in this
> thread, by embedding a Route header, as Anders and Sean suggested,
> would seem to solve all of these problems, and it reuses existing
> syntax quite nicely.  Plus -- as Sean pointed out -- it generalises
> to multiple proxies; not to mention the possibilities with implying
> other headers (State perhaps?).
>

Route does seem to be a neat solution. Excuse my ignorance, but why does it
have to be embedded in the requestURI?

Indeed I am not sure that we even need a separate SRV record for
outbound and inbound calls at all. Why not simply say that a Route:
header for initial requests should be set to the sip URL for the
user making the request (normally also the contents of the From:
header.).

This way all outbound requests pass through the same server that
handles the user's inbound calls. This should be completely compatible
with current procedures. It does tie the server which handles services
for outbound calls to the same server that handles services for inbound
calls, but is this a problem?

This also means that this form of outbound routing is used for all SIP
requests, irrespective of whether this is required for services or not.

In summary, 3 approaches:

1) configuration using REGISTER
- outbound routing can be controlled on a per specific registration basis

2) configuration using SRV record
- outbound routing can be controlled on a per domain basis

3) always route through user's home server
- no option not to route through user's home server

or

4) other method?



> Do you forsee any problems with this approach?

Seems very sensible!

>
> 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  Mon Sep 25 19:44: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 TAA17514
	for ; Mon, 25 Sep 2000 19:44: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 8C07F4433E; Mon, 25 Sep 2000 18:44:10 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from mailserver2.sylantro.com (unknown [38.185.174.4])
	by lists.bell-labs.com (Postfix) with SMTP id 4A7054433A
	for ; Mon, 25 Sep 2000 18:43:49 -0400 (EDT)
Received: from 172.16.128.16 by mailserver2.sylantro.com with ESMTP (
 WorldSecure Server SMTP Relay(WSS) v4.3); Mon, 25 Sep 00 16:42:17 -0700
X-Server-Uuid: 59490da2-986c-11d3-91ca-00104b9c3900
Received: by MAILSERVER2 with Internet Mail Service (5.5.2650.21) id
 ; Mon, 25 Sep 2000 16:42:16 -0700
Message-ID: 
From: "Suresh Srinivas" 
To: sip@lists.bell-labs.com
Subject: [SIP] Handling error conditions
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
X-WSS-ID: 15D13D536973-01-01
Content-Type: text/plain; 
 charset=iso-8859-1
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, 25 Sep 2000 16:42:16 -0700
Content-Transfer-Encoding: 7bit

Could someone please validate if the following error conditions are handled
properly or 
what is the right way to handle them. 

Regards,
Suresh

New call origination:
---------------------
Scenario 1:
    - Sending INVITE failed at the UAC
    - UAC did not receive response (or failed to parse response) for INVITE
Handling:
   Give disconnect indication. Go to Idling state when user disconnects the
call.

Scenario 2:
   - Sending ACK (in response to 200 OK) failed at the UAC
Handling:
   Give disconnect indication. Go to Idling state when user disconnects the
call.
                OR
   Continue with the call ?

Scenario 3:
    - Sending response to INVITE failed at the UAS
    - Did not receive ACK (or failed to parse ACK) for the final response at
the UAS
Handling:
   Disconnect the call and go to Idling state.

Call is established, UAC sends INVITE to change the session params
-------------------------------------------------------------------
Scenario 1:
    - Sending INVITE failed at the UAC
    - UAC did not receive response (or failed to parse response) for INVITE
    - Sending ACK (in response to 200 OK) failed at the UAC
Handling:
    Give disconnect indication. Go to Idling state when user disconnects the
call.
                     OR
    Return failure on the user interface for the action that triggered 
    the session parameter change and continue with the old session 
    parameters ?

Scenario 2:
    - Sending response to INVITE failed at the UAS
    - Did not receive ACK (or failed to parse ACK) for the final 
      response at the UAS
Handling:
    Give disconnect indication. Go to Idling state when user disconnects the
call.
                     OR
    Continue with the old session parameters ?

Call disconnection
-------------------
Scenario 1:
    - Sending BYE failed at the UAC
    - UAC did not receive response (or failed to parse response) for BYE
Handling:
    Go to Idling

Scenario 2:
    - Sending response to BYE failed at the UAS
Handling:
    Go to Idling


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


From sip-admin@lists.bell-labs.com  Mon Sep 25 19:54: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 TAA17730
	for ; Mon, 25 Sep 2000 19: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 A05AD4433C; Mon, 25 Sep 2000 18:54:09 -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 B8E424433A
	for ; Mon, 25 Sep 2000 18:53:02 -0400 (EDT)
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 IAA05747;
	Mon, 25 Sep 2000 08:11:33 -0700 (PDT)
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 LAA27018; Mon, 25 Sep 2000 11:10:39 -0400 (EDT)
Message-ID: <39CF6AEF.F92151C5@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: Jonathan Rosenberg 
Cc: "'sip@lists.bell-labs.com'" 
Subject: Re: [SIP] Content-Disposition Header questions
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, 25 Sep 2000 11:10:39 -0400
Content-Transfer-Encoding: 7bit

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 ?

Thanks
- Sudipto


Jonathan Rosenberg wrote:
> 
> > -----Original Message-----
> > From: Sudipto Mukherjee [mailto:sudiptom@cisco.com]
> > Sent: Wednesday, September 20, 2000 3:55 PM
> > To: sip@lists.bell-labs.com
> > Subject: [SIP] Content-Disposition Header questions
> >
> >
> > In Sec 6.15, Content-Disposition of draft-ietf-sip-rfc2543bis-02.ps,
> > the following is stated -
> >
> > disposition-type = "render" "session" "Icon" "alert"
> > disp-extension-token
> >
> > I need clarification on the usage of the above disposition-types for
> > early media and preconditions.
> >
> > In my understanding -
> >
> > "alert" is used in 18X responses to convey early cut-thru or
> > early media
> > cases.
> >
> 
> Yes; although I am confused as well by the wording. From the text, it would
> seem that if the content itself contains the media (i.e., a wave file), then
> you use alert. I am not sure if this is meant to imply that a 183 with SDP
> used for early media would use "session" or "alert". Henning?
> 
> > 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.
> 
> -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 Sep 25 20:06: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 UAA17925
	for ; Mon, 25 Sep 2000 20:06: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 54FEA4435A; Mon, 25 Sep 2000 19:06:10 -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 41AB34433A
	for ; Mon, 25 Sep 2000 19:05:29 -0400 (EDT)
Received: from zrchb213.us.nortel.com (actually zrchb213) 
          by smtprch1.nortel.com; Mon, 25 Sep 2000 19:03:11 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2652.35) 
          id ; Mon, 25 Sep 2000 19:03:01 -0500
Message-ID: <28560036253BD41191A10000F8BCBD11480DE4@zcard00g.ca.nortel.com>
From: "Tom-PT Taylor" 
To: sip@lists.bell-labs.com
Cc: "'rsparks@dynamicsoft.com'" 
X-Mailer: Internet Mail Service (5.5.2652.35)
Subject: [SIP] Referred-By: ...referenced-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: Mon, 25 Sep 2000 19:02:57 -0500

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


From sip-admin@lists.bell-labs.com  Mon Sep 25 23:38: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 XAA22683
	for ; Mon, 25 Sep 2000 23: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 DDE2A4433A; Mon, 25 Sep 2000 22:38:10 -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 A71FE44339
	for ; Mon, 25 Sep 2000 22:37:13 -0400 (EDT)
Received: from sampark.hss.hns.com (sampark.hss.hns.com [139.85.229.22])
	by mars.hss.co.in (8.10.0/8.10.0) with SMTP id e8Q3aOC24463;
	Tue, 26 Sep 2000 09:06:26 +0530 (IST)
Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2  (651.2 6-10-1998))  id 65256966.00142970 ; Tue, 26 Sep 2000 09:10:13 +0530
X-Lotus-FromDomain: HSSBLR
From: archow@hss.hns.com
To: "Jo Hornsby" 
Cc: archow@hss.hns.com, "Henning Schulzrinne" ,
        sip@lists.bell-labs.com
Message-ID: <65256966.001428F5.00@sampark.hss.hns.com>
Subject: RE: [SIP] The Null authentication scheme
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, 26 Sep 2000 09:10:11 +0530





jo> Imagine the following scenario:
jo> I make a SIP call from my UA, which is challenged.  The Realm of
jo> the challenge is unrecognised by my UA, so it gives me some sort
jo> of way to enter my credentials.  I have no credentials for this
jo> Realm, but I would like to try the call anyway.  With the normal
jo> "OK"/"Cancel" (use-this-username-password/hang-up-call) approach,
jo> what can I possibly do?  Having a `Null' scheme allows the UA
jo> to add an extra button: "Please take my call even though you don't
jo> know me".

Actually what I was pointing at was that if my client had made the call,
and the
server did support a "Null" Auth scheme, the first call itself would not be
rejected -
the server would see that the client had not supplied auth info, and so by
default goes
to the 'Null' handler anyway. Basically I see no harm in the server being
active in this
role rather than being passive.If it does not find an auth scheme, let it
go ahead and
put the call in its Null auth handler anyway. Why does it have to first
reject the call,
and only if the client specifies Null later it accepts it ?
I think this I-D suggestion comes into use if the server plays a passive
role.


Regds
Arjun
--
Arjun Roychowdhury @ Hughes Software Systems






"Jo Hornsby"  on 09/25/2000 07:15:28 PM

To:   archow, "Henning Schulzrinne" 
cc:   sip@lists.bell-labs.com

Subject:  RE: [SIP] The Null authentication scheme




> Hi, this seems to be useful if its the server who prompts the
> question of "I support Null, if you care".  However, if I take the
> approach of the client saying "Here is an unauthenticated request,
> process as you may" to the server:
>
> A client passes its authentication info to the server if it wants
> to. If it does not, and the server supports 'no authentication'
> scheme, it anyway proceeds to treat this request as an unknown.

Hmmm... I'm not sure that this is necessarily true.


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 Sep 26 02:47: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 CAA06828
	for ; Tue, 26 Sep 2000 02:47: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 2C7854433A; Tue, 26 Sep 2000 01:47:10 -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 0A01944339
	for ; Tue, 26 Sep 2000 01:46: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 CAA12843;
	Tue, 26 Sep 2000 02:48:31 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id ; Tue, 26 Sep 2000 02:43:16 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'archow@hss.hns.com'" ,
        "'Jo Hornsby'" 
Cc: "'Henning Schulzrinne'" ,
        "'sip@lists.bell-labs.com'" 
Subject: RE: [SIP] The Null authentication scheme
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, 26 Sep 2000 02:43:12 -0400




> -----Original Message-----
> From: archow@hss.hns.com [mailto:archow@hss.hns.com]
> Sent: Monday, September 25, 2000 11:40 PM
> To: Jo Hornsby
> Cc: archow@hss.hns.com; Henning Schulzrinne; sip@lists.bell-labs.com
> Subject: RE: [SIP] The Null authentication scheme
> 
> 
> 
> 
> 
> 
> jo> Imagine the following scenario:
> jo> I make a SIP call from my UA, which is challenged.  The Realm of
> jo> the challenge is unrecognised by my UA, so it gives me some sort
> jo> of way to enter my credentials.  I have no credentials for this
> jo> Realm, but I would like to try the call anyway.  With the normal
> jo> "OK"/"Cancel" (use-this-username-password/hang-up-call) approach,
> jo> what can I possibly do?  Having a `Null' scheme allows the UA
> jo> to add an extra button: "Please take my call even though you don't
> jo> know me".
> 
> Actually what I was pointing at was that if my client had 
> made the call,
> and the
> server did support a "Null" Auth scheme, the first call 
> itself would not be
> rejected -
> the server would see that the client had not supplied auth 
> info, and so by
> default goes
> to the 'Null' handler anyway.

No; if the server has services which require stronger authentication, it
might like to check if the user can supply real credentials. When a request
arrives with no Authorization at all, it can't know whether the UA has no
credentials at the server, or just hasn't supplied them yet. Thats what the
null case helps distinguish.

-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 Sep 26 04:27: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 EAA07744
	for ; Tue, 26 Sep 2000 04: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 ECC4B4433A; Tue, 26 Sep 2000 03:27: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 A8C2B44339
	for ; Tue, 26 Sep 2000 03:26:51 -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; 26 Sep 2000 08:27:09 UT
Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef)
	id JAA20114; Tue, 26 Sep 2000 09:24:56 +0100 (BST)
From: "Jo Hornsby" 
To: "Jonathan Rosenberg" , 
Cc: "'Henning Schulzrinne'" ,
        
Subject: RE: [SIP] The Null authentication scheme
Message-ID: <000101c02793$40e7e930$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: Tue, 26 Sep 2000 09:24:56 +0100
Content-Transfer-Encoding: 7bit

Hi,

I've just noticed a small discrepancy.

2617 specifies the following:
	challenge   = auth-scheme 1*SP 1#auth-param
which:
	challenge   _  "Null"
would seem to disobey.  It's a small problem, but it made me
think...

How about requiring that a Realm is specified along with the
Null challenge; this way, if a UA receives multiple challenges
(say due to a forking proxy), it will potentially be able to
pick a preferred Realm that it has no credentials for?


 - 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 Sep 26 05:14: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 FAA08013
	for ; Tue, 26 Sep 2000 05:14: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 252814433A; Tue, 26 Sep 2000 04:14:11 -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 DB99C44339
	for ; Tue, 26 Sep 2000 04:13:01 -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 ;
 Tue, 26 Sep 2000 02:11:00 -0700
From: "Simon Barber" 
To: 
Subject: RE: [SIP] Outbound call routing
Message-ID: 
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----=_NextPart_000_026D_01C0275F.7F647400"
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: <87A245E94948D3118DE30008C716B01301523B64@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: Tue, 26 Sep 2000 02:14:27 -0700

This is a multi-part message in MIME format.

------=_NextPart_000_026D_01C0275F.7F647400
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Terminology:

I have certainly helped confuse the issue by using unclear terminology -
specifically outbound server. Perhaps a clearer name might help the
discussion. Perhaps "home outbound proxy" HOB. This is a proxy server under
control of the user's home administrative domain, through which outbound
calls may be routed, to allow services on outbound calls. How this routing
is controlled and achieved is the subject of the discussion.

The problem is:

If the user is using a UA in a part of the network within his administrative
domain it is possible to arrange for his outbound calls to have some
processing applied under the control of his administrative domain, but if
the user is roaming in a network under another administrative domain there
is no mechanism for his home administrative domain to have any knowledge or
control of his outbound calls within the SIP specification.

A diagram:
(switch to a fixed pitch font to view this)

........................        ....................
  Administrative       :        :Administrative
  domain X             :        :domain A, a.com
                       :        :
User A ----- P1 ----- P2 ----- P3 ----- P4 (HOB)
                       :     /  :
.......................:    /   :...................
  Administrative       :   /
  domain B, b.com      :  /
                       : /
         User B ----- P5
                       :
.......................:

User A wishes to call User B - but the call must pass through proxy P4, user
A's home outbound server, so that a service can be applied to the call.

Simon Barber.



> -----Original Message-----
> From: sip-admin@lists.bell-labs.com
> [mailto:sip-admin@lists.bell-labs.com]On Behalf Of
> Jon.Peterson@Level3.com
> Sent: Monday, September 25, 2000 3:46 PM
> To: sip@lists.bell-labs.com
> Subject: RE: [SIP] Outbound call routing
>
>
>
> It seems to me that this discussion is considering two issues -
> firstly, how
> does a UA discover that it should use a particular PS as an
> outbound proxy,
> and secondly, how does the UA signal the first-hop and final
> destinations of
> the session in an INVITE. I think the second question can and should be
> considered independently from the first, as it has bearing on other
> architectures that require a very similar mechanism.
>
> For example, consider a case in which a UA sends an INVITE that reaches a
> local PS which then performs some sort of lookup and decides to
> forward the
> call to a remote PS in another administrative domain. In order to
> reach the
> remote PS, however, the local PS must send the call through a specific
> firewall - perhaps there are several firewalls in the local administrative
> domain, and one is a better way to reach the remote domain than
> the others.
> When it has made its decision about which specific firewall is
> the right one
> to traverse (which could have been discovered in any of a number of ways),
> it must use some mechanism in its signaling to the firewall to
> describe the
> first-hop server (the firewall itself) and the final destination
> (the remote
> PS). I see no reason why we couldn't use the same signaling mechanism for
> this that we would use in the UA-to-outbound-proxy case. It could be as
> simple as just sending the INVITE to the first-hop server with a
> Request-URI
> indicating the final destination. Or it could be, as has been suggested
> here, an early Route header (an idea that's fairly attractive to me). I'm
> not sure how this could be made compatible with DNS SRV records
> (for reasons
> similar to those brought up by Jo@ubiquity earlier in the thread), but I
> think SRV speaks more to the first issue than to the second anyway.
>
> As a bit of an aside, I'd also like to suggest that a UA should not break
> Record-Route regardless of any internally configured PS for outbound
> requests. That is, the outbound proxy routing mechanism should be
> consulted
> for new session requests only, not for requests associated with a
> pre-existing session. When the UA is the -caller-, if the outbound proxy
> chooses to add itself to the Record-Route, all future requests for the
> session will cross the outbound proxy, so this shouldn't be broken. What
> concerns me here are cases in which a UA is the -callee-, a Record-Route
> exists for the call that does not include the outbound proxy (for whatever
> reason), and the UA decides to a issue, say, a BYE, and is forced to break
> Record-Route in order to send it to the outbound proxy. This could lead to
> various problems. Ultimately, the inbound routing procedures should
> guarantee that the outbound proxy has the opportunity to
> Record-Route itself
> on the initial INVITE if this is appropriate; this shouldn't be
> retroactively enforced by a UA.
>
> Jon Peterson
> Level(3) Communications
>
> -----Original Message-----
> From: Simon Barber [mailto:simon@firetalk.com]
> Sent: Friday, September 22, 2000 6:48 PM
> To: Jo Hornsby; hch@ipdialog.com
> Cc: 'Sip@Lists. Bell-Labs. Com'
> Subject: RE: [SIP] Outbound call routing
>
>
> > > When a SIP message is first sent out from a UAC the requestURI could
> > > be set to the contents of the DNS SRV record "sipoutbound". When the
> > > INVITE reaches the user's outbound server, then the request URI
> > > would be set to the contents of the to: header. This assumes that
> > > the UA always wants the request routed to the to: header. Is this
> > > always true?
> >
> > I would say very likely to be true, for an initial INVITE.  I
> > would stay away from "always", however. &:)
>
> A valid argument. We should maintain the ability of the UAC to set
> the requestURI of the invite to whatever it wants.
>
> >
> > > This also changes the handling of the to: header. It is
> > > now not interpreted by the proxy servers between the terminal and
> > > the user's outbound server. This means that local semantics will not
> > > be applied. I guess sometimes this is good, sometimes bad!
> >
> > This is slightly problematic; how does a proxy know that it is
> > supposed to be interpreting the To: instead of the Request-URI?
> > Although I guess it's only the first proxy (the "home" proxy?)
> > after the firewall prox(y|ies) that needs to know that To is
> > overriding.  Hmmm...
> >
> > [...]
> > > Using the SRV record has the advantage that the UA does not need to
> > > be registered before outbound calling will work correctly. I see
> > > this decoupling of outbound and inbound calling as an important
> > > advantage.
> >
> > Using the SRV record also has the disadvantage that someone has to
> > be responsible for configuring the record for a user's address,
> > and since the granularity is at a domain level, this isn't that
> > flexible (I might like to have my own "outbound" proxy, that I'd
> > written with my own funky features, for instance).
>
> Hisham - Apologies, I have misunderstood your meaning for outbound server.
> By outbound server I mean a server that is part of my domain, that all my
> outbound requests will pass though (whether I am originating
> those requests
> from part of the network within my domain or not).
>
> I would suggest the sipoutbound SRV record is domain wide, not user
> specific - just like the SIP SRV record for incoming calls. If you
> want to use a specific server for your particular user, then you
> should have the server that handles the domain direct the request to
> a server that handles your particular user.
>
> Using a domain wide SRV record means that it's all or nothing for that
> domain, of course. This forces outbound requests to be routed
> like this for
> all users. Using the response to REGISTER means this is configurable on a
> user by user basis, but it does require the user be registered.
>
> >
> > The notion of using source routing mentioned earlier in this
> > thread, by embedding a Route header, as Anders and Sean suggested,
> > would seem to solve all of these problems, and it reuses existing
> > syntax quite nicely.  Plus -- as Sean pointed out -- it generalises
> > to multiple proxies; not to mention the possibilities with implying
> > other headers (State perhaps?).
> >
>
> Route does seem to be a neat solution. Excuse my ignorance, but
> why does it
> have to be embedded in the requestURI?
>
> Indeed I am not sure that we even need a separate SRV record for
> outbound and inbound calls at all. Why not simply say that a Route:
> header for initial requests should be set to the sip URL for the
> user making the request (normally also the contents of the From:
> header.).
>
> This way all outbound requests pass through the same server that
> handles the user's inbound calls. This should be completely compatible
> with current procedures. It does tie the server which handles services
> for outbound calls to the same server that handles services for inbound
> calls, but is this a problem?
>
> This also means that this form of outbound routing is used for all SIP
> requests, irrespective of whether this is required for services or not.
>
> In summary, 3 approaches:
>
> 1) configuration using REGISTER
> - outbound routing can be controlled on a per specific registration basis
>
> 2) configuration using SRV record
> - outbound routing can be controlled on a per domain basis
>
> 3) always route through user's home server
> - no option not to route through user's home server
>
> or
>
> 4) other method?
>
>
>
> > Do you forsee any problems with this approach?
>
> Seems very sensible!
>
> >
> > Cheers,
> >
> >
> >  - Jo.
>
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip
>

------=_NextPart_000_026D_01C0275F.7F647400
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_026D_01C0275F.7F647400--


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


From sip-admin@lists.bell-labs.com  Tue Sep 26 06:14: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 GAA08350
	for ; Tue, 26 Sep 2000 06:14: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 EAC3C4433A; Tue, 26 Sep 2000 05:14:10 -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 5355744339
	for ; Tue, 26 Sep 2000 05:12:09 -0400 (EDT)
Received: from armorse (PPP-179-52.bng.vsnl.net.in [203.197.179.52]) by mail.in.huawei.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21)
	id S7TKDTAR; Tue, 26 Sep 2000 15:43:57 +0530
Reply-To: 
From: "Bodgey" 
To: 
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.00.2919.6600
Subject: [SIP] About reponse authenticate:
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
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, 26 Sep 2000 15:43:08 +0530
Content-Transfer-Encoding: 7bit

Hi,
   In section 13.2.1 of RFC2543bis-02,there describe the problem of response
authenticating. It is difficult to understand "The correct behaviour in such
a case would be for the called-user to form a dated response containing the
Contact field to be used, to sign it, and give this signed stub response to
the proxy that will provide the redirection, thus the response can be
authenticated correctly".How to sign it? would someone explain it detailed
in order to indicate how to authenticate the response? Thanks!
    The other question is the header "WWW-authenticate" is a response
header,but in example of section 14.1, why it in the request? Is there
error?

Bodgey


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


From sip-admin@lists.bell-labs.com  Tue Sep 26 07:39: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 HAA08983
	for ; Tue, 26 Sep 2000 07:39: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 79F354433A; Tue, 26 Sep 2000 06:39:10 -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 F423F44339
	for ; Tue, 26 Sep 2000 03:00:55 -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 DAA06780;
	Tue, 26 Sep 2000 03:00:45 -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 DAA17876;
	Tue, 26 Sep 2000 03:00:44 -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 DAA19818; Tue, 26 Sep 2000 03:00:43 -0500 (CDT)
Message-ID: <39D057A8.58B07A5F@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: Jon.Peterson@Level3.com
Cc: sip@lists.bell-labs.com
Subject: Re: [SIP] Expressing multiple choices in INVITE?
References: <87A245E94948D3118DE30008C716B01301523B63@c0005v1idc1.oss.level3.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, 26 Sep 2000 10:00:41 +0200
Content-Transfer-Encoding: 7bit

Comments inline
Sean
--
Sean Olson 

Jon.Peterson@Level3.com wrote:

> I've been shopping around for a mechanism in SIP that will allow me to send
> multiple target URIs in a single INVITE message to a UA. Consider, for
> example:
>
> UA1 sends out a SIP INVITE that eventually hits a redirect server which
> sends back a 300 with four Contact URIs. The first three URIs identify users
> (with qvalues) at UA2: harpo@ua2;q=0.1, chico@ua2;q=0.2, and
> groucho@ua2;q=0.5. Let's say that UA1 understands that it will perform a
> recursive sequential search. And also, for this to make sense, UA2 has to be
> an entity that manages multiple discrete users (like a PBX or some kind of
> gateway), and it must have made sense for the URI in the original INVITE to
> be mapped onto multiple possible termination URIs.

I'm assuming then that these N Contact URIs are all for literally the same
host/domain and not several aliases for the same node? (Are you
suggesting that this mechanism work for intermediate proxies as well?
Do you see the PBX as a proxy or a gateway?)

>
> Ordinarily, UA1 would first send an INVITE to groucho@ua2. If UA2 is unable
> to accept the session for any reason, it would return an appropriate status
> code, and then (if appropriate given the status) UA1 would send a new INVITE
> to UA2 for chico@ua2. If Chico weren't available Harpo would be tried in
> turn.
>
> What I'm looking for is a mechanism by which UA1 could send a single INVITE
> to UA2 containing the URIs for Groucho, Harpo and Chico, with their qvalues,
> in order to allow UA2 to try them all without any intermediate signaling as
> it traverses the choices. Presumably, only if none of the three were
> available would UA2 return a failure code to UA1. This could result in
> consideration optimization of signaling message exchange (hence cutting down
> on session setup time and whatnot) for relevant applications.

Are you against piggybacking of the SIP messages in a single packet?
I realize this solution is not ideal as SIP messages seem to be growing by
leaps and bounds with Route: headers, etc.

> It has been suggested to me that the Accept-Contact header specified in the
> callerprefs draft:
> http://www.ietf.org/internet-drafts/draft-ietf-sip-callerprefs-02.txt
> is relatively close to what is desired here. Using that header, one could
> construct a message like:
>
> INVITE sip:ua2.level3.net SIP/2.0
> ...
> Accept-Contact: sip:groucho@ua2.level3.net;q=0.5,
>                   sip:chico@ua2.level3.net;q=0.2,
>                   sip:harpo@ua2.level3.net;q=0.1
>
> This differs in a couple of ways from the assumptions of the callerprefs doc
> - the most salient difference being that in this example the target of this
> INVITE is a UA rather than a PS. Also, the user portion of the Request-URI
> is left unspecified - all destination addresses for the session are assumed
> to be in the Accept-Contact header.
>
> Does anyone have strong feelings for or against this method of expressing
> multiple choices in an INVITE? Any other suggestions for implementing this
> functionality?

Do you intend to allow Request-Disposition: as well? An alternative approach
would be to ship a CPL script along with the request -- not an attractive
approach, but possible :)


> Jon Peterson
> Level(3) Communications


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


From sip-admin@lists.bell-labs.com  Tue Sep 26 09:13: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 JAA09906
	for ; Tue, 26 Sep 2000 09:13: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 CFB064433A; Tue, 26 Sep 2000 08:13:10 -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 6CFFA44339
	for ; Tue, 26 Sep 2000 08:12: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 JAA15102;
	Tue, 26 Sep 2000 09:12:20 -0400 (EDT)
Message-ID: <39D0A0B4.6A4AA1B9@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: "'archow@hss.hns.com'" ,
        "'Jo Hornsby'" ,
        "'sip@lists.bell-labs.com'" 
Subject: Re: [SIP] The Null authentication scheme
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, 26 Sep 2000 09:12:20 -0400
Content-Transfer-Encoding: 7bit

Jonathan Rosenberg wrote:
> 

> 
> No; if the server has services which require stronger authentication, it
> might like to check if the user can supply real credentials. When a request
> arrives with no Authorization at all, it can't know whether the UA has no
> credentials at the server, or just hasn't supplied them yet. Thats what the
> null case helps distinguish.
> 

And to do this without keeping state.
-- 
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 Sep 26 09:45: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 JAA10200
	for ; Tue, 26 Sep 2000 09:45: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 767534433A; Tue, 26 Sep 2000 08:45:11 -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 5452A44339
	for ; Tue, 26 Sep 2000 08:44:40 -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 JAA17167;
	Tue, 26 Sep 2000 09:44:27 -0400 (EDT)
Message-ID: <39D0A83B.F670CBAD@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: Jo Hornsby 
Cc: sip@lists.bell-labs.com
Subject: Re: [SIP] The Null authentication scheme
References: <000101c02793$40e7e930$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, 26 Sep 2000 09:44:27 -0400
Content-Transfer-Encoding: 7bit

Jo Hornsby wrote:
> 
> Hi,
> 
> I've just noticed a small discrepancy.
> 
> 2617 specifies the following:
>         challenge   = auth-scheme 1*SP 1#auth-param
> which:
>         challenge   _  "Null"
> would seem to disobey.  It's a small problem, but it made me
> think...
> 
> How about requiring that a Realm is specified along with the
> Null challenge; this way, if a UA receives multiple challenges
> (say due to a forking proxy), it will potentially be able to
> pick a preferred Realm that it has no credentials for?

Indeed, I missed the sentence in 2617 that says

The authentication parameter realm is defined for all authentication
   schemes ...

Not sure what a realm means here, but it would allow to do something
like

realm="For unauthenticated calls"

I added this to the text.

-- 
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 Sep 26 10:10: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 KAA10437
	for ; Tue, 26 Sep 2000 10:10: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 661DB4433A; Tue, 26 Sep 2000 09:10: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 9953844339
	for ; Tue, 26 Sep 2000 09:09:23 -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 KAA14672;
	Tue, 26 Sep 2000 10:11:06 -0400 (EDT)
From: "Robert Sparks" 
To: "Tom-PT Taylor" , 
Message-ID: 
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0006_01C02798.FF62A120"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <28560036253BD41191A10000F8BCBD11480DE4@zcard00g.ca.nortel.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Subject: [SIP] RE: Referred-By: ...referenced-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, 26 Sep 2000 09:06:03 -0500

This is a multi-part message in MIME format.

------=_NextPart_000_0006_01C02798.FF62A120
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Referred-By: ...referenced-urlYes.

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


------=_NextPart_000_0006_01C02798.FF62A120
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Referred-By: ...referenced-url




Yes.


 


The=20
referenced party needs to be able to know, with proof, which of the =
headers=20
in


the=20
request it receives came from the referrer, and that those headers have =
not=20
been


modified.


 


RjS


  
-----Original Message-----
From: Tom-PT Taylor=20
  [mailto:taylor@nortelnetworks.com]
Sent: Monday, September =
25, 2000=20
  7:03 PM
To: sip@lists.bell-labs.com
Cc:=20
  'rsparks@dynamicsoft.com'
Subject: Referred-By:=20
  ...referenced-url


  
According to draft-ietf-sip-cc-transfer-01.txt, the=20
  referenced-url component of the Referred-By: header contains a copy of =
the URL=20
  transmitted in the Refer-To: header.  What if the Refer-To: URL =
contains=20
  headers (e.g. Accept-Contact:).  Are these also reproduced in=20
  Referred-By:, particularly as it appears in the REFER =
request?

  
Tom Taylor 


------=_NextPart_000_0006_01C02798.FF62A120--


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


From sip-admin@lists.bell-labs.com  Tue Sep 26 10:55: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 KAA10813
	for ; Tue, 26 Sep 2000 10:55: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 2B6E44433A; Tue, 26 Sep 2000 09:55: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 29E9744339
	for ; Tue, 26 Sep 2000 09:54: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 KAA15477;
	Tue, 26 Sep 2000 10:56:26 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id ; Tue, 26 Sep 2000 10:51:11 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'Henning Schulzrinne'" ,
        "'Jo Hornsby'" 
Cc: "'sip@lists.bell-labs.com'" 
Subject: RE: [SIP] The Null authentication scheme
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, 26 Sep 2000 10:51:09 -0400




> -----Original Message-----
> From: Henning Schulzrinne [mailto:schulzrinne@cs.columbia.edu]
> Sent: Tuesday, September 26, 2000 9:44 AM
> To: Jo Hornsby
> Cc: sip@lists.bell-labs.com
> Subject: Re: [SIP] The Null authentication scheme
> 
> 
> Jo Hornsby wrote:
> > 
> > Hi,
> > 
> > I've just noticed a small discrepancy.
> > 
> > 2617 specifies the following:
> >         challenge   = auth-scheme 1*SP 1#auth-param
> > which:
> >         challenge   _  "Null"
> > would seem to disobey.  It's a small problem, but it made me
> > think...
> > 
> > How about requiring that a Realm is specified along with the
> > Null challenge; this way, if a UA receives multiple challenges
> > (say due to a forking proxy), it will potentially be able to
> > pick a preferred Realm that it has no credentials for?
> 
> Indeed, I missed the sentence in 2617 that says
> 
> The authentication parameter realm is defined for all authentication
>    schemes ...
> 
> Not sure what a realm means here, but it would allow to do something
> like
> 
> realm="For unauthenticated calls"
> 
> I added this to the text.

I think realm should be what it always is; a token specific to the
challenging server.

The idea is that if there are two proxies on the path, each of which
requires proxy authorization, and I have credentials on just one, my
Proxy-Authorize header might look like:

Proxy-Authorize: Null realm="proxy1"
Proxy-Authorize: Digest realm="proxy2", username="Mufasa",
    response="6629fae49393a05397450978507c4ef1"

-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 Sep 26 11:26: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 LAA11076
	for ; Tue, 26 Sep 2000 11:26: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 2A8154433A; Tue, 26 Sep 2000 10:26:10 -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 D19AF44339
	for ; Tue, 26 Sep 2000 10:25:30 -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 e8QFPRt05043
	for ; Tue, 26 Sep 2000 17:25:27 +0200 (MEST)
Received: FROM esealnt743.al.sw.ericsson.se BY esealnt461 ; Tue Sep 26 17:19:26 2000 +0200
Received: by esealnt743.al.sw.ericsson.se with Internet Mail Service (5.5.2651.58)
	id ; Tue, 26 Sep 2000 17:25:26 +0200
Message-ID: <56E7307B0850D411B1480008C75DD5EAB73CC6@enlrynt303.dsn.ericsson.se>
From: "Arnoud van Wijk (ETM)" 
To: "'Simon Barber'" , sip@lists.bell-labs.com
Subject: RE: [SIP] Outbound call routing
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, 26 Sep 2000 17:25:24 +0200

Hello Simon,

Yes. I see the problem. I have been wrestling with similar architecture problems.
Right now, nothing can force the SIP messages from User A to go through P3 and P4.

I think that the solution will be in forcing the client of User A to use the registrar of the home domain of user A. And then have P4 add itself in the via header (route header).
This means that P4 receives the location search request from user A when A places a call to B, and P4 will then use the registrar to find the definite location of user B. Then P4 will send the SIP message with the IP address of user B's UA (via P5). But before P4 sends the SIP message, it will add itself to the via header or route header. (I am in a hurry, sorry for the sketchy details).

Bottomline is that a roaming user should never be allowed to use the current domain's location server/registrar. Always ONLY the homedomain's locator servers. And then it is just a matter of the insertion of the desired servers.

I will work this out in more detail if this is too unclear.

Arnoud van Wijk

______________________________________________________________
ERICSSON TELECOMMUNICATIE BV
Arnoud van Wijk
ABACUS Lab
Research & Development
Fax: +31-161 247569
_______________________________________________________________


-----Original Message-----
From: Simon Barber [mailto:simon@firetalk.com]
Sent: dinsdag 26 sep 2000 11:14
To: sip@lists.bell-labs.com
Subject: RE: [SIP] Outbound call routing


Terminology:

I have certainly helped confuse the issue by using unclear terminology -
specifically outbound server. Perhaps a clearer name might help the
discussion. Perhaps "home outbound proxy" HOB. This is a proxy server under
control of the user's home administrative domain, through which outbound
calls may be routed, to allow services on outbound calls. How this routing
is controlled and achieved is the subject of the discussion.

The problem is:

If the user is using a UA in a part of the network within his administrative
domain it is possible to arrange for his outbound calls to have some
processing applied under the control of his administrative domain, but if
the user is roaming in a network under another administrative domain there
is no mechanism for his home administrative domain to have any knowledge or
control of his outbound calls within the SIP specification.

A diagram:
(switch to a fixed pitch font to view this)

........................        ....................
  Administrative       :        :Administrative
  domain X             :        :domain A, a.com
                       :        :
User A ----- P1 ----- P2 ----- P3 ----- P4 (HOB)
                       :     /  :
.......................:    /   :...................
  Administrative       :   /
  domain B, b.com      :  /
                       : /
         User B ----- P5
                       :
.......................:

User A wishes to call User B - but the call must pass through proxy P4, user
A's home outbound server, so that a service can be applied to the call.

Simon Barber.



> -----Original Message-----
> From: sip-admin@lists.bell-labs.com
> [mailto:sip-admin@lists.bell-labs.com]On Behalf Of
> Jon.Peterson@Level3.com
> Sent: Monday, September 25, 2000 3:46 PM
> To: sip@lists.bell-labs.com
> Subject: RE: [SIP] Outbound call routing
>
>
>
> It seems to me that this discussion is considering two issues -
> firstly, how
> does a UA discover that it should use a particular PS as an
> outbound proxy,
> and secondly, how does the UA signal the first-hop and final
> destinations of
> the session in an INVITE. I think the second question can and should be
> considered independently from the first, as it has bearing on other
> architectures that require a very similar mechanism.
>
> For example, consider a case in which a UA sends an INVITE that reaches a
> local PS which then performs some sort of lookup and decides to
> forward the
> call to a remote PS in another administrative domain. In order to
> reach the
> remote PS, however, the local PS must send the call through a specific
> firewall - perhaps there are several firewalls in the local administrative
> domain, and one is a better way to reach the remote domain than
> the others.
> When it has made its decision about which specific firewall is
> the right one
> to traverse (which could have been discovered in any of a number of ways),
> it must use some mechanism in its signaling to the firewall to
> describe the
> first-hop server (the firewall itself) and the final destination
> (the remote
> PS). I see no reason why we couldn't use the same signaling mechanism for
> this that we would use in the UA-to-outbound-proxy case. It could be as
> simple as just sending the INVITE to the first-hop server with a
> Request-URI
> indicating the final destination. Or it could be, as has been suggested
> here, an early Route header (an idea that's fairly attractive to me). I'm
> not sure how this could be made compatible with DNS SRV records
> (for reasons
> similar to those brought up by Jo@ubiquity earlier in the thread), but I
> think SRV speaks more to the first issue than to the second anyway.
>
> As a bit of an aside, I'd also like to suggest that a UA should not break
> Record-Route regardless of any internally configured PS for outbound
> requests. That is, the outbound proxy routing mechanism should be
> consulted
> for new session requests only, not for requests associated with a
> pre-existing session. When the UA is the -caller-, if the outbound proxy
> chooses to add itself to the Record-Route, all future requests for the
> session will cross the outbound proxy, so this shouldn't be broken. What
> concerns me here are cases in which a UA is the -callee-, a Record-Route
> exists for the call that does not include the outbound proxy (for whatever
> reason), and the UA decides to a issue, say, a BYE, and is forced to break
> Record-Route in order to send it to the outbound proxy. This could lead to
> various problems. Ultimately, the inbound routing procedures should
> guarantee that the outbound proxy has the opportunity to
> Record-Route itself
> on the initial INVITE if this is appropriate; this shouldn't be
> retroactively enforced by a UA.
>
> Jon Peterson
> Level(3) Communications
>
> -----Original Message-----
> From: Simon Barber [mailto:simon@firetalk.com]
> Sent: Friday, September 22, 2000 6:48 PM
> To: Jo Hornsby; hch@ipdialog.com
> Cc: 'Sip@Lists. Bell-Labs. Com'
> Subject: RE: [SIP] Outbound call routing
>
>
> > > When a SIP message is first sent out from a UAC the requestURI could
> > > be set to the contents of the DNS SRV record "sipoutbound". When the
> > > INVITE reaches the user's outbound server, then the request URI
> > > would be set to the contents of the to: header. This assumes that
> > > the UA always wants the request routed to the to: header. Is this
> > > always true?
> >
> > I would say very likely to be true, for an initial INVITE.  I
> > would stay away from "always", however. &:)
>
> A valid argument. We should maintain the ability of the UAC to set
> the requestURI of the invite to whatever it wants.
>
> >
> > > This also changes the handling of the to: header. It is
> > > now not interpreted by the proxy servers between the terminal and
> > > the user's outbound server. This means that local semantics will not
> > > be applied. I guess sometimes this is good, sometimes bad!
> >
> > This is slightly problematic; how does a proxy know that it is
> > supposed to be interpreting the To: instead of the Request-URI?
> > Although I guess it's only the first proxy (the "home" proxy?)
> > after the firewall prox(y|ies) that needs to know that To is
> > overriding.  Hmmm...
> >
> > [...]
> > > Using the SRV record has the advantage that the UA does not need to
> > > be registered before outbound calling will work correctly. I see
> > > this decoupling of outbound and inbound calling as an important
> > > advantage.
> >
> > Using the SRV record also has the disadvantage that someone has to
> > be responsible for configuring the record for a user's address,
> > and since the granularity is at a domain level, this isn't that
> > flexible (I might like to have my own "outbound" proxy, that I'd
> > written with my own funky features, for instance).
>
> Hisham - Apologies, I have misunderstood your meaning for outbound server.
> By outbound server I mean a server that is part of my domain, that all my
> outbound requests will pass though (whether I am originating
> those requests
> from part of the network within my domain or not).
>
> I would suggest the sipoutbound SRV record is domain wide, not user
> specific - just like the SIP SRV record for incoming calls. If you
> want to use a specific server for your particular user, then you
> should have the server that handles the domain direct the request to
> a server that handles your particular user.
>
> Using a domain wide SRV record means that it's all or nothing for that
> domain, of course. This forces outbound requests to be routed
> like this for
> all users. Using the response to REGISTER means this is configurable on a
> user by user basis, but it does require the user be registered.
>
> >
> > The notion of using source routing mentioned earlier in this
> > thread, by embedding a Route header, as Anders and Sean suggested,
> > would seem to solve all of these problems, and it reuses existing
> > syntax quite nicely.  Plus -- as Sean pointed out -- it generalises
> > to multiple proxies; not to mention the possibilities with implying
> > other headers (State perhaps?).
> >
>
> Route does seem to be a neat solution. Excuse my ignorance, but
> why does it
> have to be embedded in the requestURI?
>
> Indeed I am not sure that we even need a separate SRV record for
> outbound and inbound calls at all. Why not simply say that a Route:
> header for initial requests should be set to the sip URL for the
> user making the request (normally also the contents of the From:
> header.).
>
> This way all outbound requests pass through the same server that
> handles the user's inbound calls. This should be completely compatible
> with current procedures. It does tie the server which handles services
> for outbound calls to the same server that handles services for inbound
> calls, but is this a problem?
>
> This also means that this form of outbound routing is used for all SIP
> requests, irrespective of whether this is required for services or not.
>
> In summary, 3 approaches:
>
> 1) configuration using REGISTER
> - outbound routing can be controlled on a per specific registration basis
>
> 2) configuration using SRV record
> - outbound routing can be controlled on a per domain basis
>
> 3) always route through user's home server
> - no option not to route through user's home server
>
> or
>
> 4) other method?
>
>
>
> > Do you forsee any problems with this approach?
>
> Seems very sensible!
>
> >
> > 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 Sep 26 11:27: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 LAA11087
	for ; Tue, 26 Sep 2000 11:27: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 686E844377; Tue, 26 Sep 2000 10:26:28 -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 0EBF744339
	for ; Tue, 26 Sep 2000 10:25: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 LAA16410;
	Tue, 26 Sep 2000 11:27:47 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id ; Tue, 26 Sep 2000 11:22:31 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'Suresh Srinivas'" ,
        "'sip@lists.bell-labs.com'" 
Subject: RE: [SIP] Handling error conditions
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, 26 Sep 2000 11:22:27 -0400




> -----Original Message-----
> From: Suresh Srinivas [mailto:Suresh.srinivas@sylantro.com]
> Sent: Monday, September 25, 2000 7:42 PM
> To: sip@lists.bell-labs.com
> Subject: [SIP] Handling error conditions
> 
> 
> Could someone please validate if the following error 
> conditions are handled
> properly or 
> what is the right way to handle them. 
> 
> Regards,
> Suresh
> 
> New call origination:
> ---------------------
> Scenario 1:
>     - Sending INVITE failed at the UAC
>     - UAC did not receive response (or failed to parse 
> response) for INVITE
> Handling:
>    Give disconnect indication. Go to Idling state when user 
> disconnects the
> call.
> 

Probably a good idea to also send BYE. Since no ACK is being sent, the call
will timeout at the UAS, but BYE makes it faster and more robust.



> Scenario 2:
>    - Sending ACK (in response to 200 OK) failed at the UAC

There is no way to detect this case at the UAC.

> Handling:
>    Give disconnect indication. Go to Idling state when user 
> disconnects the
> call.
>                 OR
>    Continue with the call ?

THe UAS will never get the ACK, and thus the call times out at their end.
The UAC will probably think the call is up; session timer + human
interaction ("hello? hello!") will fix that.


> 
> Scenario 3:
>     - Sending response to INVITE failed at the UAS
>     - Did not receive ACK (or failed to parse ACK) for the 
> final response at
> the UAS
> Handling:
>    Disconnect the call and go to Idling state.

Yes.

> 
> Call is established, UAC sends INVITE to change the session params
> -------------------------------------------------------------------
> Scenario 1:
>     - Sending INVITE failed at the UAC
>     - UAC did not receive response (or failed to parse 
> response) for INVITE
>     - Sending ACK (in response to 200 OK) failed at the UAC
> Handling:
>     Give disconnect indication. Go to Idling state when user 
> disconnects the
> call.

No; just the transaction fails.


>                      OR
>     Return failure on the user interface for the action that 
> triggered 
>     the session parameter change and continue with the old session 
>     parameters ?

Yes.


> 
> Scenario 2:
>     - Sending response to INVITE failed at the UAS
>     - Did not receive ACK (or failed to parse ACK) for the final 
>       response at the UAS
> Handling:
>     Give disconnect indication. Go to Idling state when user 
> disconnects the
> call.

No.

>                      OR
>     Continue with the old session parameters ?

Yes. 

> 
> Call disconnection
> -------------------
> Scenario 1:
>     - Sending BYE failed at the UAC
>     - UAC did not receive response (or failed to parse 
> response) for BYE
> Handling:
>     Go to Idling

Yes.

> 
> Scenario 2:
>     - Sending response to BYE failed at the UAS
> Handling:
>     Go to Idling

Yes.


Might be worth documenting this in a little table for the bis draft, as it
does come up every once in a while. I can add a few more cases:


for each of initial invite, re-invite, bye, other requests:

  UAC never receives any response at all
  UAC receives provisional response, but no final response
  
  UAS sends final response, never gets an ACK

  proxy never receives any response at all
  proxy receives provisional response, no final response
  proxy sends final response, never gets an ACK

possible actions are:
  send CANCEL
  send BYE
  ignore transaction
  terminate call


volunteers at a first cut? latex format preferred....

-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 Sep 26 11: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 LAA11312
	for ; Tue, 26 Sep 2000 11: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 7C2984437E; Tue, 26 Sep 2000 10:43: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 AF5F74437D
	for ; Tue, 26 Sep 2000 10:43: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 LAA16681;
	Tue, 26 Sep 2000 11:44:47 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id ; Tue, 26 Sep 2000 11:39:32 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'Rosen, Brian'" ,
        Jonathan Rosenberg ,
        "'pmurthy@hss.hns.com'" ,
        "'sip@lists.bell-labs.com'" 
Subject: RE: [SIP] A 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: Tue, 26 Sep 2000 11:39:23 -0400




> -----Original Message-----
> From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
> Sent: Monday, September 25, 2000 2:08 PM
> To: 'Jonathan Rosenberg'; 'pmurthy@hss.hns.com';
> 'sip@lists.bell-labs.com'
> Subject: RE: [SIP] A Clarification
> 
> 
> While I like 1), I think we may need to do 2).
> If the requestor doesn't need to challenge, but the
> responder does....

You lost me here; the responder (the UAS), issuing a challenge
is covered already by the standard request authentication case.

> 
> I'm a bit off from being able to sign up to implement such
> a feature, but that looks like what we have to do.
> 
> I could probably live with 1) if there were a lot of problems.

Well, here is a problem we encountered with challenge-response on responses.

Basically, there is no analag to proxy-authentication for responses. That
is, the proxy can't challenge the UAS for credentials for the response. Its
just horrible, if not impossible, in a request-response model.

The solution is that if the response is just signed with the key of the UAS,
any proxy along the response path could authenticate 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 Sep 26 11:47: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 LAA11357
	for ; Tue, 26 Sep 2000 11: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 388204433A; Tue, 26 Sep 2000 10:47:11 -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 2020844339
	for ; Tue, 26 Sep 2000 10:46:53 -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 LAA25278;
	Tue, 26 Sep 2000 11:46:24 -0400 (EDT)
Message-ID: <39D0C4D0.6260DEF3@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: "Arnoud van Wijk (ETM)" 
Cc: "'Simon Barber'" , sip@lists.bell-labs.com
Subject: Re: [SIP] Outbound call routing
References: <56E7307B0850D411B1480008C75DD5EAB73CC6@enlrynt303.dsn.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, 26 Sep 2000 11:46:24 -0400
Content-Transfer-Encoding: 7bit

"Arnoud van Wijk (ETM)" wrote:
> 
> Hello Simon,
> 
> Yes. I see the problem. I have been wrestling with similar architecture problems.
> Right now, nothing can force the SIP messages from User A to go through P3 and P4.
> 
> I think that the solution will be in forcing the client of User A to use the registrar of the home domain of user A. And then have P4 add itself in the via header (route header).
> This means that P4 receives the location search request from user A when A places a call to B, and P4 will then use the registrar to find the definite location of user B. Then P4 will send the SIP message with the IP address of user B's UA (via P5). But before P4 sends the SIP message, it will add itself to the via header or route header. (I am in a hurry, sorry for the sketchy details).
> 
> Bottomline is that a roaming user should never be allowed to use the current domain's location server/registrar. Always ONLY the homedomain's locator servers. And then it is just a matter of the insertion of the desired servers.

This is a fundamentally broken idea. This is not your grandpa's phone
network. Any notion of "forcing" clients to do anything is just not a
workable proposition in the Internet. In some circumstances, using the
current ("visited") registrar makes perfect sense, so I see no reason to
prohibit that.


> 
> I will work this out in more detail if this is too unclear.
> 

> Terminology:
> 
> I have certainly helped confuse the issue by using unclear terminology -
> specifically outbound server. Perhaps a clearer name might help the
> discussion. Perhaps "home outbound proxy" HOB. This is a proxy server under
> control of the user's home administrative domain, through which outbound
> calls may be routed, to allow services on outbound calls. How this routing
> is controlled and achieved is the subject of the discussion.
> 
> The problem is:
> 
> If the user is using a UA in a part of the network within his administrative
> domain it is possible to arrange for his outbound calls to have some
> processing applied under the control of his administrative domain, but if
> the user is roaming in a network under another administrative domain there
> is no mechanism for his home administrative domain to have any knowledge or
> control of his outbound calls within the SIP specification.
> 
> A diagram:
> (switch to a fixed pitch font to view this)
> 
> ........................        ....................
>   Administrative       :        :Administrative
>   domain X             :        :domain A, a.com
>                        :        :
> User A ----- P1 ----- P2 ----- P3 ----- P4 (HOB)
>                        :     /  :
> .......................:    /   :...................
>   Administrative       :   /
>   domain B, b.com      :  /
>                        : /
>          User B ----- P5
>                        :
> .......................:
> 
> User A wishes to call User B - but the call must pass through proxy P4, user
> A's home outbound server, so that a service can be applied to the call.
> 
> Simon Barber.
> 
> > -----Original Message-----
> > From: sip-admin@lists.bell-labs.com
> > [mailto:sip-admin@lists.bell-labs.com]On Behalf Of
> > Jon.Peterson@Level3.com
> > Sent: Monday, September 25, 2000 3:46 PM
> > To: sip@lists.bell-labs.com
> > Subject: RE: [SIP] Outbound call routing
> >
> >
> >
> > It seems to me that this discussion is considering two issues -
> > firstly, how
> > does a UA discover that it should use a particular PS as an
> > outbound proxy,
> > and secondly, how does the UA signal the first-hop and final
> > destinations of
> > the session in an INVITE. I think the second question can and should be
> > considered independently from the first, as it has bearing on other
> > architectures that require a very similar mechanism.
> >
> > For example, consider a case in which a UA sends an INVITE that reaches a
> > local PS which then performs some sort of lookup and decides to
> > forward the
> > call to a remote PS in another administrative domain. In order to
> > reach the
> > remote PS, however, the local PS must send the call through a specific
> > firewall - perhaps there are several firewalls in the local administrative
> > domain, and one is a better way to reach the remote domain than
> > the others.
> > When it has made its decision about which specific firewall is
> > the right one
> > to traverse (which could have been discovered in any of a number of ways),
> > it must use some mechanism in its signaling to the firewall to
> > describe the
> > first-hop server (the firewall itself) and the final destination
> > (the remote
> > PS). I see no reason why we couldn't use the same signaling mechanism for
> > this that we would use in the UA-to-outbound-proxy case. It could be as
> > simple as just sending the INVITE to the first-hop server with a
> > Request-URI
> > indicating the final destination. Or it could be, as has been suggested
> > here, an early Route header (an idea that's fairly attractive to me). I'm
> > not sure how this could be made compatible with DNS SRV records
> > (for reasons
> > similar to those brought up by Jo@ubiquity earlier in the thread), but I
> > think SRV speaks more to the first issue than to the second anyway.
> >
> > As a bit of an aside, I'd also like to suggest that a UA should not break
> > Record-Route regardless of any internally configured PS for outbound
> > requests. That is, the outbound proxy routing mechanism should be
> > consulted
> > for new session requests only, not for requests associated with a
> > pre-existing session. When the UA is the -caller-, if the outbound proxy
> > chooses to add itself to the Record-Route, all future requests for the
> > session will cross the outbound proxy, so this shouldn't be broken. What
> > concerns me here are cases in which a UA is the -callee-, a Record-Route
> > exists for the call that does not include the outbound proxy (for whatever
> > reason), and the UA decides to a issue, say, a BYE, and is forced to break
> > Record-Route in order to send it to the outbound proxy. This could lead to
> > various problems. Ultimately, the inbound routing procedures should
> > guarantee that the outbound proxy has the opportunity to
> > Record-Route itself
> > on the initial INVITE if this is appropriate; this shouldn't be
> > retroactively enforced by a UA.
> >
> > Jon Peterson
> > Level(3) Communications
> >
> > -----Original Message-----
> > From: Simon Barber [mailto:simon@firetalk.com]
> > Sent: Friday, September 22, 2000 6:48 PM
> > To: Jo Hornsby; hch@ipdialog.com
> > Cc: 'Sip@Lists. Bell-Labs. Com'
> > Subject: RE: [SIP] Outbound call routing
> >
> >
> > > > When a SIP message is first sent out from a UAC the requestURI could
> > > > be set to the contents of the DNS SRV record "sipoutbound". When the
> > > > INVITE reaches the user's outbound server, then the request URI
> > > > would be set to the contents of the to: header. This assumes that
> > > > the UA always wants the request routed to the to: header. Is this
> > > > always true?
> > >
> > > I would say very likely to be true, for an initial INVITE.  I
> > > would stay away from "always", however. &:)
> >
> > A valid argument. We should maintain the ability of the UAC to set
> > the requestURI of the invite to whatever it wants.
> >
> > >
> > > > This also changes the handling of the to: header. It is
> > > > now not interpreted by the proxy servers between the terminal and
> > > > the user's outbound server. This means that local semantics will not
> > > > be applied. I guess sometimes this is good, sometimes bad!
> > >
> > > This is slightly problematic; how does a proxy know that it is
> > > supposed to be interpreting the To: instead of the Request-URI?
> > > Although I guess it's only the first proxy (the "home" proxy?)
> > > after the firewall prox(y|ies) that needs to know that To is
> > > overriding.  Hmmm...
> > >
> > > [...]
> > > > Using the SRV record has the advantage that the UA does not need to
> > > > be registered before outbound calling will work correctly. I see
> > > > this decoupling of outbound and inbound calling as an important
> > > > advantage.
> > >
> > > Using the SRV record also has the disadvantage that someone has to
> > > be responsible for configuring the record for a user's address,
> > > and since the granularity is at a domain level, this isn't that
> > > flexible (I might like to have my own "outbound" proxy, that I'd
> > > written with my own funky features, for instance).
> >
> > Hisham - Apologies, I have misunderstood your meaning for outbound server.
> > By outbound server I mean a server that is part of my domain, that all my
> > outbound requests will pass though (whether I am originating
> > those requests
> > from part of the network within my domain or not).
> >
> > I would suggest the sipoutbound SRV record is domain wide, not user
> > specific - just like the SIP SRV record for incoming calls. If you
> > want to use a specific server for your particular user, then you
> > should have the server that handles the domain direct the request to
> > a server that handles your particular user.
> >
> > Using a domain wide SRV record means that it's all or nothing for that
> > domain, of course. This forces outbound requests to be routed
> > like this for
> > all users. Using the response to REGISTER means this is configurable on a
> > user by user basis, but it does require the user be registered.
> >
> > >
> > > The notion of using source routing mentioned earlier in this
> > > thread, by embedding a Route header, as Anders and Sean suggested,
> > > would seem to solve all of these problems, and it reuses existing
> > > syntax quite nicely.  Plus -- as Sean pointed out -- it generalises
> > > to multiple proxies; not to mention the possibilities with implying
> > > other headers (State perhaps?).
> > >
> >
> > Route does seem to be a neat solution. Excuse my ignorance, but
> > why does it
> > have to be embedded in the requestURI?
> >
> > Indeed I am not sure that we even need a separate SRV record for
> > outbound and inbound calls at all. Why not simply say that a Route:
> > header for initial requests should be set to the sip URL for the
> > user making the request (normally also the contents of the From:
> > header.).
> >
> > This way all outbound requests pass through the same server that
> > handles the user's inbound calls. This should be completely compatible
> > with current procedures. It does tie the server which handles services
> > for outbound calls to the same server that handles services for inbound
> > calls, but is this a problem?
> >
> > This also means that this form of outbound routing is used for all SIP
> > requests, irrespective of whether this is required for services or not.
> >
> > In summary, 3 approaches:
> >
> > 1) configuration using REGISTER
> > - outbound routing can be controlled on a per specific registration basis
> >
> > 2) configuration using SRV record
> > - outbound routing can be controlled on a per domain basis
> >
> > 3) always route through user's home server
> > - no option not to route through user's home server
> >
> > or
> >
> > 4) other method?
> >
> >
> >
> > > Do you forsee any problems with this approach?
> >
> > Seems very sensible!
> >
> > >
> > > 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

-- 
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 Sep 26 12: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 MAA12411
	for ; Tue, 26 Sep 2000 12:54: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 9A7B44433A; Tue, 26 Sep 2000 11:54:10 -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 F1CE544339
	for ; Tue, 26 Sep 2000 11:53:30 -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 QAA20032;
	Tue, 26 Sep 2000 16:53:26 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 KAA24870;
	Tue, 26 Sep 2000 10:53:17 -0600 (MDT)
Received: by n0195idc1.oss.level3.com with Internet Mail Service (5.5.2650.21)
	id ; Tue, 26 Sep 2000 10:55:07 -0600
Message-ID: <87A245E94948D3118DE30008C716B01301523B66@c0005v1idc1.oss.level3.com>
To: sean.olson@ericsson.com
Cc: sip@lists.bell-labs.com
Subject: RE: [SIP] Expressing multiple choices in INVITE?
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, 26 Sep 2000 10:53:12 -0600


In reference to the notes inline below:

Yes, I am assuming that each of the URIs are literally for the same host -
again, the original URI would have to yield multiple discrete termination
points for this to be meaningful, but I think examples of this abound in IP
telephony services. A PBX could be implemented as a proxy (for other UAs) or
a gateway UA (to conventional phones for which it performs translations) -
I'm considering the latter case here. Were I considering this functionality
for a proxy, this wouldn't be quite as problematic.

Piggybacking the three INVITE messages into a single packet would work for a
parallel search - or at least, it would be more efficient than sending three
messages in separate packets. The size of the packets is a lesser concern, I
think. The problem I'm exploring, though, is eliminating the need for an
exchange between UA1 and UA2 (and specifically for the sequential search
case, in which piggybacking isn't as meaningful - the qvalues in the 300
specify priorities for the route choices, and hence they should be tried
one-by-one in order). So in other words, I would like to prevent unnecessary
backwards messaging from UA2 to UA1 as well as consolidation of signaling
from UA1 to UA2. The whole idea is to optimize the exchange of messages
between these two entities.

As for the Request-Disposition, it could be used to indicate that the search
should be sequential and so forth, but once again I think the draft is
oriented towards how a proxy should behave, rather than how a UA should
behave. But this does beg a good question - if a UA can parse
Accept-Contact, why not Request-Disposition, and why not the whole
callerprefs draft? It isn't clear now what kinds of complications might
arise from extending callerprefs to full support for UAs.

As for CPL, I'd like to think a UA could figure out how to try a few URIs
without having to execute a script... :) 

Jon Peterson
Level(3) Communications

-----Original Message-----
From: Sean Olson [mailto:sean.olson@ericsson.com]
Sent: Tuesday, September 26, 2000 2:01 AM
To: Peterson, Jon
Cc: sip@lists.bell-labs.com
Subject: Re: [SIP] Expressing multiple choices in INVITE?


Comments inline
Sean
--
Sean Olson 

Jon.Peterson@Level3.com wrote:

> I've been shopping around for a mechanism in SIP that will allow me to
send
> multiple target URIs in a single INVITE message to a UA. Consider, for
> example:
>
> UA1 sends out a SIP INVITE that eventually hits a redirect server which
> sends back a 300 with four Contact URIs. The first three URIs identify
users
> (with qvalues) at UA2: harpo@ua2;q=0.1, chico@ua2;q=0.2, and
> groucho@ua2;q=0.5. Let's say that UA1 understands that it will perform a
> recursive sequential search. And also, for this to make sense, UA2 has to
be
> an entity that manages multiple discrete users (like a PBX or some kind of
> gateway), and it must have made sense for the URI in the original INVITE
to
> be mapped onto multiple possible termination URIs.

I'm assuming then that these N Contact URIs are all for literally the same
host/domain and not several aliases for the same node? (Are you
suggesting that this mechanism work for intermediate proxies as well?
Do you see the PBX as a proxy or a gateway?)

>
> Ordinarily, UA1 would first send an INVITE to groucho@ua2. If UA2 is
unable
> to accept the session for any reason, it would return an appropriate
status
> code, and then (if appropriate given the status) UA1 would send a new
INVITE
> to UA2 for chico@ua2. If Chico weren't available Harpo would be tried in
> turn.
>
> What I'm looking for is a mechanism by which UA1 could send a single
INVITE
> to UA2 containing the URIs for Groucho, Harpo and Chico, with their
qvalues,
> in order to allow UA2 to try them all without any intermediate signaling
as
> it traverses the choices. Presumably, only if none of the three were
> available would UA2 return a failure code to UA1. This could result in
> consideration optimization of signaling message exchange (hence cutting
down
> on session setup time and whatnot) for relevant applications.

Are you against piggybacking of the SIP messages in a single packet?
I realize this solution is not ideal as SIP messages seem to be growing by
leaps and bounds with Route: headers, etc.

> It has been suggested to me that the Accept-Contact header specified in
the
> callerprefs draft:
> http://www.ietf.org/internet-drafts/draft-ietf-sip-callerprefs-02.txt
> is relatively close to what is desired here. Using that header, one could
> construct a message like:
>
> INVITE sip:ua2.level3.net SIP/2.0
> ...
> Accept-Contact: sip:groucho@ua2.level3.net;q=0.5,
>                   sip:chico@ua2.level3.net;q=0.2,
>                   sip:harpo@ua2.level3.net;q=0.1
>
> This differs in a couple of ways from the assumptions of the callerprefs
doc
> - the most salient difference being that in this example the target of
this
> INVITE is a UA rather than a PS. Also, the user portion of the Request-URI
> is left unspecified - all destination addresses for the session are
assumed
> to be in the Accept-Contact header.
>
> Does anyone have strong feelings for or against this method of expressing
> multiple choices in an INVITE? Any other suggestions for implementing this
> functionality?

Do you intend to allow Request-Disposition: as well? An alternative approach
would be to ship a CPL script along with the request -- not an attractive
approach, but possible :)


> Jon Peterson
> Level(3) Communications


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
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 Sep 26 13:51: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 NAA13380
	for ; Tue, 26 Sep 2000 13:51: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 3248A4433A; Tue, 26 Sep 2000 12:51:10 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from microappliances.com (unknown [216.103.255.138])
	by lists.bell-labs.com (Postfix) with SMTP id 5E30D44339
	for ; Tue, 26 Sep 2000 12:50:14 -0400 (EDT)
Received: (qmail 92041 invoked by uid 100); 26 Sep 2000 17:50:03 -0000
Message-ID: <20000926175003.92040.qmail@microappliances.com>
From: shh@microappliances.com
To: Jonathan Rosenberg 
Reply-To: shh@microappliances.com
Cc: "'Suresh Srinivas'" , \@lists.bell-labs.com,
        "'sip@lists.bell-labs.com'\" "@lists.bell-labs.com
References: 
In-Reply-To: 
MIME-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 8bit
Subject: RE: [SIP] Handling error conditions
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: 26 Sep 2000 17:50:03 -0000
Content-Transfer-Encoding: 8bit


Jonathan,

> >
> > New call origination:
> > ---------------------
> > Scenario 1:
> >     - Sending INVITE failed at the UAC
> >     - UAC did not receive response (or failed to parse
> > response) for INVITE
> > Handling:
> >    Give disconnect indication. Go to Idling state when user
> > disconnects the
> > call.
> >
>
> Probably a good idea to also send BYE. Since no ACK is being sent, the call
> will timeout at the UAS, but BYE makes it faster and more robust.
>

I am curious to know why you prefer to send a BYE instead of a
CANCEL. If the 200 OK was not received, the Route is not established
and hence the BYE may be difficult to route properly.

If the UAC receives no response a UAC could timeout and send the CANCEL.

Thoughts?

Shiv


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


From sip-admin@lists.bell-labs.com  Tue Sep 26 13:58: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 NAA13427
	for ; Tue, 26 Sep 2000 13:58: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 E761F4433A; Tue, 26 Sep 2000 12:58: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 645574433A
	for ; Tue, 26 Sep 2000 10:52: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; 26 Sep 2000 15:52:50 UT
Received: from phoffer by ubiquity.net with SMTP (8.8.8+Sun/25-eef)
	id QAA07549; Tue, 26 Sep 2000 16:50:50 +0100 (BST)
Message-ID: <00df01c027d1$6da59470$5334c3c1@ubiquity.co.uk>
From: "Phil Hoffer" 
To: 
Subject: RE: [SIP] The Null authentication scheme
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_00DC_01C027D9.CF4E8530"
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, 26 Sep 2000 16:50:00 +0100

This is a multi-part message in MIME format.

------=_NextPart_000_00DC_01C027D9.CF4E8530
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,

Just a quick point/question?

Section 1.2 of rfc2617.txt states that the authenticating entity MUST =
include
a WWW-Authenticate (or Proxy-Authenticate) header with at least one =
challenge
applicable to the requested resource.

It goes on to state that the user agent responding to the challenge MUST =
choose to
use one of the challenges with the strongest auth-scheme it understands.

Consider then if a WWW-Authenticate header is returned with multiple =
challenges,
e.g. Digest and Null

Does the selection by the user agent break the "strongest challenge =
rule" if it chooses
to use the Null authentication scheme?

In the strictest terms I suppose it does.
However, I can also see the argument that the caller didn't get to =
contact the original callee directly.

Maybe a clarification is required !???

WDYT?

Phil

http://www.ubiquity.net


------=_NextPart_000_00DC_01C027D9.CF4E8530
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable









Hi,


 


Just a quick point/question?


 


Section 1.2 of rfc2617.txt states that the =
authenticating=20
entity MUST include


a WWW-Authenticate (or Proxy-Authenticate) header =
with at=20
least one challenge


applicable to the requested resource.


 


It goes on to state that the user agent responding =
to the=20
challenge MUST choose to


use one of the challenges with the strongest =
auth-scheme it=20
understands.


 


Consider then if a WWW-Authenticate header is =
returned with=20
multiple challenges,


e.g. Digest and Null


 


Does the selection by the user agent break the =
"strongest=20
challenge rule" if it chooses


to use the Null authentication scheme?


 


In the strictest terms I suppose it =
does.


However, I can also see the argument that the =
caller=20
didn't get to contact the original=20
callee directly.


 


Maybe a clarification is required !???


 


WDYT?


 


Phil


 


http://www.ubiquity.net
=


 


------=_NextPart_000_00DC_01C027D9.CF4E8530--


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


From sip-admin@lists.bell-labs.com  Tue Sep 26 14:30: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 OAA14009
	for ; Tue, 26 Sep 2000 14:30: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 6C2ED4433A; Tue, 26 Sep 2000 13:30:11 -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 CD8FE44339
	for ; Tue, 26 Sep 2000 13:29: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 ;
 Tue, 26 Sep 2000 11:27:01 -0700
From: "Simon Barber" 
To: "Henning Schulzrinne" ,
        "Arnoud van Wijk (ETM)" 
Cc: 
Subject: RE: [SIP] Outbound call routing
Message-ID: 
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----=_NextPart_000_0276_01C027AD.2D2AA990"
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: <39D0C4D0.6260DEF3@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: Tue, 26 Sep 2000 11:30:30 -0700

This is a multi-part message in MIME format.

------=_NextPart_000_0276_01C027AD.2D2AA990
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

> > Bottomline is that a roaming user should never be allowed to
> use the current domain's location server/registrar. Always ONLY
> the homedomain's locator servers. And then it is just a matter of
> the insertion of the desired servers.
>
> This is a fundamentally broken idea. This is not your grandpa's phone
> network. Any notion of "forcing" clients to do anything is just not a
> workable proposition in the Internet. In some circumstances, using the
> current ("visited") registrar makes perfect sense, so I see no reason to
> prohibit that.

Henning - It would be helpful to have example senarios.

Currently in SIP the REGISTER message is sent out twice - once multicast,
and once sent with a requestURI set to the address of the user who is being
registered. The multicast registration will be picked up by the local
registration server, and the one sent to the address of the user being
registered will be forwarded by any necessary proxies, just an an INVITE
would, to the user's home registration server.

Hopefully any proxies working with firewalls will be keeping state for the
registration, and re-writing the Contact: header so that calls in to the
user come through the firewall.
- are there issues to do with proxy selection? do we need record-route for
REGISTER?

Simon Barber

>
>
> >
> > I will work this out in more detail if this is too unclear.
> >
>
> > Terminology:
> >
> > I have certainly helped confuse the issue by using unclear terminology -
> > specifically outbound server. Perhaps a clearer name might help the
> > discussion. Perhaps "home outbound proxy" HOB. This is a proxy
> server under
> > control of the user's home administrative domain, through which outbound
> > calls may be routed, to allow services on outbound calls. How
> this routing
> > is controlled and achieved is the subject of the discussion.
> >
> > The problem is:
> >
> > If the user is using a UA in a part of the network within his
> administrative
> > domain it is possible to arrange for his outbound calls to have some
> > processing applied under the control of his administrative
> domain, but if
> > the user is roaming in a network under another administrative
> domain there
> > is no mechanism for his home administrative domain to have any
> knowledge or
> > control of his outbound calls within the SIP specification.
> >
> > A diagram:
> > (switch to a fixed pitch font to view this)
> >
> > ........................        ....................
> >   Administrative       :        :Administrative
> >   domain X             :        :domain A, a.com
> >                        :        :
> > User A ----- P1 ----- P2 ----- P3 ----- P4 (HOB)
> >                        :     /  :
> > .......................:    /   :...................
> >   Administrative       :   /
> >   domain B, b.com      :  /
> >                        : /
> >          User B ----- P5
> >                        :
> > .......................:
> >
> > User A wishes to call User B - but the call must pass through
> proxy P4, user
> > A's home outbound server, so that a service can be applied to the call.
> >
> > Simon Barber.
> >
> > > -----Original Message-----
> > > From: sip-admin@lists.bell-labs.com
> > > [mailto:sip-admin@lists.bell-labs.com]On Behalf Of
> > > Jon.Peterson@Level3.com
> > > Sent: Monday, September 25, 2000 3:46 PM
> > > To: sip@lists.bell-labs.com
> > > Subject: RE: [SIP] Outbound call routing
> > >
> > >
> > >
> > > It seems to me that this discussion is considering two issues -
> > > firstly, how
> > > does a UA discover that it should use a particular PS as an
> > > outbound proxy,
> > > and secondly, how does the UA signal the first-hop and final
> > > destinations of
> > > the session in an INVITE. I think the second question can and
> should be
> > > considered independently from the first, as it has bearing on other
> > > architectures that require a very similar mechanism.
> > >
> > > For example, consider a case in which a UA sends an INVITE
> that reaches a
> > > local PS which then performs some sort of lookup and decides to
> > > forward the
> > > call to a remote PS in another administrative domain. In order to
> > > reach the
> > > remote PS, however, the local PS must send the call through a specific
> > > firewall - perhaps there are several firewalls in the local
> administrative
> > > domain, and one is a better way to reach the remote domain than
> > > the others.
> > > When it has made its decision about which specific firewall is
> > > the right one
> > > to traverse (which could have been discovered in any of a
> number of ways),
> > > it must use some mechanism in its signaling to the firewall to
> > > describe the
> > > first-hop server (the firewall itself) and the final destination
> > > (the remote
> > > PS). I see no reason why we couldn't use the same signaling
> mechanism for
> > > this that we would use in the UA-to-outbound-proxy case. It
> could be as
> > > simple as just sending the INVITE to the first-hop server with a
> > > Request-URI
> > > indicating the final destination. Or it could be, as has been
> suggested
> > > here, an early Route header (an idea that's fairly attractive
> to me). I'm
> > > not sure how this could be made compatible with DNS SRV records
> > > (for reasons
> > > similar to those brought up by Jo@ubiquity earlier in the
> thread), but I
> > > think SRV speaks more to the first issue than to the second anyway.
> > >
> > > As a bit of an aside, I'd also like to suggest that a UA
> should not break
> > > Record-Route regardless of any internally configured PS for outbound
> > > requests. That is, the outbound proxy routing mechanism should be
> > > consulted
> > > for new session requests only, not for requests associated with a
> > > pre-existing session. When the UA is the -caller-, if the
> outbound proxy
> > > chooses to add itself to the Record-Route, all future requests for the
> > > session will cross the outbound proxy, so this shouldn't be
> broken. What
> > > concerns me here are cases in which a UA is the -callee-, a
> Record-Route
> > > exists for the call that does not include the outbound proxy
> (for whatever
> > > reason), and the UA decides to a issue, say, a BYE, and is
> forced to break
> > > Record-Route in order to send it to the outbound proxy. This
> could lead to
> > > various problems. Ultimately, the inbound routing procedures should
> > > guarantee that the outbound proxy has the opportunity to
> > > Record-Route itself
> > > on the initial INVITE if this is appropriate; this shouldn't be
> > > retroactively enforced by a UA.
> > >
> > > Jon Peterson
> > > Level(3) Communications
> > >
> > > -----Original Message-----
> > > From: Simon Barber [mailto:simon@firetalk.com]
> > > Sent: Friday, September 22, 2000 6:48 PM
> > > To: Jo Hornsby; hch@ipdialog.com
> > > Cc: 'Sip@Lists. Bell-Labs. Com'
> > > Subject: RE: [SIP] Outbound call routing
> > >
> > >
> > > > > When a SIP message is first sent out from a UAC the
> requestURI could
> > > > > be set to the contents of the DNS SRV record
> "sipoutbound". When the
> > > > > INVITE reaches the user's outbound server, then the request URI
> > > > > would be set to the contents of the to: header. This assumes that
> > > > > the UA always wants the request routed to the to: header. Is this
> > > > > always true?
> > > >
> > > > I would say very likely to be true, for an initial INVITE.  I
> > > > would stay away from "always", however. &:)
> > >
> > > A valid argument. We should maintain the ability of the UAC to set
> > > the requestURI of the invite to whatever it wants.
> > >
> > > >
> > > > > This also changes the handling of the to: header. It is
> > > > > now not interpreted by the proxy servers between the terminal and
> > > > > the user's outbound server. This means that local
> semantics will not
> > > > > be applied. I guess sometimes this is good, sometimes bad!
> > > >
> > > > This is slightly problematic; how does a proxy know that it is
> > > > supposed to be interpreting the To: instead of the Request-URI?
> > > > Although I guess it's only the first proxy (the "home" proxy?)
> > > > after the firewall prox(y|ies) that needs to know that To is
> > > > overriding.  Hmmm...
> > > >
> > > > [...]
> > > > > Using the SRV record has the advantage that the UA does
> not need to
> > > > > be registered before outbound calling will work correctly. I see
> > > > > this decoupling of outbound and inbound calling as an important
> > > > > advantage.
> > > >
> > > > Using the SRV record also has the disadvantage that someone has to
> > > > be responsible for configuring the record for a user's address,
> > > > and since the granularity is at a domain level, this isn't that
> > > > flexible (I might like to have my own "outbound" proxy, that I'd
> > > > written with my own funky features, for instance).
> > >
> > > Hisham - Apologies, I have misunderstood your meaning for
> outbound server.
> > > By outbound server I mean a server that is part of my domain,
> that all my
> > > outbound requests will pass though (whether I am originating
> > > those requests
> > > from part of the network within my domain or not).
> > >
> > > I would suggest the sipoutbound SRV record is domain wide, not user
> > > specific - just like the SIP SRV record for incoming calls. If you
> > > want to use a specific server for your particular user, then you
> > > should have the server that handles the domain direct the request to
> > > a server that handles your particular user.
> > >
> > > Using a domain wide SRV record means that it's all or nothing for that
> > > domain, of course. This forces outbound requests to be routed
> > > like this for
> > > all users. Using the response to REGISTER means this is
> configurable on a
> > > user by user basis, but it does require the user be registered.
> > >
> > > >
> > > > The notion of using source routing mentioned earlier in this
> > > > thread, by embedding a Route header, as Anders and Sean suggested,
> > > > would seem to solve all of these problems, and it reuses existing
> > > > syntax quite nicely.  Plus -- as Sean pointed out -- it generalises
> > > > to multiple proxies; not to mention the possibilities with implying
> > > > other headers (State perhaps?).
> > > >
> > >
> > > Route does seem to be a neat solution. Excuse my ignorance, but
> > > why does it
> > > have to be embedded in the requestURI?
> > >
> > > Indeed I am not sure that we even need a separate SRV record for
> > > outbound and inbound calls at all. Why not simply say that a Route:
> > > header for initial requests should be set to the sip URL for the
> > > user making the request (normally also the contents of the From:
> > > header.).
> > >
> > > This way all outbound requests pass through the same server that
> > > handles the user's inbound calls. This should be completely compatible
> > > with current procedures. It does tie the server which handles services
> > > for outbound calls to the same server that handles services
> for inbound
> > > calls, but is this a problem?
> > >
> > > This also means that this form of outbound routing is used for all SIP
> > > requests, irrespective of whether this is required for
> services or not.
> > >
> > > In summary, 3 approaches:
> > >
> > > 1) configuration using REGISTER
> > > - outbound routing can be controlled on a per specific
> registration basis
> > >
> > > 2) configuration using SRV record
> > > - outbound routing can be controlled on a per domain basis
> > >
> > > 3) always route through user's home server
> > > - no option not to route through user's home server
> > >
> > > or
> > >
> > > 4) other method?
> > >
> > >
> > >
> > > > Do you forsee any problems with this approach?
> > >
> > > Seems very sensible!
> > >
> > > >
> > > > 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
>
> --
> 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_0276_01C027AD.2D2AA990
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_0276_01C027AD.2D2AA990--


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


From sip-admin@lists.bell-labs.com  Tue Sep 26 14:33: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 OAA14078
	for ; Tue, 26 Sep 2000 14:33: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 C98FC44373; Tue, 26 Sep 2000 13:33:10 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from microappliances.com (unknown [216.103.255.138])
	by lists.bell-labs.com (Postfix) with SMTP id D7FC744339
	for ; Tue, 26 Sep 2000 13:32:36 -0400 (EDT)
Received: (qmail 95665 invoked by uid 100); 26 Sep 2000 18:32:18 -0000
Message-ID: <20000926183218.95664.qmail@microappliances.com>
From: shh@microappliances.com
To: shh@microappliances.com
Reply-To: shh@microappliances.com
Cc: Jonathan Rosenberg ,
        "'Suresh Srinivas'" ,
        \@lists.bell-labs.com,
        "@lists.bell-labs.com\"@UNKNOWN.byo.com,   \"'sip@lists.bell-labs."@lists.bell-labs.com,
        "com'\\\""@lists.bell-labs.com,
        " ,   \"@lists.bell-labs.com"@lists.bell-labs.com
References:  <20000926175003.92040.qmail@microappliances.com>
In-Reply-To: <20000926175003.92040.qmail@microappliances.com>
MIME-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 8bit
Subject: RE: [SIP] Handling error conditions
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: 26 Sep 2000 18:32:18 -0000
Content-Transfer-Encoding: 8bit


Just to clarify my question further, my contention is
that the UAC is unaware of the fact that final responses
were generated for it, even though it did not see it for
some reason. Being unaware it may end up sending a CANCEL.

I do agree the proxies want to see a BYE.

So is it fair to say for the sake of
robustness, in general a BYE should be sent for cancelling an
INVITE and allow it to route the way INVITE got routed,
without the luxary of the \'Route\' information.

Shiv


Quoting shh@microappliances.com:

> 
> Jonathan,
>
> > >
> > > New call origination:
> > > ---------------------
> > > Scenario 1:
> > >     - Sending INVITE failed at the UAC
> > >     - UAC did not receive response (or failed to parse
> > > response) for INVITE
> > > Handling:
> > >    Give disconnect indication. Go to Idling state when user
> > > disconnects the
> > > call.
> > >
> >
> > Probably a good idea to also send BYE. Since no ACK is being sent, the
> call
> > will timeout at the UAS, but BYE makes it faster and more robust.
> >
>
> I am curious to know why you prefer to send a BYE instead of a
> CANCEL. If the 200 OK was not received, the Route is not established
> and hence the BYE may be difficult to route properly.
>
> If the UAC receives no response a UAC could timeout and send the CANCEL.
>
> Thoughts?
>
> Shiv
>
>
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> 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 Sep 26 16: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 QAA15865
	for ; Tue, 26 Sep 2000 16:55: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 C41A34433A; Tue, 26 Sep 2000 15:55:10 -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 62F6644339
	for ; Tue, 26 Sep 2000 15:54:20 -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 e8QKs7Z28207
	for ; Tue, 26 Sep 2000 22:54: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 XAA01977
	for ; Tue, 26 Sep 2000 23:54:07 +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 XAA01985
	for ; Tue, 26 Sep 2000 23:54:05 +0300 (EETDST)
Message-ID: <39D10CEF.81582ACC@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
References: <4FBEA8857476D311A03300204840E1CF01A6E71B@whq-msgusr-02.pit.com>
Content-Type: multipart/mixed;
 boundary="------------4C09C7206E794963C9DC0BBF"
Subject: [SIP] Session Timer 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, 26 Sep 2000 23:54:07 +0300

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


Hi,

I have a question about the session timer.

Since the session timer can be used even if one party supports it,
consider the following examples, where the UAS (but not the UAC)
supports it.

A.

UAC	UAS

--------->   INVITE

<---------   200 OK
	     Session-Expires: X


B.

UAC	UAS

--------->   INVITE

<---------   200 OK


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.

Regards,

Christer Holmberg
Ericsson Finland
--------------4C09C7206E794963C9DC0BBF
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

--------------4C09C7206E794963C9DC0BBF--


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


From sip-admin@lists.bell-labs.com  Tue Sep 26 17:27: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 RAA16194
	for ; Tue, 26 Sep 2000 17: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 032DA4433A; Tue, 26 Sep 2000 16:27:11 -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 5C2F044339
	for ; Tue, 26 Sep 2000 16:26:53 -0400 (EDT)
Received: from vovida.com ([209.237.8.113]) by pigeon.vovida.com
          (Netscape Messaging Server 4.15) with ESMTP id G1IJBO00.D04 for
          ; Tue, 26 Sep 2000 14:21:24 -0700 
Message-ID: <39D11492.911F1007@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="------------1843DF32BE78E456563B7D93"
Subject: [SIP] Informative responses for OPTIONS, and INFO requests
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
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, 26 Sep 2000 14:26:42 -0700


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

Could 100 Trying be sent as a response to these. The SIP RFC, and the
INFO draft specifies that a 200 MUST be sent from the UAS. However,
since the requests go through a proxy, allowing the proxy to send a 1xx
back, should be feasible.
Kindly let me know if this causes further problems.

thanks

--
Sunitha Kumar
http://www.vovida.com



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



Could 100 Trying be sent as a response to these. The SIP RFC, and the INFO
draft specifies that a 200 MUST be sent from the UAS. However, since the
requests go through a proxy, allowing the proxy to send a 1xx back, should
be feasible.

Kindly let me know if this causes further problems.

thanks

-- 
Sunitha Kumar
http://www.vovida.com

 

--------------1843DF32BE78E456563B7D93--


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


From sip-admin@lists.bell-labs.com  Tue Sep 26 17:39: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 RAA16328
	for ; Tue, 26 Sep 2000 17:39: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 942FE4433A; Tue, 26 Sep 2000 16:39:10 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from motgate3.mot.com (unknown [144.189.100.103])
	by lists.bell-labs.com (Postfix) with ESMTP id 1CDA944339
	for ; Tue, 26 Sep 2000 16:38:08 -0400 (EDT)
Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate3.mot.com (motgate3 2.1) with ESMTP id OAA28256 for ; Tue, 26 Sep 2000 14:35:25 -0700 (MST)]
Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id OAA25735 for ; Tue, 26 Sep 2000 14:37:49 -0700 (MST)]
Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2650.21)
	id ; Tue, 26 Sep 2000 16:37:49 -0500
Message-ID: 
From: Lewis Karl-QA3387 
To: "'Henning Schulzrinne'" ,
        sip@lists.bell-labs.com
Subject: RE: [SIP] Attempt at summarizing current SIP drafts
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, 26 Sep 2000 16:37:48 -0500

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


From sip-admin@lists.bell-labs.com  Tue Sep 26 17:43: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 RAA16442
	for ; Tue, 26 Sep 2000 17:43: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 D467344377; Tue, 26 Sep 2000 16:43:09 -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 733F54433A
	for ; Tue, 26 Sep 2000 16:42:07 -0400 (EDT)
Received: from tate ([216.181.56.35]) by broadsoft.com (8.8.8) id RAA80762; Tue, 26 Sep 2000 17:42:04 -0400 (EDT)
Message-ID: <00d901c02802$bc61b720$3202a8c0@broadsoft.com>
From: "Brett Tate" 
To: "sip bell labs" 
References: <39D11492.911F1007@vovida.com>
Subject: Re: [SIP] Informative responses for OPTIONS, and INFO requests
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_00D6_01C027E1.3520C9C0"
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, 26 Sep 2000 17:42:57 -0400

This is a multi-part message in MIME format.

------=_NextPart_000_00D6_01C027E1.3520C9C0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

The 100 Trying response can be sent by any=20
device to inform the requestor (or transaction=20
stateful entity) that it was received by a=20
transaction stateful entity that will take=20
responsibility for its delivery.  As a result of
a 100 Trying, the event retry timers should=20
be adjusted accordingly to rfc2543.
  ----- Original Message -----=20
  From: Sunitha Kumar=20
  To: sip bell labs=20
  Sent: Tuesday, September 26, 2000 5:26 PM
  Subject: [SIP] Informative responses for OPTIONS, and INFO requests


  Could 100 Trying be sent as a response to these. The SIP RFC, and the =
INFO draft specifies that a 200 MUST be sent from the UAS. However, =
since the requests go through a proxy, allowing the proxy to send a 1xx =
back, should be feasible.=20
  Kindly let me know if this causes further problems.=20
  thanks=20

--=20
Sunitha Kumar
http://www.vovida.com
   =20

------=_NextPart_000_00D6_01C027E1.3520C9C0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable









The 100 Trying response can be sent by any =



device to inform the requestor (or transaction =



stateful entity) that it was received by a =



transaction stateful entity that will take =



responsibility for its delivery.  As a result=20
of


a 100 Trying, the event retry=20
timers should 


be adjusted accordingly to rfc2543.


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

  From:=20
  Sunitha =
Kumar=20
  
  
To: sip bell=20
  labs 

  
Sent: Tuesday, September 26, =
2000 5:26=20
  PM

  
Subject: [SIP] Informative =
responses for=20
  OPTIONS, and INFO requests

  

Could 100 Trying be sent as a response to these. The =
SIP RFC,=20
  and the INFO draft specifies that a 200 MUST be sent from the UAS. =
However,=20
  since the requests go through a proxy, allowing the proxy to send a =
1xx back,=20
  should be feasible. 
Kindly let me know if this causes further =
problems.=20
  
thanks 
-- 
Sunitha Kumar
http://www.vovida.com
 =20


------=_NextPart_000_00D6_01C027E1.3520C9C0--


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


From sip-admin@lists.bell-labs.com  Tue Sep 26 22:06: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 WAA20053
	for ; Tue, 26 Sep 2000 22:06: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 65E124433A; Tue, 26 Sep 2000 21:06:10 -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 4B83C44339
	for ; Tue, 26 Sep 2000 21:05: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 WAA23177;
	Tue, 26 Sep 2000 22:07:25 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id ; Tue, 26 Sep 2000 22:02:08 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'Christer Holmberg'" ,
        "'sip@lists.bell-labs.com'" 
Subject: RE: [SIP] Session Timer 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, 26 Sep 2000 22:01:58 -0400




> -----Original Message-----
> From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se]
> Sent: Tuesday, September 26, 2000 4:54 PM
> To: sip@lists.bell-labs.com
> Subject: [SIP] Session Timer Question
> 
> 
> 
> Hi,
> 
> I have a question about the session timer.
> 
> Since the session timer can be used even if one party supports it,
> consider the following examples, where the UAS (but not the UAC)
> supports it.
> 
> A.
> 
> UAC	UAS
> 
> --------->   INVITE
> 
> <---------   200 OK
> 	     Session-Expires: X
> 
> 
> B.
> 
> UAC	UAS
> 
> --------->   INVITE
> 
> <---------   200 OK
> 
> 
> 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.

---
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 Sep 26 22:19: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 WAA20208
	for ; Tue, 26 Sep 2000 22:19: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 3AC7C4433A; Tue, 26 Sep 2000 21:19: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 05AA044339
	for ; Tue, 26 Sep 2000 21:18:06 -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 WAA23343;
	Tue, 26 Sep 2000 22:19:55 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id ; Tue, 26 Sep 2000 22:14:38 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'shh@microappliances.com'" ,
        Jonathan Rosenberg 
Cc: "'Suresh Srinivas'" ,
        "'\"\\\"'sip@lists.bell-labs.com'\\\"\"'" 
Subject: RE: [SIP] Handling error conditions
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, 26 Sep 2000 22:14:36 -0400




> -----Original Message-----
> From: shh@microappliances.com [mailto:shh@microappliances.com]
> Sent: Tuesday, September 26, 2000 1:50 PM
> To: Jonathan Rosenberg
> Cc: 'Suresh Srinivas'; "\"'sip@lists.bell-labs.com'\""
> Subject: RE: [SIP] Handling error conditions
> 
> 
> 
> Jonathan,
> 
> > >
> > > New call origination:
> > > ---------------------
> > > Scenario 1:
> > >     - Sending INVITE failed at the UAC
> > >     - UAC did not receive response (or failed to parse
> > > response) for INVITE
> > > Handling:
> > >    Give disconnect indication. Go to Idling state when user
> > > disconnects the
> > > call.
> > >
> >
> > Probably a good idea to also send BYE. Since no ACK is 
> being sent, the call
> > will timeout at the UAS, but BYE makes it faster and more robust.
> >
> 
> I am curious to know why you prefer to send a BYE instead of a
> CANCEL.

Because in my caffeine deprived state somehow the "not" did not pass through
my brain correctly.

> If the 200 OK was not received, the Route is not established
> and hence the BYE may be difficult to route properly.

Yes. It should be CANCEL.

-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 Sep 26 22:33: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 WAA21265
	for ; Tue, 26 Sep 2000 22:33: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 345D84433A; Tue, 26 Sep 2000 21:33: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 0984744339
	for ; Tue, 26 Sep 2000 21:32: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 WAA23442;
	Tue, 26 Sep 2000 22:34:05 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id ; Tue, 26 Sep 2000 22:28:48 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'Jon.Peterson@Level3.com'" ,
        "'sip@lists.bell-labs.com'" 
Subject: RE: [SIP] Outbound call routing
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, 26 Sep 2000 22:28:46 -0400

I agree with Jon on all counts.

Seems like general consensus that Route would be the right mechanism here,
no?

-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: Monday, September 25, 2000 6:46 PM
> To: sip@lists.bell-labs.com
> Subject: RE: [SIP] Outbound call routing
> 
> 
> 
> It seems to me that this discussion is considering two issues 
> - firstly, how
> does a UA discover that it should use a particular PS as an 
> outbound proxy,
> and secondly, how does the UA signal the first-hop and final 
> destinations of
> the session in an INVITE. I think the second question can and 
> should be
> considered independently from the first, as it has bearing on other
> architectures that require a very similar mechanism.
> 
> For example, consider a case in which a UA sends an INVITE 
> that reaches a
> local PS which then performs some sort of lookup and decides 
> to forward the
> call to a remote PS in another administrative domain. In 
> order to reach the
> remote PS, however, the local PS must send the call through a specific
> firewall - perhaps there are several firewalls in the local 
> administrative
> domain, and one is a better way to reach the remote domain 
> than the others.
> When it has made its decision about which specific firewall 
> is the right one
> to traverse (which could have been discovered in any of a 
> number of ways),
> it must use some mechanism in its signaling to the firewall 
> to describe the
> first-hop server (the firewall itself) and the final 
> destination (the remote
> PS). I see no reason why we couldn't use the same signaling 
> mechanism for
> this that we would use in the UA-to-outbound-proxy case. It 
> could be as
> simple as just sending the INVITE to the first-hop server 
> with a Request-URI
> indicating the final destination. Or it could be, as has been 
> suggested
> here, an early Route header (an idea that's fairly attractive 
> to me). I'm
> not sure how this could be made compatible with DNS SRV 
> records (for reasons
> similar to those brought up by Jo@ubiquity earlier in the 
> thread), but I
> think SRV speaks more to the first issue than to the second anyway.
> 
> As a bit of an aside, I'd also like to suggest that a UA 
> should not break
> Record-Route regardless of any internally configured PS for outbound
> requests. That is, the outbound proxy routing mechanism 
> should be consulted
> for new session requests only, not for requests associated with a
> pre-existing session. When the UA is the -caller-, if the 
> outbound proxy
> chooses to add itself to the Record-Route, all future requests for the
> session will cross the outbound proxy, so this shouldn't be 
> broken. What
> concerns me here are cases in which a UA is the -callee-, a 
> Record-Route
> exists for the call that does not include the outbound proxy 
> (for whatever
> reason), and the UA decides to a issue, say, a BYE, and is 
> forced to break
> Record-Route in order to send it to the outbound proxy. This 
> could lead to
> various problems. Ultimately, the inbound routing procedures should
> guarantee that the outbound proxy has the opportunity to 
> Record-Route itself
> on the initial INVITE if this is appropriate; this shouldn't be
> retroactively enforced by a UA.
> 
> Jon Peterson
> Level(3) Communications
> 
> -----Original Message-----
> From: Simon Barber [mailto:simon@firetalk.com]
> Sent: Friday, September 22, 2000 6:48 PM
> To: Jo Hornsby; hch@ipdialog.com
> Cc: 'Sip@Lists. Bell-Labs. Com'
> Subject: RE: [SIP] Outbound call routing
> 
> 
> > > When a SIP message is first sent out from a UAC the 
> requestURI could
> > > be set to the contents of the DNS SRV record 
> "sipoutbound". When the
> > > INVITE reaches the user's outbound server, then the request URI
> > > would be set to the contents of the to: header. This assumes that
> > > the UA always wants the request routed to the to: header. Is this
> > > always true?
> >
> > I would say very likely to be true, for an initial INVITE.  I
> > would stay away from "always", however. &:)
> 
> A valid argument. We should maintain the ability of the UAC to set
> the requestURI of the invite to whatever it wants.
> 
> >
> > > This also changes the handling of the to: header. It is
> > > now not interpreted by the proxy servers between the terminal and
> > > the user's outbound server. This means that local 
> semantics will not
> > > be applied. I guess sometimes this is good, sometimes bad!
> >
> > This is slightly problematic; how does a proxy know that it is
> > supposed to be interpreting the To: instead of the Request-URI?
> > Although I guess it's only the first proxy (the "home" proxy?)
> > after the firewall prox(y|ies) that needs to know that To is
> > overriding.  Hmmm...
> >
> > [...]
> > > Using the SRV record has the advantage that the UA does 
> not need to
> > > be registered before outbound calling will work correctly. I see
> > > this decoupling of outbound and inbound calling as an important
> > > advantage.
> >
> > Using the SRV record also has the disadvantage that someone has to
> > be responsible for configuring the record for a user's address,
> > and since the granularity is at a domain level, this isn't that
> > flexible (I might like to have my own "outbound" proxy, that I'd
> > written with my own funky features, for instance).
> 
> Hisham - Apologies, I have misunderstood your meaning for 
> outbound server.
> By outbound server I mean a server that is part of my domain, 
> that all my
> outbound requests will pass though (whether I am originating 
> those requests
> from part of the network within my domain or not).
> 
> I would suggest the sipoutbound SRV record is domain wide, not user
> specific - just like the SIP SRV record for incoming calls. If you
> want to use a specific server for your particular user, then you
> should have the server that handles the domain direct the request to
> a server that handles your particular user.
> 
> Using a domain wide SRV record means that it's all or nothing for that
> domain, of course. This forces outbound requests to be routed 
> like this for
> all users. Using the response to REGISTER means this is 
> configurable on a
> user by user basis, but it does require the user be registered.
> 
> >
> > The notion of using source routing mentioned earlier in this
> > thread, by embedding a Route header, as Anders and Sean suggested,
> > would seem to solve all of these problems, and it reuses existing
> > syntax quite nicely.  Plus -- as Sean pointed out -- it generalises
> > to multiple proxies; not to mention the possibilities with implying
> > other headers (State perhaps?).
> >
> 
> Route does seem to be a neat solution. Excuse my ignorance, 
> but why does it
> have to be embedded in the requestURI?
> 
> Indeed I am not sure that we even need a separate SRV record for
> outbound and inbound calls at all. Why not simply say that a Route:
> header for initial requests should be set to the sip URL for the
> user making the request (normally also the contents of the From:
> header.).
> 
> This way all outbound requests pass through the same server that
> handles the user's inbound calls. This should be completely compatible
> with current procedures. It does tie the server which handles services
> for outbound calls to the same server that handles services 
> for inbound
> calls, but is this a problem?
> 
> This also means that this form of outbound routing is used for all SIP
> requests, irrespective of whether this is required for 
> services or not.
> 
> In summary, 3 approaches:
> 
> 1) configuration using REGISTER
> - outbound routing can be controlled on a per specific 
> registration basis
> 
> 2) configuration using SRV record
> - outbound routing can be controlled on a per domain basis
> 
> 3) always route through user's home server
> - no option not to route through user's home server
> 
> or
> 
> 4) other method?
> 
> 
> 
> > Do you forsee any problems with this approach?
> 
> Seems very sensible!
> 
> >
> > 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 Sep 26 22:40: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 WAA21304
	for ; Tue, 26 Sep 2000 22: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 D315F44365; Tue, 26 Sep 2000 21:40:10 -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 69E7B4433C
	for ; Tue, 26 Sep 2000 21:39: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 WAA23471;
	Tue, 26 Sep 2000 22:41:55 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id ; Tue, 26 Sep 2000 22:36:38 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'Phil Hoffer'" ,
        "'sip@lists.bell-labs.com'" 
Subject: RE: [SIP] The Null authentication scheme
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, 26 Sep 2000 22:36:30 -0400

I would argue that the server should have well defined mappings from
strength of authentication to services provided. That is, if the UAC chooses
the null scheme, the server will accept that, but won't do much useful for
that 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: (732) 741-7244
http://www.dynamicsoft.com 
-----Original Message-----
From: Phil Hoffer [mailto:phoffer@ubiquity.net]
Sent: Tuesday, September 26, 2000 11:50 AM
To: sip@lists.bell-labs.com
Subject: RE: [SIP] The Null authentication scheme


Hi,

Just a quick point/question?

Section 1.2 of rfc2617.txt states that the authenticating entity MUST
include
a WWW-Authenticate (or Proxy-Authenticate) header with at least one
challenge
applicable to the requested resource.

It goes on to state that the user agent responding to the challenge MUST
choose to
use one of the challenges with the strongest auth-scheme it understands.

Consider then if a WWW-Authenticate header is returned with multiple
challenges,
e.g. Digest and Null

Does the selection by the user agent break the "strongest challenge rule" if
it chooses
to use the Null authentication scheme?

In the strictest terms I suppose it does.
However, I can also see the argument that the caller didn't get to contact
the original callee directly.

Maybe a clarification is required !???

WDYT?

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  Tue Sep 26 23: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 XAA21523
	for ; Tue, 26 Sep 2000 23:14: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 9E4844433A; Tue, 26 Sep 2000 22:14:10 -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 F0B5644339
	for ; Tue, 26 Sep 2000 22:13: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 XAA23513;
	Tue, 26 Sep 2000 23:15:25 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id ; Tue, 26 Sep 2000 23:10:09 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'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;
	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, 26 Sep 2000 23:09:59 -0400

I don't follow the scenario. Can you elaborate?

-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: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
> Sent: Monday, September 25, 2000 4:02 PM
> To: sip
> Subject: [SIP] Re-direct of Media During Ringing
> 
> 
> 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
> 

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


From sip-admin@lists.bell-labs.com  Wed Sep 27 00:18: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 AAA22455
	for ; Wed, 27 Sep 2000 00:18: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 E1EAB4433A; Tue, 26 Sep 2000 23:18:12 -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 CD06344339
	for ; Tue, 26 Sep 2000 23:17:20 -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, 26 Sep 2000 21:15:18 -0700
From: "Simon Barber" 
To: "Jo Hornsby" ,
        "Henning Schulzrinne" 
Cc: "Hisham Khartabil" ,
        ,
        "Jonathan Rosenberg" 
Subject: RE: [SIP] Outbound call routing
Message-ID: 
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----=_NextPart_000_0032_01C027FF.5C7BB9D0"
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: <006001c02157$8dd65840$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: Tue, 26 Sep 2000 21:18:48 -0700

This is a multi-part message in MIME format.

------=_NextPart_000_0032_01C027FF.5C7BB9D0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

How would a current implementation of a proxy server handle this new URL
parameter (route).

Would the parameter be ignored by current proxies, or would the request be
rejected?

If current proxies would ignore the route, perhaps it would be better to put
the home outbound server (the destination we wish to loose route through) as
the requestURI (so current implementations send the request in the right
direction), and the final destination in the route parameter. This way only
the client, and the home outbound server need know about the new parameter.

Simon Barber.


> -----Original Message-----
> From: sip-admin@lists.bell-labs.com
> [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Jo Hornsby
> Sent: Monday, September 18, 2000 3:02 AM
> To: Henning Schulzrinne; Simon Barber
> Cc: Hisham Khartabil; sip@lists.bell-labs.com; Jonathan Rosenberg
> Subject: RE: [SIP] Outbound call routing
>
>
> > Forcing routing seems yet another user configuration parameter, along
> > with other service parameters that I'd like to keep even as I change
> > terminals. Thus, this is probably best addressed as user configuration
> > data downloaded from the REGISTER server, along with things like
> > speed-dial buttons or, say, CFB/CFNA end system behavior. If we define
> > an extension of CPL that's tailored to user agents, this might be a
> > useful feature to have, as one may want to make this feature
> > conditional.
>
> It's a nice idea, but I would guess that is going to be difficult
> in a lot of situations.
>
> I think the real problem lies with the fact that if a UA has an
> Outbound Proxy configured, then in a lot of cases, this is going
> to be for a very good reason (Firewall, or whatever).  Therefore,
> if I happen to be working on some remote part of this Planet, and
> thus using "somebody else's" UA, I'm not necessarily going to be
> able to just reconfigure it to use my "home" proxy.
>
> As Jonathan pointed out, one could utilise Route to achieve this
> goal, but there is no guarantee that a proxy will honour this,
> since it will previously have been unaware of this "call".
>
> I've always wondered if it might be useful to have SIP URLs
> slightly more expressive, so that routing can be slightly richer
> without any information being lost as it occurs.  And this seems
> as good a time as any to bring this point up.
>
> What I'm proposing, is a new SIP URL parameter, let's say: "proxy".
> The value of the "proxy" parameter is a `hostport'.
>
> This means that I can now roam to somebody else's domain, and
> send out an INVITE a la:
>     INVITE sip:alice@example.com;proxy=sip.ubiquity.net SIP/2.0
>     ...
> In which case the INVITE is routed through the UAs normal
> outbound proxy, as needed, and "sip.ubiquity.net" supercedes
> any normal routing decisions.
>
> This would seem to satisfy the "always use this proxy" requirement,
> whether an outbound proxy is in the loop or not.
>
> Futhermore, it helps with the following scenario...
>
> Say my public SIP Address is sip:jo@ubiquity.net, but today I'm
> going to be working at buffy.com, thus I would like all my calls
> to be routed through to buffy.com.  I plug in my laptop, and
> get allocated some private intranet IP via DHCP.  I would like
> to send a REGISTER to my proxy at ubiquity.net, but my IP is
> not globally routable, so the Contact address my UA deduces is
> useless; however, it is trivial for me to multicast a REGISTER
> locally for sip:jo@ubiquity.net.
>
> So how does the proxy serving ubiquity.net know to route messages
> to buffy.com?  Well, I can think of three solutions:
>  1) I send a REGISTER to ubiquity.net with my non-globally-routable
>     IP in the Contact, and some proxy at buffy.com rewrites the
>     Contact (and notes where I am for subsequent routing).
>  2) I have some sort of temporary account set up at buffy.com
>     by the Systems Administrator, say "sip:ubiquity-jo@buffy.com".
>     The necessary registrations are then done at both ubiquity.net
>     and buffy.com .
>  3) I register my Contact at ubiquity.net as
>     sip:jo@ubiquity.net;proxy=buffy.com
>
> I prefer 3), since maximum information is retained and very little
> messing around is required (i.e., we don't require any bastardisation
> of the message, nor extra staff).
>
> But in the end, I'm just bouncing this around, to see what people
> think.  Routing is already very flexible, so this might be only
> really useful for the constant threat of firewall, in which case
> other, probably rewriting-based, solutions are probably preferable
> (since they're probably already going to have to be in place).
>
> Thoughts?
>
> Cheers,
>
>
>  - Jo.
>
>
>
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip
>

------=_NextPart_000_0032_01C027FF.5C7BB9D0
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_0032_01C027FF.5C7BB9D0--


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


From sip-admin@lists.bell-labs.com  Wed Sep 27 00:32: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 AAA22561
	for ; Wed, 27 Sep 2000 00:32: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 A230D44369; Tue, 26 Sep 2000 23:32:10 -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 CB04944339
	for ; Tue, 26 Sep 2000 23:31:51 -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, 26 Sep 2000 21:29:47 -0700
From: "Simon Barber" 
To: "Jonathan Rosenberg" ,
        "'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_01C02801.622ABBE0"
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, 26 Sep 2000 21:33:17 -0700

This is a multi-part message in MIME format.

------=_NextPart_000_0035_01C02801.622ABBE0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

I see the restriction on re-invite during ringing as dangerous. Media
delivered during ringing might not be simply "ringback" to the caller, but
might also include media delivered to the callee. This might be used, for
example for:

Audio paging to a telephone/telephones
Delivering video of the caller early
Delivering any push media channel, where the user wants to receive the
channel without or before explicitly accepting the call.

I think there are many possible services that could be created using this
facility (obviously the user must have privacy controls for this type of
call). Because of the range of services that might use push delivery without
explicit acceptance it could potentially be dangerously limiting to not
allow re-invite during ringing.

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.

Simon Barber


> -----Original Message-----
> From: sip-admin@lists.bell-labs.com
> [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Jonathan Rosenberg
> Sent: Tuesday, September 26, 2000 8:10 PM
> To: 'Tom-PT Taylor'; 'sip'
> Subject: RE: [SIP] Re-direct of Media During Ringing
>
>
> I don't follow the scenario. Can you elaborate?
>
> -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: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
> > Sent: Monday, September 25, 2000 4:02 PM
> > To: sip
> > Subject: [SIP] Re-direct of Media During Ringing
> >
> >
> > 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
> >
>
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip
>

------=_NextPart_000_0035_01C02801.622ABBE0
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_01C02801.622ABBE0--


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


From sip-admin@lists.bell-labs.com  Wed Sep 27 01:03: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 BAA22752
	for ; Wed, 27 Sep 2000 01:03: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 AAFEF44369; Wed, 27 Sep 2000 00:03:10 -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 47E104433A
	for ; Wed, 27 Sep 2000 00:02:09 -0400 (EDT)
Received: from armorse (203.197.179.23 [203.197.179.23]) by mail.in.huawei.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21)
	id S7TKDTZW; Wed, 27 Sep 2000 10:33:27 +0530
Reply-To: 
From: "Bodgey" 
To: "Jonathan Rosenberg" 
Cc: , 
Subject: RE: [SIP] Session Timer Question
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.00.2919.6600
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, 27 Sep 2000 10:31:35 +0530
Content-Transfer-Encoding: 7bit

> > Hi,
> >
> > I have a question about the session timer.
> >
> > Since the session timer can be used even if one party supports it,
> > consider the following examples, where the UAS (but not the UAC)
> > supports it.
> >
> > A.
> >
> > UAC	UAS
> >
> > --------->   INVITE
> >
> > <---------   200 OK
> > 	     Session-Expires: X
> >
> >
> > B.
> >
> > UAC	UAS
> >
> > --------->   INVITE
> >
> > <---------   200 OK
> >
> >
> > 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.

Bodgey


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


From sip-admin@lists.bell-labs.com  Wed Sep 27 03:26: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 DAA06183
	for ; Wed, 27 Sep 2000 03:26: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 1AACA4433A; Wed, 27 Sep 2000 02:26:11 -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 2826844339
	for ; Wed, 27 Sep 2000 02:25:05 -0400 (EDT)
Received: from esealnt409 (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 e8R7P1Z10740
	for ; Wed, 27 Sep 2000 09:25:01 +0200 (MEST)
Received: FROM esealnt743.al.sw.ericsson.se BY esealnt409 ; Wed Sep 27 09:09:58 2000 +0200
Received: by esealnt743.al.sw.ericsson.se with Internet Mail Service (5.5.2651.58)
	id ; Wed, 27 Sep 2000 09:25:00 +0200
Message-ID: <56E7307B0850D411B1480008C75DD5EAB73CC7@enlrynt303.dsn.ericsson.se>
From: "Arnoud van Wijk (ETM)" 
To: "'Henning Schulzrinne'" 
Cc: "'Simon Barber'" , sip@lists.bell-labs.com
Subject: RE: [SIP] Outbound call routing
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, 27 Sep 2000 09:24:58 +0200

Henning.


That is right. It is a broken idea..and quite unfriendly. :-)
I did not say that I agree with this idea (even that I did suggest it), but it illustrates that this seems to be the only way to route the SIP messages to P4.

Personally I think that the realistic solution will be that a visited network partner will do the services that is required for the roaming user (user A in this example). So, this would lead to trust between the home network and the visited network. 
(which is then a network operator issue, I believe that the AAAArch group is working on this interdomain work).

Arnoud



-----Original Message-----
From: Henning Schulzrinne [ mailto:schulzrinne@cs.columbia.edu  ]
Sent: dinsdag 26 sep 2000 17:46
To: Arnoud van Wijk (ETM)
Cc: 'Simon Barber'; sip@lists.bell-labs.com
Subject: Re: [SIP] Outbound call routing


"Arnoud van Wijk (ETM)" wrote:
>
> Hello Simon,
>
> Yes. I see the problem. I have been wrestling with similar architecture problems.
> Right now, nothing can force the SIP messages from User A to go through P3 and P4.
>
> I think that the solution will be in forcing the client of User A to use the registrar of the home domain of user A. And then have P4 add itself in the via header (route header).
> This means that P4 receives the location search request from user A when A places a call to B, and P4 will then use the registrar to find the definite location of user B. Then P4 will send the SIP message with the IP address of user B's UA (via P5). But before P4 sends the SIP message, it will add itself to the via header or route header. (I am in a hurry, sorry for the sketchy details).
>
> Bottomline is that a roaming user should never be allowed to use the current domain's location server/registrar. Always ONLY the homedomain's locator servers. And then it is just a matter of the insertion of the desired servers.

This is a fundamentally broken idea. This is not your grandpa's phone
network. Any notion of "forcing" clients to do anything is just not a
workable proposition in the Internet. In some circumstances, using the
current ("visited") registrar makes perfect sense, so I see no reason to
prohibit that.


>
> I will work this out in more detail if this is too unclear.
>

> Terminology:
>
> I have certainly helped confuse the issue by using unclear terminology -
> specifically outbound server. Perhaps a clearer name might help the
> discussion. Perhaps "home outbound proxy" HOB. This is a proxy server under
> control of the user's home administrative domain, through which outbound
> calls may be routed, to allow services on outbound calls. How this routing
> is controlled and achieved is the subject of the discussion.
>
> The problem is:
>
> If the user is using a UA in a part of the network within his administrative
> domain it is possible to arrange for his outbound calls to have some
> processing applied under the control of his administrative domain, but if
> the user is roaming in a network under another administrative domain there
> is no mechanism for his home administrative domain to have any knowledge or
> control of his outbound calls within the SIP specification.
>
> A diagram:
> (switch to a fixed pitch font to view this)
>
> ........................        ....................
>   Administrative       :        :Administrative
>   domain X             :        :domain A, a.com
>                        :        :
> User A ----- P1 ----- P2 ----- P3 ----- P4 (HOB)
>                        :     /  :
> .......................:    /   :...................
>   Administrative       :   /
>   domain B, b.com      :  /
>                        : /
>          User B ----- P5
>                        :
> .......................:
>
> User A wishes to call User B - but the call must pass through proxy P4, user
> A's home outbound server, so that a service can be applied to the call.
>
> Simon Barber.
>
> > -----Original Message-----
> > From: sip-admin@lists.bell-labs.com
> > [ mailto:sip-admin@lists.bell-labs.com  ]On Behalf Of
> > Jon.Peterson@Level3.com
> > Sent: Monday, September 25, 2000 3:46 PM
> > To: sip@lists.bell-labs.com
> > Subject: RE: [SIP] Outbound call routing
> >
> >
> >
> > It seems to me that this discussion is considering two issues -
> > firstly, how
> > does a UA discover that it should use a particular PS as an
> > outbound proxy,
> > and secondly, how does the UA signal the first-hop and final
> > destinations of
> > the session in an INVITE. I think the second question can and should be
> > considered independently from the first, as it has bearing on other
> > architectures that require a very similar mechanism.
> >
> > For example, consider a case in which a UA sends an INVITE that reaches a
> > local PS which then performs some sort of lookup and decides to
> > forward the
> > call to a remote PS in another administrative domain. In order to
> > reach the
> > remote PS, however, the local PS must send the call through a specific
> > firewall - perhaps there are several firewalls in the local administrative
> > domain, and one is a better way to reach the remote domain than
> > the others.
> > When it has made its decision about which specific firewall is
> > the right one
> > to traverse (which could have been discovered in any of a number of ways),
> > it must use some mechanism in its signaling to the firewall to
> > describe the
> > first-hop server (the firewall itself) and the final destination
> > (the remote
> > PS). I see no reason why we couldn't use the same signaling mechanism for
> > this that we would use in the UA-to-outbound-proxy case. It could be as
> > simple as just sending the INVITE to the first-hop server with a
> > Request-URI
> > indicating the final destination. Or it could be, as has been suggested
> > here, an early Route header (an idea that's fairly attractive to me). I'm
> > not sure how this could be made compatible with DNS SRV records
> > (for reasons
> > similar to those brought up by Jo@ubiquity earlier in the thread), but I
> > think SRV speaks more to the first issue than to the second anyway.
> >
> > As a bit of an aside, I'd also like to suggest that a UA should not break
> > Record-Route regardless of any internally configured PS for outbound
> > requests. That is, the outbound proxy routing mechanism should be
> > consulted
> > for new session requests only, not for requests associated with a
> > pre-existing session. When the UA is the -caller-, if the outbound proxy
> > chooses to add itself to the Record-Route, all future requests for the
> > session will cross the outbound proxy, so this shouldn't be broken. What
> > concerns me here are cases in which a UA is the -callee-, a Record-Route
> > exists for the call that does not include the outbound proxy (for whatever
> > reason), and the UA decides to a issue, say, a BYE, and is forced to break
> > Record-Route in order to send it to the outbound proxy. This could lead to
> > various problems. Ultimately, the inbound routing procedures should
> > guarantee that the outbound proxy has the opportunity to
> > Record-Route itself
> > on the initial INVITE if this is appropriate; this shouldn't be
> > retroactively enforced by a UA.
> >
> > Jon Peterson
> > Level(3) Communications
> >
> > -----Original Message-----
> > From: Simon Barber [ mailto:simon@firetalk.com  ]
> > Sent: Friday, September 22, 2000 6:48 PM
> > To: Jo Hornsby; hch@ipdialog.com
> > Cc: 'Sip@Lists. Bell-Labs. Com'
> > Subject: RE: [SIP] Outbound call routing
> >
> >
> > > > When a SIP message is first sent out from a UAC the requestURI could
> > > > be set to the contents of the DNS SRV record "sipoutbound". When the
> > > > INVITE reaches the user's outbound server, then the request URI
> > > > would be set to the contents of the to: header. This assumes that
> > > > the UA always wants the request routed to the to: header. Is this
> > > > always true?
> > >
> > > I would say very likely to be true, for an initial INVITE.  I
> > > would stay away from "always", however. &:)
> >
> > A valid argument. We should maintain the ability of the UAC to set
> > the requestURI of the invite to whatever it wants.
> >
> > >
> > > > This also changes the handling of the to: header. It is
> > > > now not interpreted by the proxy servers between the terminal and
> > > > the user's outbound server. This means that local semantics will not
> > > > be applied. I guess sometimes this is good, sometimes bad!
> > >
> > > This is slightly problematic; how does a proxy know that it is
> > > supposed to be interpreting the To: instead of the Request-URI?
> > > Although I guess it's only the first proxy (the "home" proxy?)
> > > after the firewall prox(y|ies) that needs to know that To is
> > > overriding.  Hmmm...
> > >
> > > [...]
> > > > Using the SRV record has the advantage that the UA does not need to
> > > > be registered before outbound calling will work correctly. I see
> > > > this decoupling of outbound and inbound calling as an important
> > > > advantage.
> > >
> > > Using the SRV record also has the disadvantage that someone has to
> > > be responsible for configuring the record for a user's address,
> > > and since the granularity is at a domain level, this isn't that
> > > flexible (I might like to have my own "outbound" proxy, that I'd
> > > written with my own funky features, for instance).
> >
> > Hisham - Apologies, I have misunderstood your meaning for outbound server.
> > By outbound server I mean a server that is part of my domain, that all my
> > outbound requests will pass though (whether I am originating
> > those requests
> > from part of the network within my domain or not).
> >
> > I would suggest the sipoutbound SRV record is domain wide, not user
> > specific - just like the SIP SRV record for incoming calls. If you
> > want to use a specific server for your particular user, then you
> > should have the server that handles the domain direct the request to
> > a server that handles your particular user.
> >
> > Using a domain wide SRV record means that it's all or nothing for that
> > domain, of course. This forces outbound requests to be routed
> > like this for
> > all users. Using the response to REGISTER means this is configurable on a
> > user by user basis, but it does require the user be registered.
> >
> > >
> > > The notion of using source routing mentioned earlier in this
> > > thread, by embedding a Route header, as Anders and Sean suggested,
> > > would seem to solve all of these problems, and it reuses existing
> > > syntax quite nicely.  Plus -- as Sean pointed out -- it generalises
> > > to multiple proxies; not to mention the possibilities with implying
> > > other headers (State perhaps?).
> > >
> >
> > Route does seem to be a neat solution. Excuse my ignorance, but
> > why does it
> > have to be embedded in the requestURI?
> >
> > Indeed I am not sure that we even need a separate SRV record for
> > outbound and inbound calls at all. Why not simply say that a Route:
> > header for initial requests should be set to the sip URL for the
> > user making the request (normally also the contents of the From:
> > header.).
> >
> > This way all outbound requests pass through the same server that
> > handles the user's inbound calls. This should be completely compatible
> > with current procedures. It does tie the server which handles services
> > for outbound calls to the same server that handles services for inbound
> > calls, but is this a problem?
> >
> > This also means that this form of outbound routing is used for all SIP
> > requests, irrespective of whether this is required for services or not.
> >
> > In summary, 3 approaches:
> >
> > 1) configuration using REGISTER
> > - outbound routing can be controlled on a per specific registration basis
> >
> > 2) configuration using SRV record
> > - outbound routing can be controlled on a per domain basis
> >
> > 3) always route through user's home server
> > - no option not to route through user's home server
> >
> > or
> >
> > 4) other method?
> >
> >
> >
> > > Do you forsee any problems with this approach?
> >
> > Seems very sensible!
> >
> > >
> > > 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  

--
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 Sep 27 07:08: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 HAA08123
	for ; Wed, 27 Sep 2000 07:08: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 A13FF4433A; Wed, 27 Sep 2000 06:08:10 -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 6E97844339
	for ; Wed, 27 Sep 2000 06:07:08 -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 OAA27909
	for ; Wed, 27 Sep 2000 14:10:02 +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 09/27/2000 02:07:03 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Subject: [SIP] Intro to 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, 27 Sep 2000 14:07:02 +0200


I realize that SIP is so new that there might not yet be books and
tutorials, but I would still like to ask: Are any books, tutorials, or
introductory technical articles?

I am learning SIP straight from the RFP, but an intro might make it faster
to learn.

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 Sep 27 07:17: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 HAA08323
	for ; Wed, 27 Sep 2000 07: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 39EC044351; Wed, 27 Sep 2000 06:17:11 -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 4C6BE4433A
	for ; Wed, 27 Sep 2000 06:16:53 -0400 (EDT)
Received: from esealnt409 (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 e8RBGkZ20174
	for ; Wed, 27 Sep 2000 13:16:46 +0200 (MEST)
Received: FROM esealnt743.al.sw.ericsson.se BY esealnt409 ; Wed Sep 27 13:01:39 2000 +0200
Received: by esealnt743.al.sw.ericsson.se with Internet Mail Service (5.5.2651.58)
	id ; Wed, 27 Sep 2000 13:16:40 +0200
Message-ID: <56E7307B0850D411B1480008C75DD5EAB73CCA@enlrynt303.dsn.ericsson.se>
From: "Arnoud van Wijk (ETM)" 
To: "'Simon Barber'" , Jo Hornsby ,
        Henning Schulzrinne 
Cc: sip@lists.bell-labs.com
Subject: RE: [SIP] Outbound call routing
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, 27 Sep 2000 13:16:30 +0200

When I replied in the previous postings, I had a different thing in my mind. Now I see what the "problem" is.

I agree with Simon that only the client and the home outbound server should understand the request.
I am not so eager to have another URL parameter.

I think that the key lies indeed with the user preferences. When a UA registers at a registrar, it will also do this at the home registrar. The UA can then get the user preferences as mentioned previously from the home registrar. And one of the options is then the home outbound server into the SIP request routing. And the UA client can insert the home outbound proxy into the route header.

To prevent that certain settings are erased from a certain UAC in a visiting domain (like outbound server from the visiting domain itself due firewall and other network related settings etc). The UAC should work at 2 levels. First level is domain specific settings (which could be sent to the UAC upon logging into the domain itself at the same time when the IP is assigned etc) and the second level is via the user preferences obtained from the home registrar upon REGISTERING the UAC.
The UAC should be intelligent enough to place any routing information after the domain specific routing info).

The job is then done by the SIP clients. I do realise that this has to work for simple SIP clients as well for the superdeluxe SIP clients, though the latter should easily support all options.

What do you think?

Arnoud

_______________________________________________________________
ERICSSON TELECOMMUNICATIE BV
Arnoud van Wijk
ABACUS Lab
Research & Development
Fax: +31-161 247569
_______________________________________________________________





-----Original Message-----
From: Simon Barber [mailto:simon@firetalk.com]
Sent: woensdag 27 sep 2000 6:19
To: Jo Hornsby; Henning Schulzrinne
Cc: Hisham Khartabil (LMF); sip@lists.bell-labs.com; Jonathan Rosenberg
Subject: RE: [SIP] Outbound call routing


How would a current implementation of a proxy server handle this new URL
parameter (route).

Would the parameter be ignored by current proxies, or would the request be
rejected?

If current proxies would ignore the route, perhaps it would be better to put
the home outbound server (the destination we wish to loose route through) as
the requestURI (so current implementations send the request in the right
direction), and the final destination in the route parameter. This way only
the client, and the home outbound server need know about the new parameter.

Simon Barber.


> -----Original Message-----
> From: sip-admin@lists.bell-labs.com
> [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Jo Hornsby
> Sent: Monday, September 18, 2000 3:02 AM
> To: Henning Schulzrinne; Simon Barber
> Cc: Hisham Khartabil; sip@lists.bell-labs.com; Jonathan Rosenberg
> Subject: RE: [SIP] Outbound call routing
>
>
> > Forcing routing seems yet another user configuration parameter, along
> > with other service parameters that I'd like to keep even as I change
> > terminals. Thus, this is probably best addressed as user configuration
> > data downloaded from the REGISTER server, along with things like
> > speed-dial buttons or, say, CFB/CFNA end system behavior. If we define
> > an extension of CPL that's tailored to user agents, this might be a
> > useful feature to have, as one may want to make this feature
> > conditional.
>
> It's a nice idea, but I would guess that is going to be difficult
> in a lot of situations.
>
> I think the real problem lies with the fact that if a UA has an
> Outbound Proxy configured, then in a lot of cases, this is going
> to be for a very good reason (Firewall, or whatever).  Therefore,
> if I happen to be working on some remote part of this Planet, and
> thus using "somebody else's" UA, I'm not necessarily going to be
> able to just reconfigure it to use my "home" proxy.
>
> As Jonathan pointed out, one could utilise Route to achieve this
> goal, but there is no guarantee that a proxy will honour this,
> since it will previously have been unaware of this "call".
>
> I've always wondered if it might be useful to have SIP URLs
> slightly more expressive, so that routing can be slightly richer
> without any information being lost as it occurs.  And this seems
> as good a time as any to bring this point up.
>
> What I'm proposing, is a new SIP URL parameter, let's say: "proxy".
> The value of the "proxy" parameter is a `hostport'.
>
> This means that I can now roam to somebody else's domain, and
> send out an INVITE a la:
>     INVITE sip:alice@example.com;proxy=sip.ubiquity.net SIP/2.0
>     ...
> In which case the INVITE is routed through the UAs normal
> outbound proxy, as needed, and "sip.ubiquity.net" supercedes
> any normal routing decisions.
>
> This would seem to satisfy the "always use this proxy" requirement,
> whether an outbound proxy is in the loop or not.
>
> Futhermore, it helps with the following scenario...
>
> Say my public SIP Address is sip:jo@ubiquity.net, but today I'm
> going to be working at buffy.com, thus I would like all my calls
> to be routed through to buffy.com.  I plug in my laptop, and
> get allocated some private intranet IP via DHCP.  I would like
> to send a REGISTER to my proxy at ubiquity.net, but my IP is
> not globally routable, so the Contact address my UA deduces is
> useless; however, it is trivial for me to multicast a REGISTER
> locally for sip:jo@ubiquity.net.
>
> So how does the proxy serving ubiquity.net know to route messages
> to buffy.com?  Well, I can think of three solutions:
>  1) I send a REGISTER to ubiquity.net with my non-globally-routable
>     IP in the Contact, and some proxy at buffy.com rewrites the
>     Contact (and notes where I am for subsequent routing).
>  2) I have some sort of temporary account set up at buffy.com
>     by the Systems Administrator, say "sip:ubiquity-jo@buffy.com".
>     The necessary registrations are then done at both ubiquity.net
>     and buffy.com .
>  3) I register my Contact at ubiquity.net as
>     sip:jo@ubiquity.net;proxy=buffy.com
>
> I prefer 3), since maximum information is retained and very little
> messing around is required (i.e., we don't require any bastardisation
> of the message, nor extra staff).
>
> But in the end, I'm just bouncing this around, to see what people
> think.  Routing is already very flexible, so this might be only
> really useful for the constant threat of firewall, in which case
> other, probably rewriting-based, solutions are probably preferable
> (since they're probably already going to have to be in place).
>
> Thoughts?
>
> 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  Wed Sep 27 07: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 HAA08510
	for ; Wed, 27 Sep 2000 07: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 6F59144377; Wed, 27 Sep 2000 06:23:10 -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 A96F144351
	for ; Wed, 27 Sep 2000 06:22:50 -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 e8RBMfC28960;
	Wed, 27 Sep 2000 16:52:45 +0530 (IST)
Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2  (651.2 6-10-1998))  id 65256967.003ED801 ; Wed, 27 Sep 2000 16:56:25 +0530
X-Lotus-FromDomain: HSSBLR
From: archow@hss.hns.com
To: Joshua_Fox@vocaltec.com
Cc: sip@lists.bell-labs.com
Message-ID: <65256967.003ED786.00@sampark.hss.hns.com>
Subject: Re: [SIP] Intro to SIP
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, 27 Sep 2000 16:55:58 +0530




There good tutorials in http://www.cs.columbia.edu/sip/papers.html which
you want to look at.
(BTW, http://www.cs.columbia.edu/sip seems to be pretty much the
one-stop-shop for anything that is or rhymes with SIP :-p)

Regds
Arjun

--
Arjun Roychowdhury @ Hughes Software Systems





Joshua_Fox@vocaltec.com on 09/27/2000 05:37:02 PM

To:   sip@lists.bell-labs.com
cc:

Subject:  [SIP] Intro to SIP





I realize that SIP is so new that there might not yet be books and
tutorials, but I would still like to ask: Are any books, tutorials, or
introductory technical articles?

I am learning SIP straight from the RFP, but an intro might make it faster
to learn.

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 Sep 27 08:46: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 IAA10792
	for ; Wed, 27 Sep 2000 08:46: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 800B344369; Wed, 27 Sep 2000 07:46:10 -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 BF5D044345
	for ; Wed, 27 Sep 2000 07:45:03 -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 IAA07334;
	Wed, 27 Sep 2000 08:44:57 -0400 (EDT)
Received: from njb140bh2.ems.att.com by gab200r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2)
	id IAA15287; Wed, 27 Sep 2000 08:46:57 -0400 (EDT)
Received: by njb140bh2.ems.att.com with Internet Mail Service (5.5.2652.35)
	id ; Wed, 27 Sep 2000 08:44:56 -0400
Message-ID: 
From: "Roy, Radhika R, ALCOO" 
To: Lewis Karl-QA3387 ,
        "'Henning Schulzrinne'" ,
        sip@lists.bell-labs.com
Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP Mobility
	/Mobile IP)
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, 27 Sep 2000 08:44:54 -0400

Hi, Karl:

Mobile IP deals with mobility in the IP (network) layer.

SIP mobility deals with mobility in the application layer per se.

One of the fundamental questions that we have how much of the mobility
related problems to be abstracted to the application layer vs network layer.

Then the next question comes, if mobile IP has problems in proving solution,
should we go to the application layer (e.g., SIP session layer) to seek the
solution, or do we find an alternative solution in the network layer (e.g.,
IP layer)?

Some drafts (e.g., draft-itsumo-sip -mobility-req-01 and others) have just
started addressing those issues. However, more works in this area need to be
done.

Best regards,
Radhika R. Roy
AT&T

-----Original Message-----
From: Lewis Karl-QA3387 [mailto:K.Lewis@motorola.com]
Sent: Tuesday, September 26, 2000 5:38 PM
To: 'Henning Schulzrinne'; sip@lists.bell-labs.com
Subject: RE: [SIP] Attempt at summarizing current SIP drafts


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


From sip-admin@lists.bell-labs.com  Wed Sep 27 09: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 JAA11554
	for ; Wed, 27 Sep 2000 09:16: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 667634433A; Wed, 27 Sep 2000 08:16:10 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from giasmd01.vsnl.net.in (giasmd01.vsnl.net.in [202.54.6.1])
	by lists.bell-labs.com (Postfix) with ESMTP id 1F70244339
	for ; Wed, 27 Sep 2000 08:15:23 -0400 (EDT)
Received: from josetel ([203.197.240.103])
	by giasmd01.vsnl.net.in (8.9.3/8.9.3) with SMTP id SAA23030
	for ; Wed, 27 Sep 2000 18:53:18 +0530 (IST)
Message-ID: <00da01c02860$0cc6cae0$e564a8c0@josetel>
From: "Jose Cherian. P." 
To: 
References: 
Subject: Re: [SIP] PhoneJack Card Installation for Vovida stack
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, 27 Sep 2000 18:49:31 +1000
Content-Transfer-Encoding: 7bit

Hello,

We are trying to install and run the vovida SIP stack
on linux (RedHat 6.0)

We have purchased, the PCI internet phone jack card.
Where can we obtain the linux driver for this card?

Has anyone tried in these lines? please  help...

Thanks,
Jose Cherian. P.
Sr. Software Engineer,
Telecom Division
SSI Technologies P lt,
Chennai, INDIA 600 034





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


From sip-admin@lists.bell-labs.com  Wed Sep 27 10:01: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 KAA12188
	for ; Wed, 27 Sep 2000 10:01: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 0387444366; Wed, 27 Sep 2000 09:01:12 -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 F0BF444339
	for ; Tue, 26 Sep 2000 16:39:52 -0400 (EDT)
Received: from mabol ([200.21.27.154])
	by itecid1.telecom-co.net (8.9.3+Sun/8.9.1) with SMTP id QAA16954
	for ; Tue, 26 Sep 2000 16:46:43 +0500 (GMT)
Message-ID: <001a01c02802$44445b30$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_0017_01C027D8.5B546290"
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] zone-adjustments SDP 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, 26 Sep 2000 16:39:36 -0500

This is a multi-part message in MIME format.

------=_NextPart_000_0017_01C027D8.5B546290
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,
I'm developing a SDP parser. In the page 16 of the RFC 2327 says:
"Monthly and yearly repeats cannot currently be directly specified with =
a single SDP repeat time - instead separate "t" fields should be used to =
explicitly list the session times.=20

z=3D    ....  "

But in ABNF grammar for SDP in the same document say:

time-fields     =3D     1*( "t=3D" start-time space stop-time

                           *(CRLF repeat-fields) CRLF)

                            [zone-adjustments CRLF]=20

repeat-fields     =3D     "r=3D" repeat-interval space typed-time=20

                              1*(space typed-time)

zone-adjustments  =3D  time space ["-"] typed-time

                               *(space time space ["-"] typed-time)

Why isn't "z=3D" defined? Should I define it by myself?

Thanks a lot

Mauricio Bola=F1os Arturo  ITEC-TELECOM




------=_NextPart_000_0017_01C027D8.5B546290
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable










Hi,


I'm developing a SDP parser. In the =
page 16 of=20
the RFC 2327 says:




"Monthly and yearly repeats cannot currently be directly =
specified with=20
a single SDP repeat time - instead separate "t" fields should =
be used=20
to explicitly list the session times. 


z=3D<adjustment time> <offset> <adjustment time>=20
<offset> ....  "


But in ABNF grammar for SDP in the same document say:


time-fields     =3D     1*(=20
"t=3D" start-time space stop-time


           &nbs=
p;            =
;  =20
*(CRLF repeat-fields) CRLF)


           &nbs=
p;            =
;   =20
[zone-adjustments CRLF] 


repeat-fields     =3D    =20
"r=3D" repeat-interval space typed-time 


           &nbs=
p;            =
;     =20
1*(space typed-time)


zone-adjustments  =3D  time space ["-"] =
typed-time


           &nbs=
p;            =
;      =20
*(space time space ["-"] typed-time)


Why isn't "z=3D" defined? Should I define it by =
myself?


Thanks a lot


Mauricio Bolaños Arturo  ITEC-TELECOM


 


------=_NextPart_000_0017_01C027D8.5B546290--


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


From sip-admin@lists.bell-labs.com  Wed Sep 27 10:02: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 KAA12201
	for ; Wed, 27 Sep 2000 10:02: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 D72F54438F; Wed, 27 Sep 2000 09:01:30 -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 CF2D34433D
	for ; Wed, 27 Sep 2000 04:12:21 -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; 27 Sep 2000 09:12:40 UT
Received: from phoffer by ubiquity.net with SMTP (8.8.8+Sun/25-eef)
	id KAA04932; Wed, 27 Sep 2000 10:08:26 +0100 (BST)
Message-ID: <002701c02862$5eb0e050$5334c3c1@ubiquity.co.uk>
From: "Phil Hoffer" 
To: "Jonathan Rosenberg" , 
References: 
Subject: Re: [SIP] The Null authentication scheme
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, 27 Sep 2000 10:07:32 +0100
Content-Transfer-Encoding: 7bit

> I would argue that the server should have well defined mappings from
> strength of authentication to services provided. That is, if the UAC
chooses
> the null scheme, the server will accept that, but won't do much useful for
> that user.
>
> -Jonathan R.

Hi Jonathan,

I agree with your sentiments, but the UAC is forced to select the strongest
scheme from the ones detailed in the challenge.
That criteria is a MUST in rfc2617.

So for a UAC faced with two authentication schemes in a challenge, e.g.
Digest & Null, then the UAC has no choice (assuming it can perform Digest
authentication), according to rfc2617, but to respond using Digest
credentials. If the UAC selects the weaker scheme it violates rfc2617.

Presumably, a couple of things must occur:

1) The strength of the Null scheme must be defined with respect to other
schemes. I'm assuming that it will be classed as the weakest of the current
schemes.

2) If the mandatory strength condition for the UAC defined by 2617 is to be
loosened by the Null scheme then it must be documented. (Are you allowed to
loosen the mandatory condition?)

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 Sep 27 10:47: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 KAA13105
	for ; Wed, 27 Sep 2000 10:47: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 CBB7944397; Wed, 27 Sep 2000 09:47: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 90DCC44386
	for ; Wed, 27 Sep 2000 09:46: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; 27 Sep 2000 14:47:02 UT
Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef)
	id PAA22104; Wed, 27 Sep 2000 15:42:43 +0100 (BST)
From: "Jo Hornsby" 
To: "Jonathan Rosenberg" , ,
        
Subject: RE: [SIP] Outbound call routing
Message-ID: <001201c02891$31f2d260$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: 
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
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: Wed, 27 Sep 2000 15:42:43 +0100
Content-Transfer-Encoding: 7bit

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

Thoughts?


 - 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 Sep 27 10:55: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 KAA13372
	for ; Wed, 27 Sep 2000 10:55: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 6F55D44390; Wed, 27 Sep 2000 09:55:11 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from hotmail.com (f293.law7.hotmail.com [216.33.236.171])
	by lists.bell-labs.com (Postfix) with ESMTP id C587444390
	for ; Wed, 27 Sep 2000 09:54:13 -0400 (EDT)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Wed, 27 Sep 2000 07:54:05 -0700
Received: from 24.201.67.104 by lw7fd.law7.hotmail.msn.com with HTTP;	Wed, 27 Sep 2000 14:54:05 GMT
X-Originating-IP: [24.201.67.104]
Reply-To: egoine@iname.com
From: "Mathieu Gervais" 
To: pcjose@giasmd01.vsnl.net.in, sip@lists.bell-labs.com
Subject: Re: [SIP] PhoneJack Card Installation for Vovida stack
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: 
X-OriginalArrivalTime: 27 Sep 2000 14:54:05.0574 (UTC) FILETIME=[C836BA60:01C02892]
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
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, 27 Sep 2000 10:54:05 EDT

Hi,


As usual for vovida related questions, this discussion would be more suited 
for the Vovida mailing lists. (vovida.org, vovida.com)

(The drivers for linux can be obtained from quicknet site. They are also in 
the kernel usually, but you should always get the latest version from 
quicknet, quicknet.com)

Mathieu


>From: "Jose Cherian. P." 
>To: 
>Subject: Re: [SIP] PhoneJack Card Installation for Vovida stack
>Date: Wed, 27 Sep 2000 18:49:31 +1000
>
>Hello,
>
>We are trying to install and run the vovida SIP stack
>on linux (RedHat 6.0)
>
>We have purchased, the PCI internet phone jack card.
>Where can we obtain the linux driver for this card?
>
>Has anyone tried in these lines? please  help...
>
>Thanks,
>Jose Cherian. P.

_________________________________________________________________________
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 Sep 27 11:09: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 LAA13646
	for ; Wed, 27 Sep 2000 11: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 C4BB044395; Wed, 27 Sep 2000 10:09:12 -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 8213E44390
	for ; Wed, 27 Sep 2000 10:08:01 -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; 27 Sep 2000 15:08:19 UT
Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef)
	id QAA29166; Wed, 27 Sep 2000 16:03:57 +0100 (BST)
From: "Jo Hornsby" 
To: "Simon Barber" ,
        "Henning Schulzrinne" 
Cc: "Hisham Khartabil" ,
        ,
        "Jonathan Rosenberg" 
Subject: RE: [SIP] Outbound call routing
Message-ID: <001301c02894$2946cab0$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: 
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
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: Wed, 27 Sep 2000 16:03:57 +0100
Content-Transfer-Encoding: 7bit

> How would a current implementation of a proxy server handle this new
> URL parameter (route).

I would guess that most proxies today would ignore a Route header
embedded in a SIP URL.

> Would the parameter be ignored by current proxies, or would the
> request be rejected?

I would think it be unlikely that a current proxy would reject a
request as a result, but you never know.

> If current proxies would ignore the route, perhaps it would be 
> better to put the home outbound server (the destination we wish
> to loose route through) as the requestURI (so current
> implementations send the request in the right direction), and
> the final destination in the route parameter.  This way only
> the client, and the home outbound server need know about the new 
> parameter.

Ummm...no, this won't work, since the proxy will obey the Route
header (and thus ignore the Request-URI).

There is no problem here, however; the client just whacks an
extra Route that represents the "home outbound server" in before
the final destination Route (and so on).


 - 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 Sep 27 11: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 LAA13998
	for ; Wed, 27 Sep 2000 11: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 4589944372; Wed, 27 Sep 2000 10:22:11 -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 7EDD944395
	for ; Wed, 27 Sep 2000 10:21:20 -0400 (EDT)
Received: by mail.mediatrix.com with Internet Mail Service (5.5.2650.21)
	id ; Wed, 27 Sep 2000 11:13:59 -0400
Message-ID: 
From: Eric Tremblay 
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] Registrars and Date
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
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, 27 Sep 2000 11:13:58 -0400


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


From sip-admin@lists.bell-labs.com  Wed Sep 27 11:27: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 LAA14110
	for ; Wed, 27 Sep 2000 11: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 79B1C443A6; Wed, 27 Sep 2000 10:27:11 -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 B80D8443A5
	for ; Wed, 27 Sep 2000 10:26:40 -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 LAA19174;
	Wed, 27 Sep 2000 11:26:30 -0400 (EDT)
Message-ID: <39D211A6.7805F15E@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: Phil Hoffer 
Cc: Jonathan Rosenberg , sip@lists.bell-labs.com
Subject: Re: [SIP] The Null authentication scheme
References:  <002701c02862$5eb0e050$5334c3c1@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: Wed, 27 Sep 2000 11:26:30 -0400
Content-Transfer-Encoding: 7bit

Phil Hoffer wrote:
> 
> > I would argue that the server should have well defined mappings from
> > strength of authentication to services provided. That is, if the UAC
> chooses
> > the null scheme, the server will accept that, but won't do much useful for
> > that user.
> >
> > -Jonathan R.
> 
> Hi Jonathan,
> 
> I agree with your sentiments, but the UAC is forced to select the strongest
> scheme from the ones detailed in the challenge.
> That criteria is a MUST in rfc2617.
> 
> So for a UAC faced with two authentication schemes in a challenge, e.g.
> Digest & Null, then the UAC has no choice (assuming it can perform Digest
> authentication), according to rfc2617, but to respond using Digest
> credentials. If the UAC selects the weaker scheme it violates rfc2617.
> 
> Presumably, a couple of things must occur:
> 
> 1) The strength of the Null scheme must be defined with respect to other
> schemes. I'm assuming that it will be classed as the weakest of the current
> schemes.

Yes.

> 
> 2) If the mandatory strength condition for the UAC defined by 2617 is to be
> loosened by the Null scheme then it must be documented. (Are you allowed to
> loosen the mandatory condition?)

Before getting to worried about this aspect, it might be worthwhile to
review the motivation. The "UAC must choose strongest scheme" is meant
to avoid that the UAC or some third party snoop substitutes Basic when
Digest was called for, thus allowing it to subvert the authentication
intent. (Since the outcome after authentication is the same regardless
of whether a stronger or a weaker scheme was used.) Substituting Null
when the UAC can do Digest, say, helps neither the UAC (since it will
get inferior service) nor the intruder (since it could have generated
that unauthenticated request by itself).

-- 
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 Sep 27 11:41: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 LAA14495
	for ; Wed, 27 Sep 2000 11:41: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 F1CD6443A6; Wed, 27 Sep 2000 10:41:10 -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 9313B443A4
	for ; Wed, 27 Sep 2000 10:40:05 -0400 (EDT)
Received: from mailee.research.telcordia.com (mailee [192.4.7.23])
	by thumper.research.telcordia.com (8.10.1/8.10.1) with ESMTP id e8RFe0a07550;
	Wed, 27 Sep 2000 11:40:00 -0400 (EDT)
Received: from research.telcordia.com (VFaramak.cc.telcordia.com [128.96.54.222])
	by mailee.research.telcordia.com (8.9.3/8.9.3) with ESMTP id LAA06938;
	Wed, 27 Sep 2000 11:39:59 -0400 (EDT)
Message-ID: <39D214CB.BE3A3A5B@research.telcordia.com>
From: Faramak Vakil 
Organization: Telcordia Technologies
X-Mailer: Mozilla 4.51 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Lewis Karl-QA3387 
Cc: "'Henning Schulzrinne'" ,
        sip@lists.bell-labs.com
Subject: Re: [SIP] Attempt at summarizing current SIP drafts
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, 27 Sep 2000 11:39:55 -0400
Content-Transfer-Encoding: 7bit

We are actively working on these issues
in the ITSUMO project. We submitted
an ID, "Host Mobility Management Protocol"
 to IETF in October
1999. It is expired now, though we plan to post
its updated version by early November.

Regards, Faramak

Lewis Karl-QA3387 wrote:

> 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


From sip-admin@lists.bell-labs.com  Wed Sep 27 11:44: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 LAA14561
	for ; Wed, 27 Sep 2000 11:44: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 6D0D1443B4; Wed, 27 Sep 2000 10:42:11 -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 415CB443A4
	for ; Wed, 27 Sep 2000 10:37:35 -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 IAA06850;
	Wed, 27 Sep 2000 08:36:53 -0700 (PDT)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA04947; Wed, 27 Sep 2000 08:36:53 -0700 (PDT)
From: Michael Thomas 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14802.5141.143274.484448@thomasm-u1.cisco.com>
To: Henning Schulzrinne 
Cc: Phil Hoffer ,
        Jonathan Rosenberg , sip@lists.bell-labs.com
Subject: Re: [SIP] The Null authentication scheme
In-Reply-To: <39D211A6.7805F15E@cs.columbia.edu>
References: 
	<002701c02862$5eb0e050$5334c3c1@ubiquity.co.uk>
	<39D211A6.7805F15E@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: Wed, 27 Sep 2000 08:36:53 -0700 (PDT)
Content-Transfer-Encoding: 7bit


There seems to be a lot of conflation of
algorithms and users going on here.

I still don't understand why this is more desirable
than having a BCP which says that if you want to
authenticate as an anonymous user, use Basic with
guest/anonymous/null/whatever and no password.

This works for ftp, there doesn't seem to be a
burning need in http; why is SIP different in this
regard?

		Mike

Henning Schulzrinne writes:
 > Phil Hoffer wrote:
 > > 
 > > > I would argue that the server should have well defined mappings from
 > > > strength of authentication to services provided. That is, if the UAC
 > > chooses
 > > > the null scheme, the server will accept that, but won't do much useful for
 > > > that user.
 > > >
 > > > -Jonathan R.
 > > 
 > > Hi Jonathan,
 > > 
 > > I agree with your sentiments, but the UAC is forced to select the strongest
 > > scheme from the ones detailed in the challenge.
 > > That criteria is a MUST in rfc2617.
 > > 
 > > So for a UAC faced with two authentication schemes in a challenge, e.g.
 > > Digest & Null, then the UAC has no choice (assuming it can perform Digest
 > > authentication), according to rfc2617, but to respond using Digest
 > > credentials. If the UAC selects the weaker scheme it violates rfc2617.
 > > 
 > > Presumably, a couple of things must occur:
 > > 
 > > 1) The strength of the Null scheme must be defined with respect to other
 > > schemes. I'm assuming that it will be classed as the weakest of the current
 > > schemes.
 > 
 > Yes.
 > 
 > > 
 > > 2) If the mandatory strength condition for the UAC defined by 2617 is to be
 > > loosened by the Null scheme then it must be documented. (Are you allowed to
 > > loosen the mandatory condition?)
 > 
 > Before getting to worried about this aspect, it might be worthwhile to
 > review the motivation. The "UAC must choose strongest scheme" is meant
 > to avoid that the UAC or some third party snoop substitutes Basic when
 > Digest was called for, thus allowing it to subvert the authentication
 > intent. (Since the outcome after authentication is the same regardless
 > of whether a stronger or a weaker scheme was used.) Substituting Null
 > when the UAC can do Digest, say, helps neither the UAC (since it will
 > get inferior service) nor the intruder (since it could have generated
 > that unauthenticated request by itself).
 > 
 > -- 
 > 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 Sep 27 12:47: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 MAA16427
	for ; Wed, 27 Sep 2000 12:47: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 6415E44366; Wed, 27 Sep 2000 11:47:10 -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 C51874433D
	for ; Wed, 27 Sep 2000 11:46:44 -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 KAA04971;
	Wed, 27 Sep 2000 10:44:46 -0600 (MDT)
Message-ID: <39D22546.2506F174@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 ,
        "'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: Wed, 27 Sep 2000 10:50:14 -0600
Content-Transfer-Encoding: 7bit

Simon Barber wrote:

> I see the restriction on re-invite during ringing as dangerous. Media
> delivered during ringing might not be simply "ringback" to the caller, but
> might also include media delivered to the callee. This might be used, for
> example for:
>
> Audio paging to a telephone/telephones
> Delivering video of the caller early
> Delivering any push media channel, where the user wants to receive the
> channel without or before explicitly accepting the call.
>
> I think there are many possible services that could be created using this
> facility (obviously the user must have privacy controls for this type of
> call). Because of the range of services that might use push delivery without
> explicit acceptance it could potentially be dangerously limiting to not
> allow re-invite during ringing.
>
> 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.
>
> Simon Barber
>
> > -----Original Message-----
> > From: sip-admin@lists.bell-labs.com
> > [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Jonathan Rosenberg
> > Sent: Tuesday, September 26, 2000 8:10 PM
> > To: 'Tom-PT Taylor'; 'sip'
> > Subject: RE: [SIP] Re-direct of Media During Ringing
> >
> >
> > I don't follow the scenario. Can you elaborate?
> >
> > -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: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
> > > Sent: Monday, September 25, 2000 4:02 PM
> > > To: sip
> > > Subject: [SIP] Re-direct of Media During Ringing
> > >
> > >
> > > 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
> > >
> >
> > _______________________________________________
> > SIP mailing list
> > SIP@lists.bell-labs.com
> > http://lists.bell-labs.com/mailman/listinfo/sip
> >

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

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.

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.

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 Sep 27 12:50: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 MAA16492
	for ; Wed, 27 Sep 2000 12:50: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 5716F4438F; Wed, 27 Sep 2000 11:49:11 -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 85E4544387
	for ; Wed, 27 Sep 2000 11:48:48 -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 MAA09625;
	Wed, 27 Sep 2000 12:44:27 -0400 (EDT)
Message-ID: <39D224EC.F3D9CC8C@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=us-ascii
Content-Transfer-Encoding: 7bit
Subject: [SIP] A question on 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: Wed, 27 Sep 2000 12:48:45 -0400
Content-Transfer-Encoding: 7bit

Greetings!

I have a simple confusion about how to compute message digests for SIP Authorization headers using the HTTP

Digest authentication scheme.

According to Digest I need to use the request URI as part of the string over which I run tbe MD5 hash. However,

uri= may also be a part of the parameters supplied with Authorization header. I am assuming that :

1. If no such parameter is supplied, use the request URI in the request-line.

2. If such a parameter is supplied, then it takes precedence over the request URI in the request-line and gets

used in the hash computation. The bis RFC does say request URI but I am not sure then how the uri= parameter

of the authentication header parameter list comes into play.

Is this the right set of assumptions?

Thank you in advance for your help.

Ranga.

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




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


From sip-admin@lists.bell-labs.com  Wed Sep 27 13:35: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 NAA17934
	for ; Wed, 27 Sep 2000 13:35: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 8FBC34433A; Wed, 27 Sep 2000 12:35:11 -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 8435F44339
	for ; Wed, 27 Sep 2000 12:34:25 -0400 (EDT)
Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-33 #42261)
 id <0G1K00B013A59C@firewall.mcit.com> for sip@lists.bell-labs.com; Wed,
 27 Sep 2000 17:30:06 +0000 (GMT)
Received: from dgismtp04.wcomnet.com ([166.38.58.144])
 by firewall.mcit.com (PMDF V5.2-33 #42261)
 with ESMTP id <0G1K009903A5X8@firewall.mcit.com>; Wed,
 27 Sep 2000 17:30:05 +0000 (GMT)
Received: from CONVERSION-DAEMON by dgismtp04.wcomnet.com (PMDF V5.2-33 #42262)
 id <0G1K000013C24Y@dgismtp04.wcomnet.com>; Wed,
 27 Sep 2000 17:31:15 +0000 (GMT)
Received: from dgismtp04.wcomnet.com by dgismtp04.wcomnet.com
 (PMDF V5.2-33 #42262) with SMTP id <0G1K00N013BF46@dgismtp04.wcomnet.com>;
 Wed, 27 Sep 2000 17:31:14 +0000 (GMT)
Received: from C25776A ([166.44.138.169])
 by dgismtp04.wcomnet.com (PMDF V5.2-33 #42262)
 with SMTP id <0G1K00KBW395BA@dgismtp04.wcomnet.com>; Wed,
 27 Sep 2000 17:30:40 +0000 (GMT)
From: Henry Sinnreich 
Subject: RE: [SIP] Attempt at summarizing current SIP drafts
In-reply-to: 
To: Lewis Karl-QA3387 ,
        "'Henning Schulzrinne'" ,
        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: Wed, 27 Sep 2000 18:28:54 +0100
Content-Transfer-Encoding: 7bit

Given Karl's note, I would add the suggestion to add a link to,
or just add all drafts from
http://www.softarmor.com/sipwg/drafts

Many valuable drafts were out of scope of the SIP WG:
- Mobility: Itsumo (Telcordia)
- Home Appliances (Telordia)
- Message Waiting Indicator (Cisco)
- SIP for Hearing Disabled
- SIP-QoS-OSP
- AAAarch-SIP-OSP
- SIP for selecting MPLS routes (... and Crowcroft)
Remember, SIP is not only for telephony, but for any session...

Related WGs
- SPIRITS: Bjorkner (IN services), Gurbani,
- INAP: Faynberg, Slutsman
- ETSI SIP: Sijben, more...

My apology if I have ommitted some.

Henry

>-----Original Message-----
>From: sip-admin@lists.bell-labs.com
>[mailto:sip-admin@lists.bell-labs.com]On Behalf Of
>Lewis Karl-QA3387
>Sent: Tuesday, September 26, 2000 4:38 PM
>To: 'Henning Schulzrinne'; sip@lists.bell-labs.com
>Subject: RE: [SIP] Attempt at summarizing current SIP drafts
>
>
>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


From sip-admin@lists.bell-labs.com  Wed Sep 27 13: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 NAA18128
	for ; Wed, 27 Sep 2000 13:37: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 285D644387; Wed, 27 Sep 2000 12:36:12 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from microappliances.com (unknown [216.103.255.138])
	by lists.bell-labs.com (Postfix) with SMTP id 8418C4433A
	for ; Wed, 27 Sep 2000 12:35:41 -0400 (EDT)
Received: (qmail 54249 invoked by uid 100); 27 Sep 2000 17:35:31 -0000
Message-ID: <20000927173531.54248.qmail@microappliances.com>
From: shh@microappliances.com
To: Michael Thomas 
Reply-To: shh@microappliances.com
Cc: Henning Schulzrinne ,
        Phil Hoffer ,
        Jonathan Rosenberg , sip@lists.bell-labs.com
References:  <002701c02862$5eb0e050$5334c3c1@ubiquity.co.uk> <39D211A6.7805F15E@cs.columbia.edu> <14802.5141.143274.484448@thomasm-u1.cisco.com>
In-Reply-To: <14802.5141.143274.484448@thomasm-u1.cisco.com>
MIME-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 8bit
Subject: Re: [SIP] The Null authentication scheme
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: 27 Sep 2000 17:35:31 -0000
Content-Transfer-Encoding: 8bit


I think Michael is making a very good point here. There
is no real need to invent the NULL authentication scheme -
simply use another username which may have limited privileges.
(e.g user: anonymous, pass: abc@pgrs.com pretty much like anonymous
ftp). The system administrator can also create/allow/disallow such
a user, at will, with ease and without having to learn about a
new authentication scheme)

Actually Michael's idea seems more powerful as you can define
many classes of users, if one needs to do so at some other
time.

Thoughts?

Shiv

Quoting Michael Thomas :

> 
> There seems to be a lot of conflation of
> algorithms and users going on here.
>
> I still don't understand why this is more desirable
> than having a BCP which says that if you want to
> authenticate as an anonymous user, use Basic with
> guest/anonymous/null/whatever and no password.
>
> This works for ftp, there doesn't seem to be a
> burning need in http; why is SIP different in this
> regard?
>
> 		Mike

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


From sip-admin@lists.bell-labs.com  Wed Sep 27 13:45: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 NAA18593
	for ; Wed, 27 Sep 2000 13:45: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 B9C6B44387; Wed, 27 Sep 2000 12:45:12 -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 5499844366
	for ; Wed, 27 Sep 2000 11:32:55 -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 JAA22984;
	Wed, 27 Sep 2000 09:32:18 -0700 (PDT)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA04957; Wed, 27 Sep 2000 09:32:18 -0700 (PDT)
From: Michael Thomas 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14802.8465.886684.107395@thomasm-u1.cisco.com>
To: Lewis Karl-QA3387 
Cc: "'Henning Schulzrinne'" ,
        sip@lists.bell-labs.com
Subject: RE: [SIP] Attempt at summarizing current SIP drafts
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: Wed, 27 Sep 2000 09:32:17 -0700 (PDT)
Content-Transfer-Encoding: 7bit


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


From sip-admin@lists.bell-labs.com  Wed Sep 27 13:48: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 NAA18803
	for ; Wed, 27 Sep 2000 13:48: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 493DF443AD; Wed, 27 Sep 2000 12:46:11 -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 8E84244383
	for ; Wed, 27 Sep 2000 12:44:48 -0400 (EDT)
Received: from zrtpd004.us.nortel.com by zrtps06s.us.nortel.com;
          Wed, 27 Sep 2000 13:37:14 -0400
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) 
          id ; Wed, 27 Sep 2000 13:37:15 -0400
Message-ID: <28560036253BD41191A10000F8BCBD11480DF2@zcard00g.ca.nortel.com>
From: "Tom-PT Taylor" 
To: "'Jonathan Rosenberg'" ,
        "'sip'" 
Subject: RE: [SIP] Re-direct of Media During Ringing
X-Mailer: Internet Mail Service (5.5.2652.35)
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, 27 Sep 2000 13:37:00 -0400

Here's the bare requirement:

A calls B, passing SDP to set up a media path.

Occasionally while B is alerting user B (after it has passed a 180 Ringing
interim response), A recognizes a need to change the media path.  After the
final response from the initial INVITE has come back, the procedure for
doing this is obvious: send a re-INVITE with new SDP.  However, the way
RFC2543bis currently reads, this can't be done while alerting is still in
progress.

The race condition in the alerting case is obvious.  However, waiting until
user B answers means that user B's initial greeting is potentially lost
while the new path is set up.  I'm inclined to think the extra complexity of
implementing a re-INVITE nested within the original INVITE transaction is
worth the improvement in service to the subscriber, but I haven't actually
reviewed or written any SIP code.  What do implementors think?



> -----Original Message-----
> From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> Sent: Tuesday, September 26, 2000 11:10 PM
> To: Taylor, Tom-PT [NORSE:B901:EXCH]; 'sip'
> Subject: RE: [SIP] Re-direct of Media During Ringing
> 
> 
> I don't follow the scenario. Can you elaborate?
> 
> -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: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
> > Sent: Monday, September 25, 2000 4:02 PM
> > To: sip
> > Subject: [SIP] Re-direct of Media During Ringing
> > 
> > 
> > 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
> > 
> 

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


From sip-admin@lists.bell-labs.com  Wed Sep 27 13: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 NAA19229
	for ; Wed, 27 Sep 2000 13: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 CC53E443AD; Wed, 27 Sep 2000 12:56:10 -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 97FBF44393
	for ; Wed, 27 Sep 2000 12:55:07 -0400 (EDT)
Received: from zrtpd004.us.nortel.com (actually zrtpd004) 
          by ertpg14e1.nortelnetworks.com; Wed, 27 Sep 2000 13:51:38 -0400
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) 
          id ; Wed, 27 Sep 2000 13:51:38 -0400
Message-ID: <28560036253BD41191A10000F8BCBD11480DF3@zcard00g.ca.nortel.com>
From: "Tom-PT Taylor" 
To: "'Doug Harbert'" , Simon Barber 
Cc: Jonathan Rosenberg ,
        "'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_01C028AB.93BF4B80"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
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, 27 Sep 2000 13:51:34 -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_01C028AB.93BF4B80
Content-Type: text/plain;
	charset="iso-8859-1"

Are you saying that instead of a re-INVITE in such cases, one should issue a
new initial INVITE to open up a new session?

> -----Original Message-----
> From: Doug Harbert [mailto:dough@voyanttech.com]
> Sent: Wednesday, September 27, 2000 12:50 PM
> To: Simon Barber
> Cc: Jonathan Rosenberg; Taylor, Tom-PT [NORSE:B901:EXCH]; 'sip'
> Subject: Re: [SIP] Re-direct of Media During Ringing
> 
[PTT] snip
> 
> 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
> 
> 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.
> 
> 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.
> 
> Doug Harbert
> 
> 
> 
> 

------_=_NextPart_001_01C028AB.93BF4B80
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: [SIP] Re-direct of Media During Ringing




Are you saying that instead of a re-INVITE in such =
cases, one should issue a new initial INVITE to open up a new =
session?



> -----Original Message-----

> From: Doug Harbert [mailto:dough@voyanttech.com]

> Sent: Wednesday, September 27, 2000 12:50 =
PM

> To: Simon Barber

> Cc: Jonathan Rosenberg; Taylor, Tom-PT =
[NORSE:B901:EXCH]; 'sip'

> Subject: Re: [SIP] Re-direct of Media During =
Ringing

> 

[PTT] snip

> 

> 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

> 

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

> 

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

> 

> Doug Harbert

> 

> 

> 

> 





------_=_NextPart_001_01C028AB.93BF4B80--

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


From sip-admin@lists.bell-labs.com  Wed Sep 27 14:34: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 OAA20185
	for ; Wed, 27 Sep 2000 14:34: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 EC8DA44386; Wed, 27 Sep 2000 13:34:10 -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 C03D044383
	for ; Wed, 27 Sep 2000 13:33:59 -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 OAA08699;
	Wed, 27 Sep 2000 14:33:56 -0400 (EDT)
Received: from njb140bh2.ems.att.com by gab200r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2)
	id OAA16438; Wed, 27 Sep 2000 14:35:57 -0400 (EDT)
Received: by njb140bh2.ems.att.com with Internet Mail Service (5.5.2652.35)
	id ; Wed, 27 Sep 2000 14:33:56 -0400
Message-ID: 
From: "Roy, Radhika R, ALCOO" 
To: Michael Thomas , Lewis Karl-QA3387 
Cc: "'Henning Schulzrinne'" ,
        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, 27 Sep 2000 14:33:46 -0400

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


From sip-admin@lists.bell-labs.com  Wed Sep 27 14:48: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 OAA20437
	for ; Wed, 27 Sep 2000 14: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 4140444351; Wed, 27 Sep 2000 13:48:11 -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 38DC54433C
	for ; Wed, 27 Sep 2000 13:47:19 -0400 (EDT)
Received: from mailee.research.telcordia.com (mailee [192.4.7.23])
	by thumper.research.telcordia.com (8.10.1/8.10.1) with ESMTP id e8RIlBa17204;
	Wed, 27 Sep 2000 14:47:13 -0400 (EDT)
Received: from research.telcordia.com (VFaramak.cc.telcordia.com [128.96.54.222])
	by mailee.research.telcordia.com (8.9.3/8.9.3) with ESMTP id OAA08520;
	Wed, 27 Sep 2000 14:47:10 -0400 (EDT)
Message-ID: <39D240AD.7E22500B@research.telcordia.com>
From: Faramak Vakil 
Organization: Telcordia Technologies
X-Mailer: Mozilla 4.51 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Michael Thomas 
Cc: Lewis Karl-QA3387 ,
        "'Henning Schulzrinne'" ,
        sip@lists.bell-labs.com
Subject: Re: [SIP] Attempt at summarizing current SIP drafts
References:  <14802.8465.886684.107395@thomasm-u1.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, 27 Sep 2000 14:47:09 -0400
Content-Transfer-Encoding: 7bit

The document 
describes the requirement for a mobility management
scheme that uses SIP to support terminal, personal
and service mobility. It does not suggest/propose to use SIP
for setting up data sessions or making resource reservation
across the network.

Regards, Faramak

Michael Thomas wrote:

> 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


From sip-admin@lists.bell-labs.com  Wed Sep 27 16:01: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 QAA21617
	for ; Wed, 27 Sep 2000 16:01: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 3E2384433A; Wed, 27 Sep 2000 15:01:11 -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 2538E4438F
	for ; Wed, 27 Sep 2000 14:38:07 -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 MAA08856;
	Wed, 27 Sep 2000 12:33:17 -0700 (PDT)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA04975; Wed, 27 Sep 2000 12:32:53 -0700 (PDT)
From: Michael Thomas 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14802.19301.46600.693186@thomasm-u1.cisco.com>
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
	)
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: Wed, 27 Sep 2000 12:32:53 -0700 (PDT)
Content-Transfer-Encoding: 7bit


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


From sip-admin@lists.bell-labs.com  Wed Sep 27 16:04: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 QAA21689
	for ; Wed, 27 Sep 2000 16:04: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 4183D443B3; Wed, 27 Sep 2000 15:04:11 -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 B415A4439D
	for ; Wed, 27 Sep 2000 15:03:56 -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 QAA20164;
	Wed, 27 Sep 2000 16:03:51 -0400 (EDT)
Received: from njb140bh2.ems.att.com by njb140r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2)
	id QAA12684; Wed, 27 Sep 2000 16:02:28 -0400 (EDT)
Received: by njb140bh2.ems.att.com with Internet Mail Service (5.5.2652.35)
	id ; Wed, 27 Sep 2000 16:03:49 -0400
Message-ID: 
From: "Roy, Radhika R, ALCOO" 
To: Michael Thomas 
Cc: Michael Thomas , Lewis Karl-QA3387 ,
        "'Henning Schulzrinne'" ,
        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, 27 Sep 2000 16:03:46 -0400

Hi, Mike:

I do not think that anyone is saying - "SIP based application mobility is
Good Thing."

I think that I have clearly defined the problem (please see my email). 

For example, if a use starts talking using the SIP phone with another user
(fixed or mobile) and moves from one place to another while talking, do we
need to do any new work in the SIP layer as it stands today considering this
mobile environment (in this case it is continuous mobility)?

Let us do an analysis: 1. What needs to be done in the SIP layer, if any, 2.
What needs to be done in the IP layer (may be mobile IP if one likes to use
it), 3. What needs to be done in the link layer (e.g., wireless LANs,
cellular networks: CDMA, TDMA), and so and so forth.

In each layer there are two things: 1. Signaling and 2. Media.

For an end-to-end solution, one needs to analyze all things of all layers
together.

However, SIP WG only needs to confine itself to the SIP session layer in the
context SIP RFC 2543 only.

Hope this will clarify your concerns.

Best regards,
Radhika R. Roy
AT&T

-----Original Message-----
From: Michael Thomas [mailto:mat@cisco.com]
Sent: Wednesday, September 27, 2000 3: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


From sip-admin@lists.bell-labs.com  Wed Sep 27 17:23: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 RAA22730
	for ; Wed, 27 Sep 2000 17:23: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 F0EE144351; Wed, 27 Sep 2000 16:23:10 -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 7F6444433A
	for ; Wed, 27 Sep 2000 16:22:17 -0400 (EDT)
Received: by mail.mediatrix.com with Internet Mail Service (5.5.2650.21)
	id ; Wed, 27 Sep 2000 17:14:58 -0400
Message-ID: 
From: Eric Tremblay 
To: "'Robert Sparks'" , 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] REFER -> Referred-By syntax
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
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, 27 Sep 2000 17:14:58 -0400


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


From sip-admin@lists.bell-labs.com  Wed Sep 27 17: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 RAA22764
	for ; Wed, 27 Sep 2000 17:25: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 088EB44390; Wed, 27 Sep 2000 16:25:12 -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 AD08B44351
	for ; Wed, 27 Sep 2000 16:24:51 -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, 27 Sep 2000 14:22:49 -0700
From: "Simon Barber" 
To: 
Cc: "Jonathan Rosenberg" ,
        "'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_0074_01C0288E.E8C4E9E0"
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: <39D22546.2506F174@voyanttech.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, 27 Sep 2000 14:26:22 -0700

This is a multi-part message in MIME format.

------=_NextPart_000_0074_01C0288E.E8C4E9E0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

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

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

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

------=_NextPart_000_0074_01C0288E.E8C4E9E0
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_0074_01C0288E.E8C4E9E0--


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


From sip-admin@lists.bell-labs.com  Wed Sep 27 17:29: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 RAA22794
	for ; Wed, 27 Sep 2000 17:29: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 299C5443A0; Wed, 27 Sep 2000 16:28:11 -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 50167443AC
	for ; Wed, 27 Sep 2000 16:27:14 -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.31 2000/08/22 00:15:13 dmccart Exp $) with SMTP id VAA01016
	for ; Wed, 27 Sep 2000 21:28:12 GMT
Received: from fmsmsx28.fm.intel.com ([132.233.48.28]) by 132.233.48.205
  (Norton AntiVirus for Internet Email Gateways 1.0) ;
  Wed, 27 Sep 2000 21:27:09 0000 (GMT)
Received: by fmsmsx28.fm.intel.com with Internet Mail Service (5.5.2650.21)
	id ; Wed, 27 Sep 2000 14:27:08 -0700
Message-ID: <4148FEAAD879D311AC5700A0C969E8902D477D@orsmsx35.jf.intel.com>
From: "Gross, Gerhard" 
To: sip@lists.bell-labs.com
Cc: "Fenger, Russell J" 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [SIP] Usefulness of auth token
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
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, 27 Sep 2000 14:27:04 -0700

I have some questions regarding authorization
tokens for QoS in
http://www.ietf.org/internet-drafts/draft-dcsgroup-sip-call-auth-02.txt.

1) Is the auth token just a base64 encoded number
   or does it contain authentication (key/hash)
   information or media/call information as well?

2) Assuming that the auth token is just a number,
   since each side (UAC and UAS) generates
   their own auth token (a token is not shared)
   why are they necessary at all? The PDP-o and
   PDP-t store the media/bandwidth info (which
   is done anyway) in an "authorized flow" list only
   if the session is granted. The PDPs then compare
   this info with the corresponding info in the
   RSVP msgs which is also done anyway. If there
   is a match, the session has been authorized.
   What is the necessity of the auth token?

3) There is no mention of a clearinghouse type
   of entity in your draft. Is it assumed that
   the PDPs contact a clearinghouse behind the
   scenes? Perhaps mention of a clearinghouse
   is out of the scope of the draft.

Thank you in advance for any thoughts/responses.
Gery

        XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
        X                                         X
        X    Gerhard W. Gross, Ph.D.              X
        X    Intel                                X
        X    2111 NE 25th Ave                     X
        X    Hillsboro, OR 97124-5961, USA        X
        X    Internet Infrastructure Group        X
        X      - Internet and Communication Lab   X
        X    phone:    (503) 264-6389             X
        X    fax:      (503) 264-3483             X
        X    email:    gerhard.gross@intel.com    X
        X                                         X
        XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX



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


From sip-admin@lists.bell-labs.com  Wed Sep 27 17: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 RAA23049
	for ; Wed, 27 Sep 2000 17:45: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 1DCA24433C; Wed, 27 Sep 2000 16:45:12 -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 0896844339
	for ; Wed, 27 Sep 2000 16:44:03 -0400 (EDT)
Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-33 #42260)
 id <0G1K00701F1A76@firewall.mcit.com> for sip@lists.bell-labs.com; Wed,
 27 Sep 2000 21:43:58 +0000 (GMT)
Received: from dgismtp01.wcomnet.com ([166.38.58.141])
 by firewall.mcit.com (PMDF V5.2-33 #42260)
 with ESMTP id <0G1K003IZF1A9X@firewall.mcit.com>; Wed,
 27 Sep 2000 21:43:58 +0000 (GMT)
Received: from CONVERSION-DAEMON by dgismtp01.wcomnet.com (PMDF V5.2-33 #42262)
 id <0G1K00M01F1A40@dgismtp01.wcomnet.com>; Wed,
 27 Sep 2000 21:43:58 +0000 (GMT)
Received: from dgismtp01.wcomnet.com by dgismtp01.wcomnet.com
 (PMDF V5.2-33 #42262) with SMTP id <0G1K00M01F193R@dgismtp01.wcomnet.com>;
 Wed, 27 Sep 2000 21:43:58 +0000 (GMT)
Received: from C25776A ([166.44.138.190])
 by dgismtp01.wcomnet.com (PMDF V5.2-33 #42262)
 with SMTP id <0G1K00KFJF0N5K@dgismtp01.wcomnet.com>; Wed,
 27 Sep 2000 21:43:42 +0000 (GMT)
From: Henry Sinnreich 
Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP Mobility	)
In-reply-to: <14802.19301.46600.693186@thomasm-u1.cisco.com>
To: Michael Thomas , "Roy, Radhika R, ALCOO" 
Cc: Lewis Karl-QA3387 ,
        "'Henning Schulzrinne'" ,
        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: Wed, 27 Sep 2000 22:43:02 +0100
Content-Transfer-Encoding: 7bit

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

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


From sip-admin@lists.bell-labs.com  Wed Sep 27 18:08: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 SAA23437
	for ; Wed, 27 Sep 2000 18:08: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 5D2284433A; Wed, 27 Sep 2000 17:08: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 6FD4B44339
	for ; Wed, 27 Sep 2000 17:07:26 -0400 (EDT)
Received: from CINQUECENTO (DYN001-DA02A03-95.arcommunications.net [64.17.132.224])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with SMTP id SAA02662;
	Wed, 27 Sep 2000 18:05:29 -0400 (EDT)
From: "Robert Sparks" 
To: "Eric Tremblay" , 
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.00.2919.6700
In-Reply-To: 
Subject: [SIP] RE: REFER -> Referred-By syntax
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
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, 27 Sep 2000 17:00:11 -0500
Content-Transfer-Encoding: 7bit

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


From sip-admin@lists.bell-labs.com  Wed Sep 27 19:52: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 TAA25050
	for ; Wed, 27 Sep 2000 19:52: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 778DE4433A; Wed, 27 Sep 2000 18:52:11 -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 A1D4D44339
	for ; Wed, 27 Sep 2000 18:51:48 -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 TAA01804;
	Wed, 27 Sep 2000 19:51:42 -0400 (EDT)
Message-ID: <39D2880F.DB4F6DE2@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: Michael Thomas 
Cc: sip@lists.bell-labs.com
Subject: Re: [SIP] The Null authentication scheme
References: 
		<002701c02862$5eb0e050$5334c3c1@ubiquity.co.uk>
		<39D211A6.7805F15E@cs.columbia.edu> <14802.5141.143274.484448@thomasm-u1.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, 27 Sep 2000 19:51:43 -0400
Content-Transfer-Encoding: 7bit

Michael Thomas wrote:
> 
> There seems to be a lot of conflation of
> algorithms and users going on here.
> 
> I still don't understand why this is more desirable
> than having a BCP which says that if you want to
> authenticate as an anonymous user, use Basic with
> guest/anonymous/null/whatever and no password.
> 
> This works for ftp, there doesn't seem to be a
> burning need in http; why is SIP different in this
> regard?

One could argue that if Null had existed, we wouldn't have to have a
special name :-)

I generally agree that this is roughly equivalent. One advantage is that
it makes it more explicit whether anon. "login" is permissible or not.
With just a Basic challenge, I would have to try anon., then be told
"sorry". 

That said, I'm not wedded to the particular proposal, just to the need
for doing something along this line. Adding a sentence like

"It is RECOMMENDED that SIP servers utilize the user name "anonymous"
and password "[what should this be - empty?]" if it is desired to allow
non-authenticated requests. Such requests MAY receive treatment that
differs from authenticated requests."

doesn't require a BCP, I believe.
-- 
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 Sep 27 21:22: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 VAA26011
	for ; Wed, 27 Sep 2000 21:22: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 50AD04433A; Wed, 27 Sep 2000 20:22:21 -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 231A944339
	for ; Wed, 27 Sep 2000 20:21:27 -0400 (EDT)
Received: by mail.mediatrix.com with Internet Mail Service (5.5.2650.21)
	id ; Wed, 27 Sep 2000 20:57:59 -0400
Message-ID: 
From: Eric Tremblay 
To: "'Robert Sparks'" ,
        Eric Tremblay , 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: REFER -> Referred-By syntax
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
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, 27 Sep 2000 20:57:58 -0400


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


From sip-admin@lists.bell-labs.com  Thu Sep 28 00:59: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 AAA00558
	for ; Thu, 28 Sep 2000 00:59: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 38FCB4433A; Wed, 27 Sep 2000 23:59:11 -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 7552E44339
	for ; Wed, 27 Sep 2000 23:58:48 -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 EAA15135
	for ; Thu, 28 Sep 2000 04:58:41 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 WAA03110
	for ; Wed, 27 Sep 2000 22:58:33 -0600 (MDT)
Received: by n0195idc1.oss.level3.com with Internet Mail Service (5.5.2650.21)
	id ; Wed, 27 Sep 2000 23:00:23 -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] Content-type
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
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, 27 Sep 2000 22:58:26 -0600

Hello.
Is it a protocol violation for a SIP message to have a Content-type header
without a message body (i.e. Content-length=0)? Not that it makes any sense
to do so, but is it illegal??
Thanks,
Aparna

Aparna V.
Level (3) Communications.

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


From sip-admin@lists.bell-labs.com  Thu Sep 28 01:22: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 BAA03076
	for ; Thu, 28 Sep 2000 01: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 7ECF244370; Thu, 28 Sep 2000 00:22:11 -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 AC4C844366
	for ; Thu, 28 Sep 2000 00:21:21 -0400 (EDT)
Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-33 #42260)
 id <0G1L00M0107HTA@firewall.mcit.com> for sip@lists.bell-labs.com; Thu,
 28 Sep 2000 05:21:17 +0000 (GMT)
Received: from pmismtp03.wcomnet.com ([166.38.62.38])
 by firewall.mcit.com (PMDF V5.2-33 #42260)
 with ESMTP id <0G1L00ID307GJY@firewall.mcit.com>; Thu,
 28 Sep 2000 05:21:16 +0000 (GMT)
Received: from CONVERSION-DAEMON by pmismtp03.wcomnet.com (PMDF V5.2-33 #42258)
 id <0G1L0040102QH5@pmismtp03.wcomnet.com>; Thu,
 28 Sep 2000 05:18:26 +0000 (GMT)
Received: from pmismtp03.wcomnet.com by pmismtp03.wcomnet.com
 (PMDF V5.2-33 #42258) with SMTP id <0G1L0040102QH4@pmismtp03.wcomnet.com>;
 Thu, 28 Sep 2000 05:18:26 +0000 (GMT)
Received: from C25776A ([166.44.137.60])
 by pmismtp03.wcomnet.com (PMDF V5.2-33 #42258)
 with SMTP id <0G1K00FHNZQK52@pmismtp03.wcomnet.com>; Thu,
 28 Sep 2000 05:18:11 +0000 (GMT)
From: Henry Sinnreich 
Subject: RE: [SIP] Outbound call routing
In-reply-to: <56E7307B0850D411B1480008C75DD5EAB73CC7@enlrynt303.dsn.ericsson.se>
To: "'Henning Schulzrinne'" ,
        "Arnoud van Wijk (ETM)" 
Cc: Theodore Havinis , sip@lists.bell-labs.com,
        "'Simon Barber'" 
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: Thu, 28 Sep 2000 06:19:13 +0100
Content-Transfer-Encoding: 7bit

>I believe
>that the AAAArch group is working on this interdomain work

Theodore Havinis and I have submitted two drafts the the AAAarch
RG at the last IETF and they are still in the archive.
Any comments are welcome, since we would like to come to closure
on any open issues we may become aware of.
Please send us your comments.

Thanks, Henry



>-----Original Message-----
>From: sip-admin@lists.bell-labs.com
>[mailto:sip-admin@lists.bell-labs.com]On Behalf Of
>Arnoud van Wijk (ETM)
>Sent: Wednesday, September 27, 2000 8:25 AM
>To: 'Henning Schulzrinne'
>Cc: 'Simon Barber'; sip@lists.bell-labs.com
>Subject: RE: [SIP] Outbound call routing
>
>
>Henning.
>
>
>That is right. It is a broken idea..and quite unfriendly. :-)
>I did not say that I agree with this idea (even that I
>did suggest it), but it illustrates that this seems to
>be the only way to route the SIP messages to P4.
>
>Personally I think that the realistic solution will be
>that a visited network partner will do the services
>that is required for the roaming user (user A in this
>example). So, this would lead to trust between the
>home network and the visited network.
>(which is then a network operator issue, I believe
>that the AAAArch group is working on this interdomain work).
>
>Arnoud
>
>
>
>-----Original Message-----
>From: Henning Schulzrinne [
>mailto:schulzrinne@cs.columbia.edu
> ]
>Sent: dinsdag 26 sep 2000 17:46
>To: Arnoud van Wijk (ETM)
>Cc: 'Simon Barber'; sip@lists.bell-labs.com
>Subject: Re: [SIP] Outbound call routing
>
>
>"Arnoud van Wijk (ETM)" wrote:
>>
>> Hello Simon,
>>
>> Yes. I see the problem. I have been wrestling with
>similar architecture problems.
>> Right now, nothing can force the SIP messages from
>User A to go through P3 and P4.
>>
>> I think that the solution will be in forcing the
>client of User A to use the registrar of the home
>domain of user A. And then have P4 add itself in the
>via header (route header).
>> This means that P4 receives the location search
>request from user A when A places a call to B, and P4
>will then use the registrar to find the definite
>location of user B. Then P4 will send the SIP message
>with the IP address of user B's UA (via P5). But
>before P4 sends the SIP message, it will add itself to
>the via header or route header. (I am in a hurry,
>sorry for the sketchy details).
>>
>> Bottomline is that a roaming user should never be
>allowed to use the current domain's location
>server/registrar. Always ONLY the homedomain's locator
>servers. And then it is just a matter of the insertion
>of the desired servers.
>
>This is a fundamentally broken idea. This is not your
>grandpa's phone
>network. Any notion of "forcing" clients to do
>anything is just not a
>workable proposition in the Internet. In some
>circumstances, using the
>current ("visited") registrar makes perfect sense, so
>I see no reason to
>prohibit that.
>
>
>>
>> I will work this out in more detail if this is too unclear.
>>
>
>> Terminology:
>>
>> I have certainly helped confuse the issue by using
>unclear terminology -
>> specifically outbound server. Perhaps a clearer name
>might help the
>> discussion. Perhaps "home outbound proxy" HOB. This
>is a proxy server under
>> control of the user's home administrative domain,
>through which outbound
>> calls may be routed, to allow services on outbound
>calls. How this routing
>> is controlled and achieved is the subject of the discussion.
>>
>> The problem is:
>>
>> If the user is using a UA in a part of the network
>within his administrative
>> domain it is possible to arrange for his outbound
>calls to have some
>> processing applied under the control of his
>administrative domain, but if
>> the user is roaming in a network under another
>administrative domain there
>> is no mechanism for his home administrative domain
>to have any knowledge or
>> control of his outbound calls within the SIP specification.
>>
>> A diagram:
>> (switch to a fixed pitch font to view this)
>>
>> ........................        ....................
>>   Administrative       :        :Administrative
>>   domain X             :        :domain A, a.com
>>                        :        :
>> User A ----- P1 ----- P2 ----- P3 ----- P4 (HOB)
>>                        :     /  :
>> .......................:    /   :...................
>>   Administrative       :   /
>>   domain B, b.com      :  /
>>                        : /
>>          User B ----- P5
>>                        :
>> .......................:
>>
>> User A wishes to call User B - but the call must
>pass through proxy P4, user
>> A's home outbound server, so that a service can be
>applied to the call.
>>
>> Simon Barber.
>>
>> > -----Original Message-----
>> > From: sip-admin@lists.bell-labs.com
>> > [ mailto:sip-admin@lists.bell-labs.com
> ]On Behalf Of
>> > Jon.Peterson@Level3.com
>> > Sent: Monday, September 25, 2000 3:46 PM
>> > To: sip@lists.bell-labs.com
>> > Subject: RE: [SIP] Outbound call routing
>> >
>> >
>> >
>> > It seems to me that this discussion is considering
>two issues -
>> > firstly, how
>> > does a UA discover that it should use a particular PS as an
>> > outbound proxy,
>> > and secondly, how does the UA signal the first-hop
>and final
>> > destinations of
>> > the session in an INVITE. I think the second
>question can and should be
>> > considered independently from the first, as it has
>bearing on other
>> > architectures that require a very similar mechanism.
>> >
>> > For example, consider a case in which a UA sends
>an INVITE that reaches a
>> > local PS which then performs some sort of lookup
>and decides to
>> > forward the
>> > call to a remote PS in another administrative
>domain. In order to
>> > reach the
>> > remote PS, however, the local PS must send the
>call through a specific
>> > firewall - perhaps there are several firewalls in
>the local administrative
>> > domain, and one is a better way to reach the
>remote domain than
>> > the others.
>> > When it has made its decision about which specific
>firewall is
>> > the right one
>> > to traverse (which could have been discovered in
>any of a number of ways),
>> > it must use some mechanism in its signaling to the
>firewall to
>> > describe the
>> > first-hop server (the firewall itself) and the
>final destination
>> > (the remote
>> > PS). I see no reason why we couldn't use the same
>signaling mechanism for
>> > this that we would use in the UA-to-outbound-proxy
>case. It could be as
>> > simple as just sending the INVITE to the first-hop
>server with a
>> > Request-URI
>> > indicating the final destination. Or it could be,
>as has been suggested
>> > here, an early Route header (an idea that's fairly
>attractive to me). I'm
>> > not sure how this could be made compatible with
>DNS SRV records
>> > (for reasons
>> > similar to those brought up by Jo@ubiquity earlier
>in the thread), but I
>> > think SRV speaks more to the first issue than to
>the second anyway.
>> >
>> > As a bit of an aside, I'd also like to suggest
>that a UA should not break
>> > Record-Route regardless of any internally
>configured PS for outbound
>> > requests. That is, the outbound proxy routing
>mechanism should be
>> > consulted
>> > for new session requests only, not for requests
>associated with a
>> > pre-existing session. When the UA is the -caller-,
>if the outbound proxy
>> > chooses to add itself to the Record-Route, all
>future requests for the
>> > session will cross the outbound proxy, so this
>shouldn't be broken. What
>> > concerns me here are cases in which a UA is the
>-callee-, a Record-Route
>> > exists for the call that does not include the
>outbound proxy (for whatever
>> > reason), and the UA decides to a issue, say, a
>BYE, and is forced to break
>> > Record-Route in order to send it to the outbound
>proxy. This could lead to
>> > various problems. Ultimately, the inbound routing
>procedures should
>> > guarantee that the outbound proxy has the opportunity to
>> > Record-Route itself
>> > on the initial INVITE if this is appropriate; this
>shouldn't be
>> > retroactively enforced by a UA.
>> >
>> > Jon Peterson
>> > Level(3) Communications
>> >
>> > -----Original Message-----
>> > From: Simon Barber [ mailto:simon@firetalk.com
> ]
>> > Sent: Friday, September 22, 2000 6:48 PM
>> > To: Jo Hornsby; hch@ipdialog.com
>> > Cc: 'Sip@Lists. Bell-Labs. Com'
>> > Subject: RE: [SIP] Outbound call routing
>> >
>> >
>> > > > When a SIP message is first sent out from a
>UAC the requestURI could
>> > > > be set to the contents of the DNS SRV record
>"sipoutbound". When the
>> > > > INVITE reaches the user's outbound server,
>then the request URI
>> > > > would be set to the contents of the to:
>header. This assumes that
>> > > > the UA always wants the request routed to the
>to: header. Is this
>> > > > always true?
>> > >
>> > > I would say very likely to be true, for an
>initial INVITE.  I
>> > > would stay away from "always", however. &:)
>> >
>> > A valid argument. We should maintain the ability
>of the UAC to set
>> > the requestURI of the invite to whatever it wants.
>> >
>> > >
>> > > > This also changes the handling of the to: header. It is
>> > > > now not interpreted by the proxy servers
>between the terminal and
>> > > > the user's outbound server. This means that
>local semantics will not
>> > > > be applied. I guess sometimes this is good,
>sometimes bad!
>> > >
>> > > This is slightly problematic; how does a proxy
>know that it is
>> > > supposed to be interpreting the To: instead of
>the Request-URI?
>> > > Although I guess it's only the first proxy (the
>"home" proxy?)
>> > > after the firewall prox(y|ies) that needs to
>know that To is
>> > > overriding.  Hmmm...
>> > >
>> > > [...]
>> > > > Using the SRV record has the advantage that
>the UA does not need to
>> > > > be registered before outbound calling will
>work correctly. I see
>> > > > this decoupling of outbound and inbound
>calling as an important
>> > > > advantage.
>> > >
>> > > Using the SRV record also has the disadvantage
>that someone has to
>> > > be responsible for configuring the record for a
>user's address,
>> > > and since the granularity is at a domain level,
>this isn't that
>> > > flexible (I might like to have my own "outbound"
>proxy, that I'd
>> > > written with my own funky features, for instance).
>> >
>> > Hisham - Apologies, I have misunderstood your
>meaning for outbound server.
>> > By outbound server I mean a server that is part of
>my domain, that all my
>> > outbound requests will pass though (whether I am
>originating
>> > those requests
>> > from part of the network within my domain or not).
>> >
>> > I would suggest the sipoutbound SRV record is
>domain wide, not user
>> > specific - just like the SIP SRV record for
>incoming calls. If you
>> > want to use a specific server for your particular
>user, then you
>> > should have the server that handles the domain
>direct the request to
>> > a server that handles your particular user.
>> >
>> > Using a domain wide SRV record means that it's all
>or nothing for that
>> > domain, of course. This forces outbound requests
>to be routed
>> > like this for
>> > all users. Using the response to REGISTER means
>this is configurable on a
>> > user by user basis, but it does require the user
>be registered.
>> >
>> > >
>> > > The notion of using source routing mentioned
>earlier in this
>> > > thread, by embedding a Route header, as Anders
>and Sean suggested,
>> > > would seem to solve all of these problems, and
>it reuses existing
>> > > syntax quite nicely.  Plus -- as Sean pointed
>out -- it generalises
>> > > to multiple proxies; not to mention the
>possibilities with implying
>> > > other headers (State perhaps?).
>> > >
>> >
>> > Route does seem to be a neat solution. Excuse my
>ignorance, but
>> > why does it
>> > have to be embedded in the requestURI?
>> >
>> > Indeed I am not sure that we even need a separate
>SRV record for
>> > outbound and inbound calls at all. Why not simply
>say that a Route:
>> > header for initial requests should be set to the
>sip URL for the
>> > user making the request (normally also the
>contents of the From:
>> > header.).
>> >
>> > This way all outbound requests pass through the
>same server that
>> > handles the user's inbound calls. This should be
>completely compatible
>> > with current procedures. It does tie the server
>which handles services
>> > for outbound calls to the same server that handles
>services for inbound
>> > calls, but is this a problem?
>> >
>> > This also means that this form of outbound routing
>is used for all SIP
>> > requests, irrespective of whether this is required
>for services or not.
>> >
>> > In summary, 3 approaches:
>> >
>> > 1) configuration using REGISTER
>> > - outbound routing can be controlled on a per
>specific registration basis
>> >
>> > 2) configuration using SRV record
>> > - outbound routing can be controlled on a per domain basis
>> >
>> > 3) always route through user's home server
>> > - no option not to route through user's home server
>> >
>> > or
>> >
>> > 4) other method?
>> >
>> >
>> >
>> > > Do you forsee any problems with this approach?
>> >
>> > Seems very sensible!
>> >
>> > >
>> > > 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


--
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 Sep 28 01:50: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 BAA06907
	for ; Thu, 28 Sep 2000 01:50: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 D5FA744369; Thu, 28 Sep 2000 00:50:11 -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 E49D144366
	for ; Thu, 28 Sep 2000 00:49:53 -0400 (EDT)
Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-32 #42257)
 id <0G1L001011J2WB@firewall.mcit.com> for sip@lists.bell-labs.com; Thu,
 28 Sep 2000 05:49:50 +0000 (GMT)
Received: from pmismtp01.wcomnet.com ([166.38.62.36])
 by firewall.mcit.com (PMDF V5.2-32 #42257)
 with ESMTP id <0G1L00LBB1J2UI@firewall.mcit.com>; Thu,
 28 Sep 2000 05:49:50 +0000 (GMT)
Received: from CONVERSION-DAEMON by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258)
 id <0G1L00M011J1K8@pmismtp01.wcomnet.com>; Thu,
 28 Sep 2000 05:49:49 +0000 (GMT)
Received: from pmismtp01.wcomnet.com by pmismtp01.wcomnet.com
 (PMDF V5.2-33 #42258) with SMTP id <0G1L00M011J0K3@pmismtp01.wcomnet.com>;
 Thu, 28 Sep 2000 05:49:49 +0000 (GMT)
Received: from C25776A ([166.44.137.60])
 by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258)
 with SMTP id <0G1L007BJ1EJWF@pmismtp01.wcomnet.com>; Thu,
 28 Sep 2000 05:49:40 +0000 (GMT)
From: Henry Sinnreich 
Subject: RE: [SIP] Outbound call routing
In-reply-to: <56E7307B0850D411B1480008C75DD5EAB73CC7@enlrynt303.dsn.ericsson.se>
To: "Arnoud van Wijk (ETM)" 
Cc: Theodore Havinis , 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: Thu, 28 Sep 2000 06:48:32 +0100
Content-Transfer-Encoding: 7bit

>I believe
>that the AAAArch group is working on this interdomain work

Theodore Havinis and I have submitted two drafts the the AAAarch
RG at the last IETF and they are still in the archive.
Any comments are welcome, since we would like to come to closure
on any open issues we may become aware of.
Please send us your comments.

Thanks, Henry



>-----Original Message-----
>From: sip-admin@lists.bell-labs.com
>[mailto:sip-admin@lists.bell-labs.com]On Behalf Of
>Arnoud van Wijk (ETM)
>Sent: Wednesday, September 27, 2000 8:25 AM
>To: 'Henning Schulzrinne'
>Cc: 'Simon Barber'; sip@lists.bell-labs.com
>Subject: RE: [SIP] Outbound call routing
>
>
>Henning.
>
>
>That is right. It is a broken idea..and quite unfriendly. :-)
>I did not say that I agree with this idea (even that I
>did suggest it), but it illustrates that this seems to
>be the only way to route the SIP messages to P4.
>
>Personally I think that the realistic solution will be
>that a visited network partner will do the services
>that is required for the roaming user (user A in this
>example). So, this would lead to trust between the
>home network and the visited network.
>(which is then a network operator issue, I believe
>that the AAAArch group is working on this interdomain work).
>
>Arnoud
>
>
>
>-----Original Message-----
>From: Henning Schulzrinne [
>mailto:schulzrinne@cs.columbia.edu
> ]
>Sent: dinsdag 26 sep 2000 17:46
>To: Arnoud van Wijk (ETM)
>Cc: 'Simon Barber'; sip@lists.bell-labs.com
>Subject: Re: [SIP] Outbound call routing
>
>
>"Arnoud van Wijk (ETM)" wrote:
>>
>> Hello Simon,
>>
>> Yes. I see the problem. I have been wrestling with
>similar architecture problems.
>> Right now, nothing can force the SIP messages from
>User A to go through P3 and P4.
>>
>> I think that the solution will be in forcing the
>client of User A to use the registrar of the home
>domain of user A. And then have P4 add itself in the
>via header (route header).
>> This means that P4 receives the location search
>request from user A when A places a call to B, and P4
>will then use the registrar to find the definite
>location of user B. Then P4 will send the SIP message
>with the IP address of user B's UA (via P5). But
>before P4 sends the SIP message, it will add itself to
>the via header or route header. (I am in a hurry,
>sorry for the sketchy details).
>>
>> Bottomline is that a roaming user should never be
>allowed to use the current domain's location
>server/registrar. Always ONLY the homedomain's locator
>servers. And then it is just a matter of the insertion
>of the desired servers.
>
>This is a fundamentally broken idea. This is not your
>grandpa's phone
>network. Any notion of "forcing" clients to do
>anything is just not a
>workable proposition in the Internet. In some
>circumstances, using the
>current ("visited") registrar makes perfect sense, so
>I see no reason to
>prohibit that.
>
>
>>
>> I will work this out in more detail if this is too unclear.
>>
>
>> Terminology:
>>
>> I have certainly helped confuse the issue by using
>unclear terminology -
>> specifically outbound server. Perhaps a clearer name
>might help the
>> discussion. Perhaps "home outbound proxy" HOB. This
>is a proxy server under
>> control of the user's home administrative domain,
>through which outbound
>> calls may be routed, to allow services on outbound
>calls. How this routing
>> is controlled and achieved is the subject of the discussion.
>>
>> The problem is:
>>
>> If the user is using a UA in a part of the network
>within his administrative
>> domain it is possible to arrange for his outbound
>calls to have some
>> processing applied under the control of his
>administrative domain, but if
>> the user is roaming in a network under another
>administrative domain there
>> is no mechanism for his home administrative domain
>to have any knowledge or
>> control of his outbound calls within the SIP specification.
>>
>> A diagram:
>> (switch to a fixed pitch font to view this)
>>
>> ........................        ....................
>>   Administrative       :        :Administrative
>>   domain X             :        :domain A, a.com
>>                        :        :
>> User A ----- P1 ----- P2 ----- P3 ----- P4 (HOB)
>>                        :     /  :
>> .......................:    /   :...................
>>   Administrative       :   /
>>   domain B, b.com      :  /
>>                        : /
>>          User B ----- P5
>>                        :
>> .......................:
>>
>> User A wishes to call User B - but the call must
>pass through proxy P4, user
>> A's home outbound server, so that a service can be
>applied to the call.
>>
>> Simon Barber.
>>
>> > -----Original Message-----
>> > From: sip-admin@lists.bell-labs.com
>> > [ mailto:sip-admin@lists.bell-labs.com
> ]On Behalf Of
>> > Jon.Peterson@Level3.com
>> > Sent: Monday, September 25, 2000 3:46 PM
>> > To: sip@lists.bell-labs.com
>> > Subject: RE: [SIP] Outbound call routing
>> >
>> >
>> >
>> > It seems to me that this discussion is considering
>two issues -
>> > firstly, how
>> > does a UA discover that it should use a particular PS as an
>> > outbound proxy,
>> > and secondly, how does the UA signal the first-hop
>and final
>> > destinations of
>> > the session in an INVITE. I think the second
>question can and should be
>> > considered independently from the first, as it has
>bearing on other
>> > architectures that require a very similar mechanism.
>> >
>> > For example, consider a case in which a UA sends
>an INVITE that reaches a
>> > local PS which then performs some sort of lookup
>and decides to
>> > forward the
>> > call to a remote PS in another administrative
>domain. In order to
>> > reach the
>> > remote PS, however, the local PS must send the
>call through a specific
>> > firewall - perhaps there are several firewalls in
>the local administrative
>> > domain, and one is a better way to reach the
>remote domain than
>> > the others.
>> > When it has made its decision about which specific
>firewall is
>> > the right one
>> > to traverse (which could have been discovered in
>any of a number of ways),
>> > it must use some mechanism in its signaling to the
>firewall to
>> > describe the
>> > first-hop server (the firewall itself) and the
>final destination
>> > (the remote
>> > PS). I see no reason why we couldn't use the same
>signaling mechanism for
>> > this that we would use in the UA-to-outbound-proxy
>case. It could be as
>> > simple as just sending the INVITE to the first-hop
>server with a
>> > Request-URI
>> > indicating the final destination. Or it could be,
>as has been suggested
>> > here, an early Route header (an idea that's fairly
>attractive to me). I'm
>> > not sure how this could be made compatible with
>DNS SRV records
>> > (for reasons
>> > similar to those brought up by Jo@ubiquity earlier
>in the thread), but I
>> > think SRV speaks more to the first issue than to
>the second anyway.
>> >
>> > As a bit of an aside, I'd also like to suggest
>that a UA should not break
>> > Record-Route regardless of any internally
>configured PS for outbound
>> > requests. That is, the outbound proxy routing
>mechanism should be
>> > consulted
>> > for new session requests only, not for requests
>associated with a
>> > pre-existing session. When the UA is the -caller-,
>if the outbound proxy
>> > chooses to add itself to the Record-Route, all
>future requests for the
>> > session will cross the outbound proxy, so this
>shouldn't be broken. What
>> > concerns me here are cases in which a UA is the
>-callee-, a Record-Route
>> > exists for the call that does not include the
>outbound proxy (for whatever
>> > reason), and the UA decides to a issue, say, a
>BYE, and is forced to break
>> > Record-Route in order to send it to the outbound
>proxy. This could lead to
>> > various problems. Ultimately, the inbound routing
>procedures should
>> > guarantee that the outbound proxy has the opportunity to
>> > Record-Route itself
>> > on the initial INVITE if this is appropriate; this
>shouldn't be
>> > retroactively enforced by a UA.
>> >
>> > Jon Peterson
>> > Level(3) Communications
>> >
>> > -----Original Message-----
>> > From: Simon Barber [ mailto:simon@firetalk.com
> ]
>> > Sent: Friday, September 22, 2000 6:48 PM
>> > To: Jo Hornsby; hch@ipdialog.com
>> > Cc: 'Sip@Lists. Bell-Labs. Com'
>> > Subject: RE: [SIP] Outbound call routing
>> >
>> >
>> > > > When a SIP message is first sent out from a
>UAC the requestURI could
>> > > > be set to the contents of the DNS SRV record
>"sipoutbound". When the
>> > > > INVITE reaches the user's outbound server,
>then the request URI
>> > > > would be set to the contents of the to:
>header. This assumes that
>> > > > the UA always wants the request routed to the
>to: header. Is this
>> > > > always true?
>> > >
>> > > I would say very likely to be true, for an
>initial INVITE.  I
>> > > would stay away from "always", however. &:)
>> >
>> > A valid argument. We should maintain the ability
>of the UAC to set
>> > the requestURI of the invite to whatever it wants.
>> >
>> > >
>> > > > This also changes the handling of the to: header. It is
>> > > > now not interpreted by the proxy servers
>between the terminal and
>> > > > the user's outbound server. This means that
>local semantics will not
>> > > > be applied. I guess sometimes this is good,
>sometimes bad!
>> > >
>> > > This is slightly problematic; how does a proxy
>know that it is
>> > > supposed to be interpreting the To: instead of
>the Request-URI?
>> > > Although I guess it's only the first proxy (the
>"home" proxy?)
>> > > after the firewall prox(y|ies) that needs to
>know that To is
>> > > overriding.  Hmmm...
>> > >
>> > > [...]
>> > > > Using the SRV record has the advantage that
>the UA does not need to
>> > > > be registered before outbound calling will
>work correctly. I see
>> > > > this decoupling of outbound and inbound
>calling as an important
>> > > > advantage.
>> > >
>> > > Using the SRV record also has the disadvantage
>that someone has to
>> > > be responsible for configuring the record for a
>user's address,
>> > > and since the granularity is at a domain level,
>this isn't that
>> > > flexible (I might like to have my own "outbound"
>proxy, that I'd
>> > > written with my own funky features, for instance).
>> >
>> > Hisham - Apologies, I have misunderstood your
>meaning for outbound server.
>> > By outbound server I mean a server that is part of
>my domain, that all my
>> > outbound requests will pass though (whether I am
>originating
>> > those requests
>> > from part of the network within my domain or not).
>> >
>> > I would suggest the sipoutbound SRV record is
>domain wide, not user
>> > specific - just like the SIP SRV record for
>incoming calls. If you
>> > want to use a specific server for your particular
>user, then you
>> > should have the server that handles the domain
>direct the request to
>> > a server that handles your particular user.
>> >
>> > Using a domain wide SRV record means that it's all
>or nothing for that
>> > domain, of course. This forces outbound requests
>to be routed
>> > like this for
>> > all users. Using the response to REGISTER means
>this is configurable on a
>> > user by user basis, but it does require the user
>be registered.
>> >
>> > >
>> > > The notion of using source routing mentioned
>earlier in this
>> > > thread, by embedding a Route header, as Anders
>and Sean suggested,
>> > > would seem to solve all of these problems, and
>it reuses existing
>> > > syntax quite nicely.  Plus -- as Sean pointed
>out -- it generalises
>> > > to multiple proxies; not to mention the
>possibilities with implying
>> > > other headers (State perhaps?).
>> > >
>> >
>> > Route does seem to be a neat solution. Excuse my
>ignorance, but
>> > why does it
>> > have to be embedded in the requestURI?
>> >
>> > Indeed I am not sure that we even need a separate
>SRV record for
>> > outbound and inbound calls at all. Why not simply
>say that a Route:
>> > header for initial requests should be set to the
>sip URL for the
>> > user making the request (normally also the
>contents of the From:
>> > header.).
>> >
>> > This way all outbound requests pass through the
>same server that
>> > handles the user's inbound calls. This should be
>completely compatible
>> > with current procedures. It does tie the server
>which handles services
>> > for outbound calls to the same server that handles
>services for inbound
>> > calls, but is this a problem?
>> >
>> > This also means that this form of outbound routing
>is used for all SIP
>> > requests, irrespective of whether this is required
>for services or not.
>> >
>> > In summary, 3 approaches:
>> >
>> > 1) configuration using REGISTER
>> > - outbound routing can be controlled on a per
>specific registration basis
>> >
>> > 2) configuration using SRV record
>> > - outbound routing can be controlled on a per domain basis
>> >
>> > 3) always route through user's home server
>> > - no option not to route through user's home server
>> >
>> > or
>> >
>> > 4) other method?
>> >
>> >
>> >
>> > > Do you forsee any problems with this approach?
>> >
>> > Seems very sensible!
>> >
>> > >
>> > > 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


--
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 Sep 28 04:24: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 EAA15085
	for ; Thu, 28 Sep 2000 04:24: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 9B74D44339; Thu, 28 Sep 2000 03:24:11 -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 7D8AB44338
	for ; Thu, 28 Sep 2000 03:23:08 -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; 28 Sep 2000 08:23:27 UT
Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef)
	id JAA01556; Thu, 28 Sep 2000 09:20:20 +0100 (BST)
Message-ID: <39D2FF43.1FEC6B1F@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: Aparna.Vemuri@Level3.com
Cc: sip@lists.bell-labs.com
Subject: Re: [SIP] Content-type
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, 28 Sep 2000 09:20:19 +0100
Content-Transfer-Encoding: 7bit

Aparna.Vemuri@Level3.com wrote:
> 
> Hello.
> Is it a protocol violation for a SIP message to have a Content-type header
> without a message body (i.e. Content-length=0)? Not that it makes any sense
> to do so, but is it illegal??
> Thanks,
> Aparna

Although it would be odd for there to be a Content-Type header
and no body, I don't see this technically illegal (especially
if Content-Length was specified as 0).  I wouldn't rely on
Content-Type to imply the presence or otherwise of a body.

According to the IETF mantra I would say your implementation
should be strict enough not to generate this but flexible
enough to accept it.

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  Thu Sep 28 05:07: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 FAA15510
	for ; Thu, 28 Sep 2000 05: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 3995A44339; Thu, 28 Sep 2000 04:07:11 -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 11EAF44338
	for ; Thu, 28 Sep 2000 04:06:35 -0400 (EDT)
Received: from tate ([216.181.56.35]) by broadsoft.com (8.8.8) id FAA26210; Thu, 28 Sep 2000 05:06:32 -0400 (EDT)
Message-ID: <02e701c0292b$869f1900$3202a8c0@broadsoft.com>
From: "Brett Tate" 
To: 
References:  <39D2FF43.1FEC6B1F@ubiquity.net>
Subject: Re: [SIP] Content-type
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, 28 Sep 2000 05:07:28 -0400
Content-Transfer-Encoding: 7bit

> >
> > Hello.
> > Is it a protocol violation for a SIP message to have a Content-type
header
> > without a message body (i.e. Content-length=0)? Not that it makes any
sense
> > to do so, but is it illegal??
> > Thanks,
> > Aparna
>
> Although it would be odd for there to be a Content-Type header
> and no body, I don't see this technically illegal (especially
> if Content-Length was specified as 0).  I wouldn't rely on
> Content-Type to imply the presence or otherwise of a body.
>
> According to the IETF mantra I would say your implementation
> should be strict enough not to generate this but flexible
> enough to accept it.

I agree.  However should/could a proxy remove
the header before relaying the message since it
clearly violates the definition of Content-Type?
Or should a proxy leave it because some
SIP extension or vendor might extend its
definition?




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


From sip-admin@lists.bell-labs.com  Thu Sep 28 07:33: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 HAA17121
	for ; Thu, 28 Sep 2000 07:33: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 B5A2D4438B; Thu, 28 Sep 2000 06:33:10 -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 EAE0344338
	for ; Thu, 28 Sep 2000 06:32: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 e8SBW1t02617;
	Thu, 28 Sep 2000 13:32:01 +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 OAA17329;
	Thu, 28 Sep 2000 14:32:00 +0300 (EET DST)
Message-ID: <39D32C42.9A2F6A6A@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: draft-camarillo-sip-sdp-00.txt WAS [Re: [SIP] DTMF discussion from WG 
 meeting]
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, 28 Sep 2000 14:32:18 +0300
Content-Transfer-Encoding: 7bit

Hi,

In the last MMUSIC WG meeting the following draft was presented:
http://search.ietf.org/internet-drafts/draft-camarillo-sip-sdp-00.txt
The slides can be found at:
http://www2.ietf.org/proceedings/00jul/slides/mmusic-sdp-media-alignment.ppt

There were people expresing different opinions and the conclusion was
that further discussion was needed in the mailing list. I believe that
the competence needed to undertake these discussions can be found in
both, MMUSIC and SIP WGs. That's why this mail is sent to both mailing
lists.

A mechanism to allow a single RTP flow to be sent to different UDP ports
was found useful in general, but there were people who did not feel
comfortable about it.

I would like to hear all the problems that this might cause in order to
find the best possible solution.

If finally it is agreed that such as mechanism is needed, we will have
to agree also upon the format to be used. This draft outlines two
possible approaches, one more general and the other "more" backwards
compatible. 

Feedback is very much appreciated,

Thanks,

Gonzalo



"Culpepper, Bert" wrote:
> 
> I'm happy with the AVT tone format for transport of DTMF.  I can request
> that media type and direct it independently from other media.  I also expect
> to be able to use this media format independently and in addition to any
> other method for transporting DTMF or other "user input".  If an endpoint
> supports both RTP-DTMF and some event reporting mechanism (SUBSCRIBE/NOTIFY)
> then I expect I can request either or both.  The associated IDs and RFCs do
> not place any limitations on this that I can see.  If there are additional
> mechanisms - great.  I like choices.
> 
> I do look forward to seeing support for draft-camarillo-sip-sdp-00.txt.  I
> think this will encourage support for the transmission of multiple copies of
> a media "stream" to different destinations.  And I look forward to support
> for terminal events using SUBSCRIBE/NOTIFY.  I think this can help in
> addressing concerns with reliable delivery of user input.  Hopefully work in
> both of these areas moves along to completion.
> 
> Regards,
> Bert
> 
> -----Original Message-----
> From: Rohan Mahy [mailto:rohan@cisco.com]
> Sent: Wednesday, August 23, 2000 7:24 PM
> To: Jonathan Rosenberg
> Cc: Culpepper, Bert; sip@lists.bell-labs.com
> Subject: Re: [SIP] DTMF discussion from WG meeting
> 
> At 09:46 PM 8/3/00 , Jonathan Rosenberg wrote:
> >Rohan Mahy wrote:
> > >
> > > Hi,
> > >
> > > I think we may have a slightly different definition of first and
> third
> > > party.  I'd say that the moment an app switches from first to
> third, it
> > > becomes third party and can subscribe to DTMF events.  Perhaps I
> > should > that a first-party cannot *take action* on DTMF events, but
> a
> > thrid party
> > > should.
> > >
> > > If a 1st party app subscribes to DTMF events, there is a danger
> that it can
> > > count the same DTMF event twice (once from RTP, and once from the
> event).
> >
> >Sounds like the kind of nasty things that happen when there are two
> >completely different ways to do the same thing. As I suspect you will
> >not be able to cleanly define a role as either 1st or 3rd, with a
> clean
> >changeover during which you would never receive events
> 
> I think the definition is crystal clear, and most apps will always be
> one
> or the other.  maybe you will like this better:
> 
>          If your app will *ever* terminate audio,
>          then it must be ready to receive DTMF via AVT tones,
>          and must never subscribe to "keypress events"
> 
> This leaves "pure" 3rd party apps (of which there are still plenty),
> which
> will never, ever terminate any media.  I think that something like
> VoXML is
> a good model here.  Send the endpoint a script or document to run.  If
> the
> end user does something interesting (press some keys, say something
> intelligable, etc), then execute a URL.  The URL may fetch a new
> script,
> contain a REFER, an INVITE, a BYE, a REGISTER, etc...
> 
> >sounds like one
> >mechanism is the right way to go.
> 
> Lots of folks will want a VoXML-like model.  Only ever sending DTMF as
> AVT
> tones is limiting and short-sighted IMHO.
> 
> thanks,
> -rohan
> 
> _______________________________________________
> 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 Sep 28 08:57: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 IAA19020
	for ; Thu, 28 Sep 2000 08:57: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 121B444339; Thu, 28 Sep 2000 07:57:11 -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 9481E44338
	for ; Thu, 28 Sep 2000 07:56:59 -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 IAA12707;
	Thu, 28 Sep 2000 08:56:53 -0400 (EDT)
Message-ID: <39D34016.A427800@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: Aparna.Vemuri@Level3.com
Cc: sip@lists.bell-labs.com
Subject: Re: [SIP] Content-type
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, 28 Sep 2000 08:56:54 -0400
Content-Transfer-Encoding: 7bit

Aparna.Vemuri@Level3.com wrote:
> 
> Hello.
> Is it a protocol violation for a SIP message to have a Content-type header
> without a message body (i.e. Content-length=0)? Not that it makes any sense
> to do so, but is it illegal??

Hardly illegal, since (just about) any type can be of zero length. Added
a sentence that says to ignore it if the body is empty. 

-- 
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 Sep 28 09:19: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 JAA19505
	for ; Thu, 28 Sep 2000 09:19: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 A693C44370; Thu, 28 Sep 2000 08:19: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 EAFCB44338
	for ; Thu, 28 Sep 2000 08:18: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; 28 Sep 2000 13:18:25 UT
Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef)
	id OAA02458; Thu, 28 Sep 2000 14:15:08 +0100 (BST)
From: "Jo Hornsby" 
To: "Brett Tate" , 
Subject: RE: [SIP] Content-type
Message-ID: <002101c0294e$1f547330$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: <02e701c0292b$869f1900$3202a8c0@broadsoft.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
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: Thu, 28 Sep 2000 14:15:07 +0100
Content-Transfer-Encoding: 7bit


> > Although it would be odd for there to be a Content-Type header
> > and no body, I don't see this technically illegal (especially
> > if Content-Length was specified as 0).  I wouldn't rely on
> > Content-Type to imply the presence or otherwise of a body.
> >
> > According to the IETF mantra I would say your implementation
> > should be strict enough not to generate this but flexible
> > enough to accept it.
> 
> I agree.  However should/could a proxy remove
> the header before relaying the message since it
> clearly violates the definition of Content-Type?
> Or should a proxy leave it because some
> SIP extension or vendor might extend its
> definition?

I would be wary of proxies trying to be too clever here; in
general, they are completely ignorant of message bodies, and
I can see no good reason to remove this header (okay, so it
could potentially make the message a little shorter).

I don't think it's too much of a stretch of the imagination
to imagine a media type that defines zero-length to have
special, but well-defined, sematics; indeed, I would not be
surprised if many such media types already exist.

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 Sep 28 09:23: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 JAA19712
	for ; Thu, 28 Sep 2000 09:23: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 799F844370; Thu, 28 Sep 2000 08:23:11 -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 CA16444339
	for ; Thu, 28 Sep 2000 08:22: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 JAA13940;
	Thu, 28 Sep 2000 09:22:29 -0400 (EDT)
Message-ID: <39D34616.2FD0815E@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: sip@lists.bell-labs.com
Subject: Re: [SIP] Content-type
References:  <39D2FF43.1FEC6B1F@ubiquity.net> <02e701c0292b$869f1900$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: Thu, 28 Sep 2000 09:22:30 -0400
Content-Transfer-Encoding: 7bit

Brett Tate wrote:
> 
> > >
> > > Hello.
> > > Is it a protocol violation for a SIP message to have a Content-type
> header
> > > without a message body (i.e. Content-length=0)? Not that it makes any
> sense
> > > to do so, but is it illegal??
> > > Thanks,
> > > Aparna
> >
> > Although it would be odd for there to be a Content-Type header
> > and no body, I don't see this technically illegal (especially
> > if Content-Length was specified as 0).  I wouldn't rely on
> > Content-Type to imply the presence or otherwise of a body.
> >
> > According to the IETF mantra I would say your implementation
> > should be strict enough not to generate this but flexible
> > enough to accept it.
> 
> I agree.  However should/could a proxy remove
> the header before relaying the message since it
> clearly violates the definition of Content-Type?
> Or should a proxy leave it because some
> SIP extension or vendor might extend its
> definition?

Proxies are not the protocol police.

Also, technically, there is nothing wrong with 

Content-Type: text/plain
Content-Length: 0

Who says that a text object cannot have zero length?




-- 
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 Sep 28 10:38: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 KAA22298
	for ; Thu, 28 Sep 2000 10:38: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 DE6FB4433C; Thu, 28 Sep 2000 09:38:14 -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 A0BA544339
	for ; Wed, 27 Sep 2000 18:01:33 -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 QAA09469;
	Wed, 27 Sep 2000 16:00:56 -0700 (PDT)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id QAA04993; Wed, 27 Sep 2000 16:00:55 -0700 (PDT)
From: Michael Thomas 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14802.31783.840138.731419@thomasm-u1.cisco.com>
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	)
In-Reply-To: 
References: <14802.19301.46600.693186@thomasm-u1.cisco.com>
	
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
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, 27 Sep 2000 16:00:55 -0700 (PDT)
Content-Transfer-Encoding: 7bit

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


From sip-admin@lists.bell-labs.com  Thu Sep 28 10:40: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 KAA22370
	for ; Thu, 28 Sep 2000 10:40: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 10127443A1; Thu, 28 Sep 2000 09:38:39 -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 83D2444338
	for ; Thu, 28 Sep 2000 04:45: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; 28 Sep 2000 09:46:04 UT
Received: from phoffer by ubiquity.net with SMTP (8.8.8+Sun/25-eef)
	id KAA29529; Thu, 28 Sep 2000 10:43:05 +0100 (BST)
Message-ID: <001d01c02930$822efb60$5334c3c1@ubiquity.co.uk>
From: "Phil Hoffer" 
To: , 
Subject: Re: [SIP] A question on Digest Authentication.
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, 28 Sep 2000 10:43:08 +0100
Content-Transfer-Encoding: 7bit

> Greetings!
>
> I have a simple confusion about how to compute message digests for SIP
Authorization headers using
> the HTTP  Digest authentication scheme.
>
> According to Digest I need to use the request URI as part of the string
over which I run tbe MD5 hash.
> However,  uri= may also be a part of the parameters supplied with
Authorization header. I am assuming that :
 >
> 1. If no such parameter is supplied, use the request URI in the
request-line.
> 2. If such a parameter is supplied, then it takes precedence over the
request URI in the request-line and
> gets  used in the hash computation. The bis RFC does say request URI but I
am not sure then how the
> uri= parameter of the authentication header parameter list comes into
play.
>
 > Is this the right set of assumptions?
>
> Thank you in advance for your help.
>
> Ranga.

Hi Ranga,

rfc2617 mandates that the Authorization header MUST contain a digest-uri
parameter.
The digest-uri parameter is mandated as the Request-URI can be modified by
proxies in transit.
Therefore, when validating the credentials, the digest-uri value should be
taken from the credentials,
and not from the Request Line.

If the digest-uri parameter is missing from the credentials then the
response should be 400 Bad Request.
See section 3.2.2 of rfc2617.

HTH
Cheers
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  Thu Sep 28 10:42: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 KAA22421
	for ; Thu, 28 Sep 2000 10:42: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 6DA2D443A5; Thu, 28 Sep 2000 09:38:57 -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 AEDB644338
	for ; Thu, 28 Sep 2000 05:47:05 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16492;
	Thu, 28 Sep 2000 06:46:52 -0400 (EDT)
Message-Id: <200009281046.GAA16492@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-04.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, 28 Sep 2000 06:46:52 -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-04.txt
	Pages		: 7
	Date		: 27-Sep-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-04.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-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-sip-isup-mime-04.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

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

ENCODING mime
FILE /internet-drafts/draft-ietf-sip-isup-mime-04.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-sip-isup-mime-04.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20000927140107.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 Sep 28 11:06: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 LAA22891
	for ; Thu, 28 Sep 2000 11:06: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 E8A924439C; Thu, 28 Sep 2000 10:06:10 -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 A796E44338
	for ; Thu, 28 Sep 2000 10:05:17 -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 LAA01699;
	Thu, 28 Sep 2000 11:05:03 -0400 (EDT)
Received: from njb140bh1.ems.att.com by njb140r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2)
	id LAA12377; Thu, 28 Sep 2000 11:00:34 -0400 (EDT)
Received: by njb140bh1.ems.att.com with Internet Mail Service (5.5.2652.35)
	id ; Thu, 28 Sep 2000 11:01:56 -0400
Message-ID: 
From: "Roy, Radhika R, ALCOO" 
To: 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
		)
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, 28 Sep 2000 11:01:50 -0400

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


From sip-admin@lists.bell-labs.com  Thu Sep 28 11: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 LAA23761
	for ; Thu, 28 Sep 2000 11:37: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 060754439C; Thu, 28 Sep 2000 10:37:11 -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 329D744338
	for ; Thu, 28 Sep 2000 10:36:33 -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 LAA26280; Thu, 28 Sep 2000 11:36:21 -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 ABL30703;
	Thu, 28 Sep 2000 11:36:19 -0400 (EDT)
Message-Id: <4.3.2.7.2.20000928112401.00b15660@cia.cisco.com>
X-Sender: mhammer@cia.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
To: "Roy, Radhika R, ALCOO" , Michael Thomas ,
        Henry Sinnreich 
From: hammer michael 
Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP
  Mobility )
Cc: Lewis Karl-QA3387 ,
        "'Henning Schulzrinne'" ,
        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: Thu, 28 Sep 2000 11:40:55 -0700

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


From sip-admin@lists.bell-labs.com  Thu Sep 28 12: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 MAA24991
	for ; Thu, 28 Sep 2000 12: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 68B19443A1; Thu, 28 Sep 2000 11:09:11 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from hkueee2.eee.hku.hk (hkueee2.eee.hku.hk [147.8.180.60])
	by lists.bell-labs.com (Postfix) with ESMTP id 3243D44338
	for ; Thu, 28 Sep 2000 10:12:16 -0400 (EDT)
Received: (from nobody@localhost)
	by hkueee2.eee.hku.hk (8.11.0/8.11.0) id e8SFBub04485
	for sip@lists.bell-labs.com; Thu, 28 Sep 2000 23:11:56 +0800 (HKT)
From: Wong Pui Ling 
To: sip@lists.bell-labs.com
Message-ID: <970153916.39d35fbccf243@se4500a.eee.hku.hk>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: IMP/PHP IMAP webmail program 2.2.3-cvs
X-Originating-User: h9806552
X-Originating-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Windows 98; DigExt)
X-Originating-IP: 168.70.97.219
Subject: [SIP] Questions on 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: Thu, 28 Sep 2000 23:11:56 +0800 (HKT)
Content-Transfer-Encoding: 8bit

Dear all,
 I'm a final year student studying in University. And I had some
questions on SIP.
 
 I want to ask can I use SIP to support mobility in Internet Telephony?
Does SIP support multi-party call? (i.e. Can I join & leave the conference 
dynamically?)

 Thanks a lot. Please reply me as soon as possible. Thanks.

Regards,
Pauline

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


From sip-admin@lists.bell-labs.com  Thu Sep 28 12:11: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 MAA25073
	for ; Thu, 28 Sep 2000 12:11: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 ACD2D443C3; Thu, 28 Sep 2000 11:09:34 -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 ABC8944339
	for ; Thu, 28 Sep 2000 11:05:32 -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 JAA03390;
	Thu, 28 Sep 2000 09:04:54 -0700 (PDT)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA05242; Thu, 28 Sep 2000 09:04:52 -0700 (PDT)
From: Michael Thomas 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14803.27684.645056.731927@thomasm-u1.cisco.com>
To: "Roy, Radhika R, ALCOO" 
Cc: Michael Thomas , Henry Sinnreich ,
        Lewis Karl-QA3387 ,
        "'Henning Schulzrinne'" ,
        sip@lists.bell-labs.com
Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP Mobility
		)
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: Thu, 28 Sep 2000 09:04:52 -0700 (PDT)
Content-Transfer-Encoding: 7bit

Roy, Radhika R, ALCOO writes:
 > 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.

   OK.

 > If it is found that SIP does not need to be involved, I do not think that
 > anyone will force it to do this.

   Just to be pedantic about my concern: if the 
   reality of the situation is that mobile ip is
   going to be needed in the vast majority of 
   devices using SIP -- say because they have
   embedded web browsers -- as a group, IETF 
   would be better served by trying to solve
   the problem at layer 3 instead of each WG
   trying to tackle the problem on their own.

   Remember, the context of my concern here was
   the SIP mobility draft which seems to take
   application layer continuous mobility as a
   starting point.
 
 > 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)?

   By discrete mobility, I assume you mean that
   SIP doesn't repeat the PSTN'ism of assigning
   a name (phone number) to the physical end of a
   wire? Ie, that to: mat@cisco.com is divorced 
   from where I happen to be injecting IP packets 
   from? If so, I agree this is a Good Thing, but
   I'm not sure that there's much if anything to
   be done beyond that.

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

   Sure. I said up front that I'm willing to believe
   that real device layer mobility may very well dredge
   up problems that need to be solved at the SIP layer
   too.

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


From sip-admin@lists.bell-labs.com  Thu Sep 28 12:29: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 MAA25607
	for ; Thu, 28 Sep 2000 12:29: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 7A347443AC; Thu, 28 Sep 2000 11:29:11 -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 1D03444394
	for ; Thu, 28 Sep 2000 11:28: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 MAA06670;
	Thu, 28 Sep 2000 12:28:21 -0400 (EDT)
Received: from njb140bh2.ems.att.com by gab200r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2)
	id MAA16274; Thu, 28 Sep 2000 12:30:22 -0400 (EDT)
Received: by njb140bh2.ems.att.com with Internet Mail Service (5.5.2652.35)
	id ; Thu, 28 Sep 2000 12:28:21 -0400
Message-ID: 
From: "Roy, Radhika R, ALCOO" 
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
	 )
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, 28 Sep 2000 12:28:16 -0400

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


From sip-admin@lists.bell-labs.com  Thu Sep 28 12:48: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 MAA26212
	for ; Thu, 28 Sep 2000 12: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 00F7544394; Thu, 28 Sep 2000 11:48:10 -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 07BA344338
	for ; Thu, 28 Sep 2000 11:46:26 -0400 (EDT)
Received: from bigboy ([210.212.215.70])
	by hd2.dot.net.in (8.8.8/8.8.8) with SMTP id WAA22850
	for ; Thu, 28 Sep 2000 22:12:15 +0530 (IST)
Message-ID: <000801c0296b$fc8ad3d0$1200a8c0@bigboy>
From: "farhan" 
To: "sip" 
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] sip mobility with 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: Thu, 28 Sep 2000 22:15:08 +0530
Content-Transfer-Encoding: 7bit

i maybe a little naive here. but isn't REGISTER already covering a great
deal of mobility issues?

moblity will be, for a fact handled at lower levels. for instance,
bluetooth. On my Windows CE PDA, running off a bluetooth pcmcia card from
ericssons, I have little problem of mobility - bluetooth handles everything.

in the coming ICE age, i dont think we are going to be faced with exclusive
sip-only network. as per the RFC, sip is an application level protocol thus,
the transport layer issues are, well, transport level issues. The issue is
aren't we really talking about using a general purpose networking layer to
run SIP? If we are, then it is understood that SIP, http, and a host of
other application layer protocols for services being delivered over the
network will not have to reinvent their own mobility schemes which may also
work in separate ways. I mean, if my sip UA is in turn going to invoke a web
page that creates a http persistent session with cookies, i wouldn't want to
loose the continuity of the page as i move from one room to another while
the sip session goes on. Thus, it is essential to have the mobility issues
handled at a lower level. SIP is and should be an application layer
protocol. Lets

in anycase, what specific mobility issues are not handlable by the REGISTER
request? Are we also discussiing when REGISTER should be invoked? I dont
think that even that is a good idea to put on paper. Different types of
networks will have different approaches and needs. A mobile network may
derive their 'q' from signal strength and the registrar may have to decide
on a criterion different from a provider like hotsip which maybe searching
for a least-cost route (prefer a sip UA to a sip gateway).


- farhan




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


From sip-admin@lists.bell-labs.com  Thu Sep 28 12:59: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 MAA26424
	for ; Thu, 28 Sep 2000 12:59: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 846594438C; Thu, 28 Sep 2000 11:59: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 8237D44338
	for ; Thu, 28 Sep 2000 11:58: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 NAA09193;
	Thu, 28 Sep 2000 13:00:28 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id ; Thu, 28 Sep 2000 12:55:08 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'Michael Thomas'" ,
        "'Henning Schulzrinne'" 
Cc: "'Phil Hoffer'" ,
        Jonathan Rosenberg ,
        "'sip@lists.bell-labs.com'" 
Subject: RE: [SIP] The Null authentication scheme
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, 28 Sep 2000 12:55:07 -0400

Actually, I like this better too.

It does need to be documented somewhere, 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: Michael Thomas [mailto:mat@cisco.com]
> Sent: Wednesday, September 27, 2000 11:37 AM
> To: Henning Schulzrinne
> Cc: Phil Hoffer; Jonathan Rosenberg; sip@lists.bell-labs.com
> Subject: Re: [SIP] The Null authentication scheme
> 
> 
> 
> There seems to be a lot of conflation of
> algorithms and users going on here.
> 
> I still don't understand why this is more desirable
> than having a BCP which says that if you want to
> authenticate as an anonymous user, use Basic with
> guest/anonymous/null/whatever and no password.
> 
> This works for ftp, there doesn't seem to be a
> burning need in http; why is SIP different in this
> regard?
> 
> 		Mike
> 
> Henning Schulzrinne writes:
>  > Phil Hoffer wrote:
>  > > 
>  > > > I would argue that the server should have well defined 
> mappings from
>  > > > strength of authentication to services provided. That 
> is, if the UAC
>  > > chooses
>  > > > the null scheme, the server will accept that, but 
> won't do much useful for
>  > > > that user.
>  > > >
>  > > > -Jonathan R.
>  > > 
>  > > Hi Jonathan,
>  > > 
>  > > I agree with your sentiments, but the UAC is forced to 
> select the strongest
>  > > scheme from the ones detailed in the challenge.
>  > > That criteria is a MUST in rfc2617.
>  > > 
>  > > So for a UAC faced with two authentication schemes in a 
> challenge, e.g.
>  > > Digest & Null, then the UAC has no choice (assuming it 
> can perform Digest
>  > > authentication), according to rfc2617, but to respond 
> using Digest
>  > > credentials. If the UAC selects the weaker scheme it 
> violates rfc2617.
>  > > 
>  > > Presumably, a couple of things must occur:
>  > > 
>  > > 1) The strength of the Null scheme must be defined with 
> respect to other
>  > > schemes. I'm assuming that it will be classed as the 
> weakest of the current
>  > > schemes.
>  > 
>  > Yes.
>  > 
>  > > 
>  > > 2) If the mandatory strength condition for the UAC 
> defined by 2617 is to be
>  > > loosened by the Null scheme then it must be documented. 
> (Are you allowed to
>  > > loosen the mandatory condition?)
>  > 
>  > Before getting to worried about this aspect, it might be 
> worthwhile to
>  > review the motivation. The "UAC must choose strongest 
> scheme" is meant
>  > to avoid that the UAC or some third party snoop 
> substitutes Basic when
>  > Digest was called for, thus allowing it to subvert the 
> authentication
>  > intent. (Since the outcome after authentication is the 
> same regardless
>  > of whether a stronger or a weaker scheme was used.) 
> Substituting Null
>  > when the UAC can do Digest, say, helps neither the UAC 
> (since it will
>  > get inferior service) nor the intruder (since it could 
> have generated
>  > that unauthenticated request by itself).
>  > 
>  > -- 
>  > 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 Sep 28 13:03: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 NAA26529
	for ; Thu, 28 Sep 2000 13:03: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 49DDA443D2; Thu, 28 Sep 2000 12:02:12 -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 D605F443D1
	for ; Thu, 28 Sep 2000 12:01: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 MAA09181;
	Thu, 28 Sep 2000 12:59:28 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id ; Thu, 28 Sep 2000 12:54:08 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'Eric Tremblay'" ,
        "'Robert Sparks'" ,
        "'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: Thu, 28 Sep 2000 12:54:08 -0400

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  Thu Sep 28 13:33: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 NAA27345
	for ; Thu, 28 Sep 2000 13:33: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 DBE7C4433C; Thu, 28 Sep 2000 12:33:10 -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 1044544338
	for ; Thu, 28 Sep 2000 11:48:05 -0400 (EDT)
Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Thu Sep 28 12:46:39 EDT 2000
Received: by lists.bell-labs.com (Postfix)
	id 2988A4437D; Thu, 28 Sep 2000 12:33:30 -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 CAFEF44341
	for ; Thu, 28 Sep 2000 12:33:29 -0400 (EDT)
Received: by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2)
	id LAA04652; Thu, 28 Sep 2000 11:33:26 -0500
Cc: sip@lists.bell-labs.com
Received: from lucent.com by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2)
	id LAA04645; Thu, 28 Sep 2000 11:33:25 -0500
Message-ID: <39D372D1.1C4CF8B6@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: Wong Pui Ling 
Original-CC: sip@lists.bell-labs.com
Subject: Re: [SIP] Questions on SIP
References: <970153916.39d35fbccf243@se4500a.eee.hku.hk>
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, 28 Sep 2000 11:33:21 -0500
Content-Transfer-Encoding: 7bit

Wong Pui Ling wrote:
> 
> Dear all,
>  I'm a final year student studying in University. And I had some
> questions on SIP.
> 
>  I want to ask can I use SIP to support mobility in Internet 
> Telephony?
> Does SIP support multi-party call? (i.e. Can I join & leave the 
> conference dynamically?)
> 
>  Thanks a lot. Please reply me as soon as possible. Thanks.

The SIP FAQ (http://www.cs.columbia.edu/sip/faq/cache/1.html), the
SIP Home Page (http://www.cs.columbia.edu/sip/) and the SIP talk 
listing (http://www.cs.columbia.edu/sip/talks/), some of which include
SIP and Mobility should give you all the answers you're looking for.

- 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 Sep 28 13:40: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 NAA27590
	for ; Thu, 28 Sep 2000 13:40: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 C4A8C4433C; Thu, 28 Sep 2000 12:40:11 -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 A7E6F44339
	for ; Thu, 28 Sep 2000 12:39:20 -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 NAA04188;
	Thu, 28 Sep 2000 13:39:16 -0400 (EDT)
Received: from njb140bh1.ems.att.com by gab200r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2)
	id NAA21510; Thu, 28 Sep 2000 13:41:17 -0400 (EDT)
Received: by njb140bh1.ems.att.com with Internet Mail Service (5.5.2652.35)
	id ; Thu, 28 Sep 2000 13:39:16 -0400
Message-ID: 
From: "Roy, Radhika R, ALCOO" 
To: 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: Thu, 28 Sep 2000 13:39:11 -0400

Hi, Farhan:

I guess that you are right.

Yes, REGISTER can be used to update the location as one moves from one place
to another.

The only thing that you need is the support of the lower layer to resolve
the address as you move from place to place. In turn, the lower layer needs
to make the SIP layer aware that it need to re-REGISTER as the point of
attachment is changed. Accordingly, an re-INVITE message may be sent.

It clearly shows that the involvement of the SIP layer is very minimal. Do
we need any additional standard work in the SIP layer to couple the change
in the lower address to invoke the REGISTER message?

It appears that the location update (with single register with a single or
multiple registers with multiple domains) is the basic problem to solve
(Does this work need to be done in the SIP WG or other WGs?). According,
REGISTER and/or INVITE messages may be impacted.

That is all! I hope that other members will also provide comments on this.

Best regards,
Radhika R. Roy
AT&T

-----Original Message-----
From: farhan [mailto:farhan@hotfoon.com]
Sent: Thursday, September 28, 2000 12:45 PM
To: sip
Subject: [SIP] sip mobility with REGISTER


i maybe a little naive here. but isn't REGISTER already covering a great
deal of mobility issues?

moblity will be, for a fact handled at lower levels. for instance,
bluetooth. On my Windows CE PDA, running off a bluetooth pcmcia card from
ericssons, I have little problem of mobility - bluetooth handles everything.

in the coming ICE age, i dont think we are going to be faced with exclusive
sip-only network. as per the RFC, sip is an application level protocol thus,
the transport layer issues are, well, transport level issues. The issue is
aren't we really talking about using a general purpose networking layer to
run SIP? If we are, then it is understood that SIP, http, and a host of
other application layer protocols for services being delivered over the
network will not have to reinvent their own mobility schemes which may also
work in separate ways. I mean, if my sip UA is in turn going to invoke a web
page that creates a http persistent session with cookies, i wouldn't want to
loose the continuity of the page as i move from one room to another while
the sip session goes on. Thus, it is essential to have the mobility issues
handled at a lower level. SIP is and should be an application layer
protocol. Lets

in anycase, what specific mobility issues are not handlable by the REGISTER
request? Are we also discussiing when REGISTER should be invoked? I dont
think that even that is a good idea to put on paper. Different types of
networks will have different approaches and needs. A mobile network may
derive their 'q' from signal strength and the registrar may have to decide
on a criterion different from a provider like hotsip which maybe searching
for a least-cost route (prefer a sip UA to a sip gateway).


- farhan




_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
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 Sep 28 14: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 OAA29555
	for ; Thu, 28 Sep 2000 14:54: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 32C3B4438C; Thu, 28 Sep 2000 13:54:11 -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 C23E444339
	for ; Thu, 28 Sep 2000 13:07:55 -0400 (EDT)
Received: (qmail 18624 invoked by uid 1002); 28 Sep 2000 18:10:04 -0000
From: Dvir Oren 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: SIP 
X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs  Lucid
Message-ID: <14803.34874.915381.402119@jodie.lucid>
Subject: [SIP] received param
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
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, 28 Sep 2000 21:10:03 +0300 (IDT)
Content-Transfer-Encoding: 7bit

I ran into a problem with my SIP implementation when a UAS returned a
reply to a Proxy with a receiver-tagged Via.  The Proxy then wanted to 
check whether this reply is for itself, or to be proxied.  It first
looked at the first Via to see if it's its own Via.  It found the
receiver-tagged Via, and tried to compare it with what it knows about
itself.

What I did at this point is compare the IP addresses.  Unfortunately,
the DNS had only one of the IP addresses of the Proxy, while the UAS
saw the request coming from a different IP.  So, the Via's did not
match.

I did some hack which ignores the recieved tag.  I personally don't
like it.

Any other solutions?

-- 
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  Thu Sep 28 15: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 PAA00102
	for ; Thu, 28 Sep 2000 15:18: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 58B25443BE; Thu, 28 Sep 2000 14:18:11 -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 1644A44339
	for ; Thu, 28 Sep 2000 14:17:47 -0400 (EDT)
Received: by div8.net
	via sendmail from stdin
	id  (Debian Smail3.2.0.102)
	for sip@lists.bell-labs.com; Thu, 28 Sep 2000 14:17:36 -0500 (CDT) 
From: Billy Biggs 
To: "Roy, Radhika R, ALCOO" 
Cc: farhan , sip 
Subject: Re: [SIP] sip mobility with REGISTER
Message-ID: <20000928141735.A16632@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, Sep 28, 2000 at 01:39:11PM -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, 28 Sep 2000 14:17:36 -0500

  Hi Radhika,

> Yes, REGISTER can be used to update the location as one moves from one
> place to another.

  I think you are confused as to the general purpose of a REGISTER
message.  A REGISTER is intended to be used to inform the proxy of a new
point of contact for a user, not a new location for an active point of
contact.

  In other words, the intent of REGISTER is not to support mobility of a
physical terminal, but rather to support activation and shutdown of
distinct terminals: enabling my phone at home to being receiving calls
to my phone at work.  The two phones are distinct, but they do share my
public address.

  If a specific terminal is about to change IP addresses and you wish to
retain active sessions, I suggest you implement a Mobile-IP based system
which provides mobility at the IP layer, allowing active sessions to
continue without being updated, or a transport-layer solution which
provides mobility below the IP layer.  Anything that does NOT involve
modifying the IP address used by the terminal for its connections to the
Internet.  This will work without having to send any SIP messages at
all.  It also allows active TCP connections (such as HTTP traffic) to
also remain active during the transition.

  While INVITE and REGISTER may be used to attempt to achieve terminal
mobility, it seems to me that the consensus here is that it is a bad
idea.  This is because:

    1.  A SIP specific solution seems to be overkill and inconsistent.
    2.  High latency of SIP requests.  The re-INVITE may take alot of
	time to propagate and be accepted, and it may fail and have to
        be re-attempted.  Handover times may take many seconds, and may
        fail completely.

> It clearly shows that the involvement of the SIP layer is very
> minimal. Do we need any additional standard work in the SIP layer to
> couple the change in the lower address to invoke the REGISTER message?

  No.  Even to do the hacked solution of REGISTER'ing under the new
address and attempting to re-INVITE any active sessions, you don't need
to add any new modifications to SIP.

-- 
Billy Biggs, 3Com              Billy_Biggs@3com.com
http://www.div8.net/billy/          vektor@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 Sep 28 15:26: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 PAA00225
	for ; Thu, 28 Sep 2000 15:26: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 55D40443BE; Thu, 28 Sep 2000 14:26:11 -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 A2FF044339
	for ; Thu, 28 Sep 2000 14:25:19 -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 PAA29871; Thu, 28 Sep 2000 15:25:13 -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 ABL33353;
	Thu, 28 Sep 2000 15:25:11 -0400 (EDT)
Message-Id: <4.3.2.7.2.20000928150757.00adee90@cia.cisco.com>
X-Sender: mhammer@cia.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
To: "Roy, Radhika R, ALCOO" , Michael Thomas ,
        Henry Sinnreich 
From: hammer michael 
Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP
  Mobility )
Cc: Lewis Karl-QA3387 ,
        "'Henning Schulzrinne'" ,
        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: Thu, 28 Sep 2000 15:28:54 -0700

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


From sip-admin@lists.bell-labs.com  Thu Sep 28 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 PAA00766
	for ; Thu, 28 Sep 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 A705F443C6; Thu, 28 Sep 2000 14:50:11 -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 61AE3443C4
	for ; Thu, 28 Sep 2000 14:49:02 -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 PAA29533;
	Thu, 28 Sep 2000 15:48:52 -0400 (EDT)
Received: from njb140bh1.ems.att.com by gab200r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2)
	id PAA11686; Thu, 28 Sep 2000 15:50:52 -0400 (EDT)
Received: by njb140bh1.ems.att.com with Internet Mail Service (5.5.2652.35)
	id ; Thu, 28 Sep 2000 15:48:50 -0400
Message-ID: 
From: "Roy, Radhika R, ALCOO" 
To: Billy Biggs 
Cc: 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: Thu, 28 Sep 2000 15:48:39 -0400

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.

I guess that we do need a mobility solution in the IP layer (like mobile IP
and/or cellular IP).

One thing is for sure that there is a change in point of attachment (e.g.,
addresses). Now SIP layer also deal with addresses. It appears to me that
this change of addresses need to be propagated in the upper layer (e.g., SIP
layer) although the lower layer may use mobile IP and/or cellular IP. In
turn, it may trigger reREGISTER or re-INVITE messages.

Please note that the lower layer will deal with media diversion or
re-routing (SIP layer is not involved).

Is that a fair analysis?

Best regards,
Radhika R. Roy
AT&T

-----Original Message-----
From: Billy Biggs [mailto:vektor@div8.net]
Sent: Thursday, September 28, 2000 3:18 PM
To: Roy, Radhika R, ALCOO
Cc: farhan; sip
Subject: Re: [SIP] sip mobility with REGISTER


  Hi Radhika,

> Yes, REGISTER can be used to update the location as one moves from one
> place to another.

  I think you are confused as to the general purpose of a REGISTER
message.  A REGISTER is intended to be used to inform the proxy of a new
point of contact for a user, not a new location for an active point of
contact.

  In other words, the intent of REGISTER is not to support mobility of a
physical terminal, but rather to support activation and shutdown of
distinct terminals: enabling my phone at home to being receiving calls
to my phone at work.  The two phones are distinct, but they do share my
public address.

  If a specific terminal is about to change IP addresses and you wish to
retain active sessions, I suggest you implement a Mobile-IP based system
which provides mobility at the IP layer, allowing active sessions to
continue without being updated, or a transport-layer solution which
provides mobility below the IP layer.  Anything that does NOT involve
modifying the IP address used by the terminal for its connections to the
Internet.  This will work without having to send any SIP messages at
all.  It also allows active TCP connections (such as HTTP traffic) to
also remain active during the transition.

  While INVITE and REGISTER may be used to attempt to achieve terminal
mobility, it seems to me that the consensus here is that it is a bad
idea.  This is because:

    1.  A SIP specific solution seems to be overkill and inconsistent.
    2.  High latency of SIP requests.  The re-INVITE may take alot of
	time to propagate and be accepted, and it may fail and have to
        be re-attempted.  Handover times may take many seconds, and may
        fail completely.

> It clearly shows that the involvement of the SIP layer is very
> minimal. Do we need any additional standard work in the SIP layer to
> couple the change in the lower address to invoke the REGISTER message?

  No.  Even to do the hacked solution of REGISTER'ing under the new
address and attempting to re-INVITE any active sessions, you don't need
to add any new modifications to SIP.

-- 
Billy Biggs, 3Com              Billy_Biggs@3com.com
http://www.div8.net/billy/          vektor@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 Sep 28 16:03: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 QAA01007
	for ; Thu, 28 Sep 2000 16:03: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 08AE2443DC; Thu, 28 Sep 2000 15:03:10 -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 250A7443C6
	for ; Thu, 28 Sep 2000 15:02:33 -0400 (EDT)
Received: by div8.net
	via sendmail from stdin
	id  (Debian Smail3.2.0.102)
	for sip@lists.bell-labs.com; Thu, 28 Sep 2000 15:02:25 -0500 (CDT) 
From: Billy Biggs 
To: "Roy, Radhika R, ALCOO" 
Cc: farhan , sip 
Subject: Re: [SIP] sip mobility with REGISTER
Message-ID: <20000928150225.A16784@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, Sep 28, 2000 at 03:48:39PM -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, 28 Sep 2000 15:02:25 -0500

  Radhika,

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

  No, the bottom line of my argument is correctness of the solution.

> Let assume for sake of argument that there is no performance problem: Will
> the procedure work using REGISTER and re-INVITE?

  Yes it will work, in a sense of technically you can send SIP messages
which can effectively divert an active SIP session from one endpoint to
another.

  However, that solution is not the correct solution for solving the
more general problem of a mobile endpoint which uses communication
services which run over IP.

  If an endpoint decides to change IP addresses, what happens to any
active HTTP connections, or telnet connections, or TCP connections, or
SIP sessions?  A solution which solves the problem only for SIP sessions
seems to be a waste.

-- 
Billy Biggs, 3Com              Billy_Biggs@3com.com
http://www.div8.net/billy/          vektor@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 Sep 28 16:12: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 QAA01165
	for ; Thu, 28 Sep 2000 16:12: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 F2F7A4438C; Thu, 28 Sep 2000 15:12:11 -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 B522544339
	for ; Thu, 28 Sep 2000 15:11:54 -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 QAA09871;
	Thu, 28 Sep 2000 16:11:46 -0400 (EDT)
Received: from njb140bh1.ems.att.com by njb140r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2)
	id QAA03707; Thu, 28 Sep 2000 16:10:22 -0400 (EDT)
Received: by njb140bh1.ems.att.com with Internet Mail Service (5.5.2652.35)
	id ; Thu, 28 Sep 2000 16:11:44 -0400
Message-ID: 
From: "Roy, Radhika R, ALCOO" 
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
	 )
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, 28 Sep 2000 16:11:41 -0400

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


From sip-admin@lists.bell-labs.com  Thu Sep 28 16:24: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 QAA01370
	for ; Thu, 28 Sep 2000 16:24: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 04106443E6; Thu, 28 Sep 2000 15:24:11 -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 A60AB443E3
	for ; Thu, 28 Sep 2000 15:23:51 -0400 (EDT)
Received: from bigboy ([210.212.215.0])
	by hd2.dot.net.in (8.8.8/8.8.8) with SMTP id BAA17417
	for ; Fri, 29 Sep 2000 01:49:51 +0530 (IST)
Message-ID: <000001c0298a$5e265510$1200a8c0@bigboy>
From: "farhan" 
To: "sip" 
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] distributed 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: Fri, 29 Sep 2000 00:03:42 +0530
Content-Transfer-Encoding: 7bit

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 am placing this architecture for review because of my interest in getting
sip into smaller stacks. With an approach wherein, we locate the sip stack
on a central host and attach the communication end points as slaves of
host, we retain all the goods of sip while at the same time we will be able
to afford far simpler and leaner clients. All we need to ensure is that the
end points are in themselves capable of handling RTP.

our hotfoon.com deployment is on similar lines. i can well imagine this as a
route to interoperability with other protocols too.
we can consider the communication endpoints to be some sort of "remote
device drivers" of the sip stack that communicate with sip stack using some
very simple protocol (just two calls: setup and clear down). Our hotfoon
client is just a 48kb slave totally controlled by hotfoon.com. As a result.,
we never upgrade our client, we only upgrade the server at hotfoon.com.

i am considering using this approach on our hotfoon deployment. will there
be any issues of interoperability?

- farhan



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


From sip-admin@lists.bell-labs.com  Thu Sep 28 16:38: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 QAA01602
	for ; Thu, 28 Sep 2000 16:38: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 892F24438C; Thu, 28 Sep 2000 15:38:11 -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 2E7DE44339
	for ; Thu, 28 Sep 2000 15:37:30 -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 QAA10791;
	Thu, 28 Sep 2000 16:37:17 -0400 (EDT)
Received: from njb140bh1.ems.att.com by njb140r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2)
	id QAA18365; Thu, 28 Sep 2000 16:35:55 -0400 (EDT)
Received: by njb140bh1.ems.att.com with Internet Mail Service (5.5.2652.35)
	id ; Thu, 28 Sep 2000 16:37:17 -0400
Message-ID: 
From: "Roy, Radhika R, ALCOO" 
To: Billy Biggs 
Cc: 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: Thu, 28 Sep 2000 16:37:08 -0400

Hi, Billy:

Let me clarify again:

I am assuming that the general mobility problems are being addressed in each
layer as necessary. For example, mobile/cellular IP for the IP layer.
TDMA/CDMA-based cellular wireless mobility solution for the link layer, and
so on. These are all complementary solutions.

However, there is one fundamental point: Change in point of attachment in
the mobile environment.

The next question is: Whether or not this change in point of attachment will
cause any change in the address of the link layer, network layer, and/or
other layers.

Depending on this "change of address," each layer has to take the
appropriate action.

If any layer is transparent to this change of address, no action is
necessary.

(Again in the application layer, each application may express the addresses
in different ways. For example, SIP and H.323 have different addressing
schemes. It is very important to note that, in the network/link layer, it is
may not be the case.)

If we follow the above principles, we can easily find out what needs to be
done in each layer.

Hope this will clarify your points.

Best regards,
Radhika R. Roy
AT&T

-----Original Message-----
From: Billy Biggs [mailto:vektor@div8.net]
Sent: Thursday, September 28, 2000 4:02 PM
To: Roy, Radhika R, ALCOO
Cc: farhan; sip
Subject: Re: [SIP] sip mobility with REGISTER


  Radhika,

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

  No, the bottom line of my argument is correctness of the solution.

> Let assume for sake of argument that there is no performance problem: Will
> the procedure work using REGISTER and re-INVITE?

  Yes it will work, in a sense of technically you can send SIP messages
which can effectively divert an active SIP session from one endpoint to
another.

  However, that solution is not the correct solution for solving the
more general problem of a mobile endpoint which uses communication
services which run over IP.

  If an endpoint decides to change IP addresses, what happens to any
active HTTP connections, or telnet connections, or TCP connections, or
SIP sessions?  A solution which solves the problem only for SIP sessions
seems to be a waste.

-- 
Billy Biggs, 3Com              Billy_Biggs@3com.com
http://www.div8.net/billy/          vektor@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 Sep 28 17: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 RAA02427
	for ; Thu, 28 Sep 2000 17:12: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 BB0854438C; Thu, 28 Sep 2000 16:12:10 -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 B248144339
	for ; Thu, 28 Sep 2000 16:11:34 -0400 (EDT)
Received: by div8.net
	via sendmail from stdin
	id  (Debian Smail3.2.0.102)
	for sip@lists.bell-labs.com; Thu, 28 Sep 2000 16:11:28 -0500 (CDT) 
From: Billy Biggs 
To: "Roy, Radhika R, ALCOO" 
Cc: farhan , sip 
Subject: Re: [SIP] sip mobility with REGISTER
Message-ID: <20000928161128.A16903@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, Sep 28, 2000 at 04:37:08PM -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, 28 Sep 2000 16:11:28 -0500

  Radhika,

> However, there is one fundamental point: Change in point of attachment
> in the mobile environment.  [...]   Depending on this "change of
> address," each layer has to take the appropriate action.  If any layer
> is transparent to this change of address, no action is necessary.

  The IP layer has no concept of mobility, and IP addresses are used
casually in upper-layer protocols.  As well, all protocols which run
over IP assume that the IP addresses used do not change mid-session.
So, any mobility solution in an IP network MUST NOT allow the IP address
of an active session to change.

  This means that IP mobility can only be implemented through address
changes in the lower layers, tunnelling through a 3rd party with a fixed
IP address, or informing the routers of new route information for a
specific address.

  Because of this architecture, applications built on IP are guarenteed
that they do not need to worry about mobility, since it is unsupported
by the IP layer they are built on.

  Since SIP is built on IP, by definition no changes need to be made to
SIP to support terminal mobility.

  The mechanisms SIP provides for doing SIP "mobility" are addressing a
different problem: that of user mobility, not endpoint mobility.  While
I agree that you can get away with updating a session endpoint in SIP, I
don't believe this solution should be in any way associated with the
concept of endpoint mobility.

-- 
Billy Biggs, 3Com              Billy_Biggs@3com.com
http://www.div8.net/billy/          vektor@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 Sep 28 17:29: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 RAA03009
	for ; Thu, 28 Sep 2000 17:29: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 1CEF9443E3; Thu, 28 Sep 2000 16:29:12 -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 10BD644339
	for ; Thu, 28 Sep 2000 16:28:08 -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 PAA02930;
	Thu, 28 Sep 2000 15:26:09 -0600 (MDT)
Message-ID: <39D3B8AE.4FDF4590@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: Tom-PT Taylor 
Cc: Simon Barber ,
        Jonathan Rosenberg ,
        "'sip'" 
Subject: Re: [SIP] Re-direct of Media During Ringing
References: <28560036253BD41191A10000F8BCBD11480DF3@zcard00g.ca.nortel.com>
Content-Type: multipart/alternative;
 boundary="------------A4175876C0FFEA84F3888B3C"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
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, 28 Sep 2000 15:31:27 -0600


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

Tom-PT Taylor wrote:

>
>
> Are you saying that instead of a re-INVITE in such cases, one should
> issue a new initial INVITE to open up a new session?
>
> > -----Original Message-----
> > From: Doug Harbert [mailto:dough@voyanttech.com]
> > Sent: Wednesday, September 27, 2000 12:50 PM
> > To: Simon Barber
> > Cc: Jonathan Rosenberg; Taylor, Tom-PT [NORSE:B901:EXCH]; 'sip'
> > Subject: Re: [SIP] Re-direct of Media During Ringing
> >
> [PTT] snip
> >
> > 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
> >
> > 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.
> >
> > 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.
> >
> > Doug Harbert
> >
> >
> >
> >

Tom:
    Yes, rather than issuing a re-INVITE before the final response (200)
has been received, it seems to me that we should
CANCEL the initial INVITE, and issue a new INVITE to start a new
session. However, once the session has been established,
re-INVITE is a perfectly appropriate way to change session parameters.

Doug Harbert.

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



Tom-PT Taylor wrote:

 

Are you saying that instead of a re-INVITE in such cases,
one should issue a new initial INVITE to open up a new session?

> -----Original Message-----

> From: Doug Harbert [mailto:dough@voyanttech.com]

> Sent: Wednesday, September 27, 2000 12:50 PM

> To: Simon Barber

> Cc: Jonathan Rosenberg; Taylor, Tom-PT [NORSE:B901:EXCH];
'sip'

> Subject: Re: [SIP] Re-direct of Media During Ringing

>

[PTT] snip

>

> 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

>

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

>

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

>

> Doug Harbert

>

>

>

>

Tom:

    Yes, rather than issuing a re-INVITE before the
final response (200) has been received, it seems to me that we should

CANCEL the initial INVITE, and issue a new INVITE to start a new session.
However, once the session has been established,

re-INVITE is a perfectly appropriate way to change session parameters.

Doug Harbert.

--------------A4175876C0FFEA84F3888B3C--


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


From sip-admin@lists.bell-labs.com  Thu Sep 28 17:44: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 RAA03363
	for ; Thu, 28 Sep 2000 17:44: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 44FDA443CD; Thu, 28 Sep 2000 16:44:11 -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 C271F443A6
	for ; Thu, 28 Sep 2000 16:43:08 -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 RAA13256;
	Thu, 28 Sep 2000 17:42:57 -0400 (EDT)
Received: from njb140bh1.ems.att.com by njb140r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2)
	id RAA18107; Thu, 28 Sep 2000 17:41:35 -0400 (EDT)
Received: by njb140bh1.ems.att.com with Internet Mail Service (5.5.2652.35)
	id ; Thu, 28 Sep 2000 17:42:56 -0400
Message-ID: 
From: "Roy, Radhika R, ALCOO" 
To: Billy Biggs 
Cc: 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: Thu, 28 Sep 2000 17:42:52 -0400

Hi, Billy:

I guess that we agreeing on the fundamental points.

What is the difference then?

SIP is basically transport independent (e.g., it is not tied to any
transport - it can run on IP, it can also run on ATM).

No layer is basically aware about mobility (e.g., CDMA, TDMA, LAN, IP, ATM,
etc.).

To solve some mobility related problems people devise some mechanisms. For
example, mobile IP, cellular IP, wireless ATM, wireless LAN, etc. are the
answers for addressing some kinds of mobility related problems. These are
value-added features. So, no one can mandate what needs to be done in the
value-added features (e.g., "any mobility solution in an IP network MUST NOT
allow the IP address of an active session to change" is NOT applicable).

Hope this will clarify the points.

Best regards,
Radhika R. Roy
AT&T

-----Original Message-----
From: Billy Biggs [mailto:vektor@div8.net]
Sent: Thursday, September 28, 2000 5:11 PM
To: Roy, Radhika R, ALCOO
Cc: farhan; sip
Subject: Re: [SIP] sip mobility with REGISTER


  Radhika,

> However, there is one fundamental point: Change in point of attachment
> in the mobile environment.  [...]   Depending on this "change of
> address," each layer has to take the appropriate action.  If any layer
> is transparent to this change of address, no action is necessary.

  The IP layer has no concept of mobility, and IP addresses are used
casually in upper-layer protocols.  As well, all protocols which run
over IP assume that the IP addresses used do not change mid-session.
So, any mobility solution in an IP network MUST NOT allow the IP address
of an active session to change.

  This means that IP mobility can only be implemented through address
changes in the lower layers, tunnelling through a 3rd party with a fixed
IP address, or informing the routers of new route information for a
specific address.

  Because of this architecture, applications built on IP are guarenteed
that they do not need to worry about mobility, since it is unsupported
by the IP layer they are built on.

  Since SIP is built on IP, by definition no changes need to be made to
SIP to support terminal mobility.

  The mechanisms SIP provides for doing SIP "mobility" are addressing a
different problem: that of user mobility, not endpoint mobility.  While
I agree that you can get away with updating a session endpoint in SIP, I
don't believe this solution should be in any way associated with the
concept of endpoint mobility.

-- 
Billy Biggs, 3Com              Billy_Biggs@3com.com
http://www.div8.net/billy/          vektor@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 Sep 28 18:01: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 SAA03629
	for ; Thu, 28 Sep 2000 18:01: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 4EB45443C4; Thu, 28 Sep 2000 17:01: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 4948F4438C
	for ; Thu, 28 Sep 2000 17:00: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 SAA12796;
	Thu, 28 Sep 2000 18:02:53 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id ; Thu, 28 Sep 2000 17:57:33 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'sip-implementors@cs.columbia.edu'" ,
        "'sip (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] More arbitrary limits
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
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, 28 Sep 2000 17:57:32 -0400

Folks,

It has just come to my attention that the vendor of a shipping SIP based
system has SIP UAs that barf when a message arrives with more than 9 Via
headers.

Again, I cannot emphasize enough how much of a recipe for disaster this is.
The system will work for small to mid size deployments, and then, all of a
sudden, once we are really rolling, completely break in the middle of an
operational deployment.

I suggest we add this to the torture tests at the bakeoffs.

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  Thu Sep 28 19:04: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 TAA04615
	for ; Thu, 28 Sep 2000 19:04: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 71D0F4438C; Thu, 28 Sep 2000 18:04:11 -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 965BA44339
	for ; Thu, 28 Sep 2000 18:03:47 -0400 (EDT)
Received: by div8.net
	via sendmail from stdin
	id  (Debian Smail3.2.0.102)
	for sip@lists.bell-labs.com; Thu, 28 Sep 2000 18:03:41 -0500 (CDT) 
From: Billy Biggs 
To: "Roy, Radhika R, ALCOO" 
Cc: farhan , sip 
Subject: Re: [SIP] sip mobility with REGISTER
Message-ID: <20000928180341.A17024@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, Sep 28, 2000 at 05:42:52PM -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, 28 Sep 2000 18:03:41 -0500

  Radhika,

  I believe that I understand what you are asking, however I think that
it would be easier to discuss if you gave some more specific
requirements about what you are trying to accomplish.

> To solve some mobility related problems people devise some mechanisms.
> For example, mobile IP, cellular IP, wireless ATM, wireless LAN, etc.
> are the answers for addressing some kinds of mobility related
> problems. These are value-added features. So, no one can mandate what
> needs to be done in the value-added features (e.g., "any mobility
> solution in an IP network MUST NOT allow the IP address of an active
> session to change" is NOT applicable).

  Alright, so I'll drop my argument about it being a bad idea to change
IP addresses mid-stream and consider some hypothetical mobility
solution.  This solution seems to involve the endpoint changing its IP
address and then attempting to migrate all active connections over to
its new IP address.

  As I have mentioned before, if an endpoint wants to handoff a session
to another SIP user agent, no extensions to SIP are required.  In fact,
I believe this has already been discussed on the mailing list.  So,
already I think we've got you covered.

  Your original questions in this thread were:

> Do we need any additional standard work in the SIP layer to couple the
> change in the lower address to invoke the REGISTER message?

  Well, since the endpoint is changing its own IP address, it seems that
it would already have enough knowledge to un-REGISTER the old address
and REGISTER again with the new one.  I don't think we need any
additional standards work.

> It appears that the location update (with single register with a
> single or multiple registers with multiple domains) is the basic
> problem to solve (Does this work need to be done in the SIP WG or
> other WGs?).  According, REGISTER and/or INVITE messages may be
> impacted.

  I don't see any changes that need to be made to the REGISTER or INVITE
messages to support switching the addresses involved in a session.

  Also, before you mentioned that:

> SIP is basically transport independent (e.g., it is not tied to any
> transport - it can run on IP, it can also run on ATM).

  This is true, however remember that a SIP URI is defined in terms of
IP addresses, so while tunnelling SIP messages across other networks is
feasible (and remembering this state in Via headers is also feasible),
the endpoints themselves are very much tied to an IP network.

-- 
Billy Biggs, 3Com              Billy_Biggs@3com.com
http://www.div8.net/billy/          vektor@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 Sep 28 19:57: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 TAA05532
	for ; Thu, 28 Sep 2000 19:57: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 861F74438C; Thu, 28 Sep 2000 18:57:11 -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 E28AE44339
	for ; Thu, 28 Sep 2000 18:56:55 -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 RAA09823;
	Thu, 28 Sep 2000 17:54:42 -0600 (MDT)
Message-ID: <39D3DB7F.F13FD1C1@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 ,
        "'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: Thu, 28 Sep 2000 17:59:59 -0600
Content-Transfer-Encoding: 7bit

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


From sip-admin@lists.bell-labs.com  Thu Sep 28 20: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 UAA05888
	for ; Thu, 28 Sep 2000 20:22: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 177EA4438C; Thu, 28 Sep 2000 19:22:12 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from ertpg15e1.nortelnetworks.com (ertpg15e1.nortelnetworks.com [47.234.0.36])
	by lists.bell-labs.com (Postfix) with ESMTP id 5B5B744339
	for ; Thu, 28 Sep 2000 19:21:50 -0400 (EDT)
Received: from smtprch1.nortel.com (erchg0j [47.113.64.103])
	by ertpg15e1.nortelnetworks.com (8.11.0/8.11.0) with ESMTP id e8T0JlT11200
	for ; Thu, 28 Sep 2000 20:19:47 -0400 (EDT)
Received: from zrchb200.us.nortel.com (actually zrchb200) 
          by smtprch1.nortel.com; Thu, 28 Sep 2000 19:19:19 -0500
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2652.35) 
          id ; Thu, 28 Sep 2000 19:19:17 -0500
Message-ID: <36FA02BD7083D411BC9E0000F8073E43C44E1B@crchy271.us.nortel.com>
From: "Brian Stucker" 
To: "Roy, Radhika R, ALCOO" , Billy Biggs 
Cc: farhan , sip 
Subject: RE: [SIP] sip mobility with REGISTER
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C029AA.E70E5830"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
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, 28 Sep 2000 19:19:16 -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_01C029AA.E70E5830
Content-Type: text/plain;
	charset="iso-8859-1"

Radhika, et. al.

Any robust IP-aware solution for a wireless terminal has to take into
account the underlying transport media being switched during an IP session.
I seriously doubt you will find anyone deploying a service on a wireless
network where the IP address visibly changes outside of the provider's
network every time the terminal hands-off. In other words, the IP stack at
the service provider and on the terminal has to be cognizant of mobility and
make that transparent to higher-order applications through some sort of
NAT/router functionality. It's simply unacceptible to deploy a system where
you have to rewrite all of the major IP application level protocols in order
to support IP layer mobility, or setup a system whereby all of your TCP
streams die whenever you do a handover because your IP changed.

As long as the mobility-capable IP endpoint uses the external IP presence
assigned to it by the network (regardless if the underlying IP structure
changes) for REGISTERS and INVITES you should be in good shape, or at the
very least in no worse shape than someone running a SIP stack in a DHCP
environment. The mobile IP network should perform any address translation
needed to map external packets destined for the external IP to the one
currently in use by the device if necessary.

I would also suggest that trying to "engineer" SIP, which by the nature of
it's routing mechanisms alone makes it a "slow propagation" protocol, into
hiding IP mobility problems (which require "instant propagation") is going
to cause whomever tries to implement this a great deal of headache, and
their implementation users a great deal of foul language directed at their
devices.

In order to effectively deal with problems such as packet black-outs on
handover, ping-ponging, handover retries, handbacks, shoe-stringing, etc.
You're going to need to deal with this at a layer lower than SIP. In a
real-world environment you run into all manner of wild scenarios that can
cause trying to deal with intra-session mobility with an inter-session
solution (ie. INVITE, REGISTER) a recipe for disaster due to all sorts of
race conditions that you'd be introducing. It's hard enough to deliver, and
keep up a simple circuit-switched phone call to a mobile phone due to
mobility, and the protocols are designed specifically to handle this. =)

Brian Stucker
Nortel Networks

-----Original Message-----
From: Roy, Radhika R, ALCOO [mailto:rrroy@att.com]
Sent: Thursday, September 28, 2000 4:43 PM
To: Billy Biggs
Cc: farhan; sip
Subject: RE: [SIP] sip mobility with REGISTER


Hi, Billy:

I guess that we agreeing on the fundamental points.

What is the difference then?

SIP is basically transport independent (e.g., it is not tied to any
transport - it can run on IP, it can also run on ATM).

No layer is basically aware about mobility (e.g., CDMA, TDMA, LAN, IP, ATM,
etc.).

To solve some mobility related problems people devise some mechanisms. For
example, mobile IP, cellular IP, wireless ATM, wireless LAN, etc. are the
answers for addressing some kinds of mobility related problems. These are
value-added features. So, no one can mandate what needs to be done in the
value-added features (e.g., "any mobility solution in an IP network MUST NOT
allow the IP address of an active session to change" is NOT applicable).

Hope this will clarify the points.

Best regards,
Radhika R. Roy
AT&T

-----Original Message-----
From: Billy Biggs [mailto:vektor@div8.net]
Sent: Thursday, September 28, 2000 5:11 PM
To: Roy, Radhika R, ALCOO
Cc: farhan; sip
Subject: Re: [SIP] sip mobility with REGISTER


  Radhika,

> However, there is one fundamental point: Change in point of attachment
> in the mobile environment.  [...]   Depending on this "change of
> address," each layer has to take the appropriate action.  If any layer
> is transparent to this change of address, no action is necessary.

  The IP layer has no concept of mobility, and IP addresses are used
casually in upper-layer protocols.  As well, all protocols which run
over IP assume that the IP addresses used do not change mid-session.
So, any mobility solution in an IP network MUST NOT allow the IP address
of an active session to change.

  This means that IP mobility can only be implemented through address
changes in the lower layers, tunnelling through a 3rd party with a fixed
IP address, or informing the routers of new route information for a
specific address.

  Because of this architecture, applications built on IP are guarenteed
that they do not need to worry about mobility, since it is unsupported
by the IP layer they are built on.

  Since SIP is built on IP, by definition no changes need to be made to
SIP to support terminal mobility.

  The mechanisms SIP provides for doing SIP "mobility" are addressing a
different problem: that of user mobility, not endpoint mobility.  While
I agree that you can get away with updating a session endpoint in SIP, I
don't believe this solution should be in any way associated with the
concept of endpoint mobility.

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

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

------_=_NextPart_001_01C029AA.E70E5830
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: [SIP] sip mobility with REGISTER




Radhika, et. al.




Any robust IP-aware solution for a wireless terminal =
has to take into account the underlying transport media being switched =
during an IP session. I seriously doubt you will find anyone deploying =
a service on a wireless network where the IP address visibly changes =
outside of the provider's network every time the terminal hands-off. In =
other words, the IP stack at the service provider and on the terminal =
has to be cognizant of mobility and make that transparent to =
higher-order applications through some sort of NAT/router =
functionality. It's simply unacceptible to deploy a system where you =
have to rewrite all of the major IP application level protocols in =
order to support IP layer mobility, or setup a system whereby all of =
your TCP streams die whenever you do a handover because your IP =
changed.



As long as the mobility-capable IP endpoint uses the =
external IP presence assigned to it by the network (regardless if the =
underlying IP structure changes) for REGISTERS and INVITES you should =
be in good shape, or at the very least in no worse shape than someone =
running a SIP stack in a DHCP environment. The mobile IP network should =
perform any address translation needed to map external packets destined =
for the external IP to the one currently in use by the device if =
necessary.



I would also suggest that trying to =
"engineer" SIP, which by the nature of it's routing =
mechanisms alone makes it a "slow propagation" protocol, into =
hiding IP mobility problems (which require "instant =
propagation") is going to cause whomever tries to implement this a =
great deal of headache, and their implementation users a great deal of =
foul language directed at their devices.



In order to effectively deal with problems such as =
packet black-outs on handover, ping-ponging, handover retries, =
handbacks, shoe-stringing, etc. You're going to need to deal with this =
at a layer lower than SIP. In a real-world environment you run into all =
manner of wild scenarios that can cause trying to deal with =
intra-session mobility with an inter-session solution (ie. INVITE, =
REGISTER) a recipe for disaster due to all sorts of race conditions =
that you'd be introducing. It's hard enough to deliver, and keep up a =
simple circuit-switched phone call to a mobile phone due to mobility, =
and the protocols are designed specifically to handle this. =
=3D)



Brian Stucker

Nortel Networks




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

From: Roy, Radhika R, ALCOO [mailto:rrroy@att.com]

Sent: Thursday, September 28, 2000 4:43 PM

To: Billy Biggs

Cc: farhan; sip

Subject: RE: [SIP] sip mobility with REGISTER






Hi, Billy:




I guess that we agreeing on the fundamental =
points.




What is the difference then?




SIP is basically transport independent (e.g., it is =
not tied to any

transport - it can run on IP, it can also run on =
ATM).




No layer is basically aware about mobility (e.g., =
CDMA, TDMA, LAN, IP, ATM,

etc.).




To solve some mobility related problems people devise =
some mechanisms. For

example, mobile IP, cellular IP, wireless ATM, =
wireless LAN, etc. are the

answers for addressing some kinds of mobility =
related problems. These are

value-added features. So, no one can mandate what =
needs to be done in the

value-added features (e.g., "any mobility =
solution in an IP network MUST NOT

allow the IP address of an active session to =
change" is NOT applicable).




Hope this will clarify the points.




Best regards,

Radhika R. Roy

AT&T




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

From: Billy Biggs [mailto:vektor@div8.net]

Sent: Thursday, September 28, 2000 5:11 PM

To: Roy, Radhika R, ALCOO

Cc: farhan; sip

Subject: Re: [SIP] sip mobility with REGISTER






  Radhika,




> However, there is one fundamental point: Change =
in point of attachment

> in the mobile environment.  =
[...]   Depending on this "change of

> address," each layer has to take the =
appropriate action.  If any layer

> is transparent to this change of address, no =
action is necessary.




  The IP layer has no concept of mobility, and =
IP addresses are used

casually in upper-layer protocols.  As well, =
all protocols which run

over IP assume that the IP addresses used do not =
change mid-session.

So, any mobility solution in an IP network MUST NOT =
allow the IP address

of an active session to change.




  This means that IP mobility can only be =
implemented through address

changes in the lower layers, tunnelling through a =
3rd party with a fixed

IP address, or informing the routers of new route =
information for a

specific address.




  Because of this architecture, applications =
built on IP are guarenteed

that they do not need to worry about mobility, since =
it is unsupported

by the IP layer they are built on.




  Since SIP is built on IP, by definition no =
changes need to be made to

SIP to support terminal mobility.




  The mechanisms SIP provides for doing SIP =
"mobility" are addressing a

different problem: that of user mobility, not =
endpoint mobility.  While

I agree that you can get away with updating a =
session endpoint in SIP, I

don't believe this solution should be in any way =
associated with the

concept of endpoint mobility.




-- 

Billy Biggs, =
3Com           &n=
bsp;  Billy_Biggs@3com.com

http://www.div8.net/billy/    =
      vektor@div8.net




_______________________________________________

SIP mailing list

SIP@lists.bell-labs.com

http://lists.bell-labs.com/mailman/listinfo/sip





------_=_NextPart_001_01C029AA.E70E5830--

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


From sip-admin@lists.bell-labs.com  Fri Sep 29 00:30: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 AAA10908
	for ; Fri, 29 Sep 2000 00:30: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 DF14F4438C; Thu, 28 Sep 2000 23:29:11 -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 4A75744339
	for ; Thu, 28 Sep 2000 23:27:52 -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 e8T4QWC27743;
	Fri, 29 Sep 2000 09:56:43 +0530 (IST)
Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2  (651.2 6-10-1998))  id 65256969.0018BDF3 ; Fri, 29 Sep 2000 10:00:14 +0530
X-Lotus-FromDomain: HSSBLR
From: archow@hss.hns.com
To: Jonathan Rosenberg 
Cc: "'sip-implementors@cs.columbia.edu'" ,
        "'sip (E-mail)'" 
Message-ID: <65256969.0018BC86.00@sampark.hss.hns.com>
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Subject: [SIP] Re: More arbitrary limits
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
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, 29 Sep 2000 10:00:10 +0530



Jonathan,
in principle I agree with you.
However, I would like to know what exactly you connotate by 'barf' - does
it mean the UA crashes, or does it mean it
gracefully declines ?

I have worked with people on the embedded side who simply cannot allocate
more than Xk for SIP messages and
by policy, their application rejects any message greater than this, by
returning a message too long bad response( I think its a 413). While this
may not be desirable, at times it can be a practical limitation.

If the UA crashes, I would say its certainly a no-no. If it declines by
saying 'sorry, I can't handle your message', then its certainly
a scenario that should be still in line. I would say that this approach is
still inter-operable .

Regds
Arjun

--
Arjun Roychowdhury @ Hughes Software Systems






Jonathan Rosenberg  on 09/29/2000 03:27:32 AM

To:   "'sip-implementors@cs.columbia.edu'"
      , "'sip (E-mail)'"
      
cc:

Subject:  More arbitrary limits




Folks,

It has just come to my attention that the vendor of a shipping SIP based
system has SIP UAs that barf when a message arrives with more than 9 Via
headers.

Again, I cannot emphasize enough how much of a recipe for disaster this is.
The system will work for small to mid size deployments, and then, all of a
sudden, once we are really rolling, completely break in the middle of an
operational deployment.

I suggest we add this to the torture tests at the bakeoffs.

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  Fri Sep 29 02: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 CAA24134
	for ; Fri, 29 Sep 2000 02: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 7E57A443E0; Fri, 29 Sep 2000 01:27:11 -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 1CB5444339
	for ; Fri, 29 Sep 2000 01:26:41 -0400 (EDT)
Received: from hotfoon.com ([210.212.215.252])
	by hd2.dot.net.in (8.8.8/8.8.8) with ESMTP id LAA16089;
	Fri, 29 Sep 2000 11:37:51 +0530 (IST)
Message-ID: <39D2E1B8.58A5DFF3@hotfoon.com>
From: farhan 
Organization: Paradigm Computers Pvt. LTD
X-Mailer: Mozilla 4.74 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Billy Biggs 
Cc: "Roy, Radhika R, ALCOO" , sip 
Subject: Re: [SIP] sip mobility with REGISTER
References:  <20000928141735.A16632@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: Thu, 28 Sep 2000 11:44:16 +0530
Content-Transfer-Encoding: 7bit



Billy Biggs wrote: 
>   I think you are confused as to the general purpose of a REGISTER
> message.  A REGISTER is intended to be used to inform the proxy of a new
> point of contact for a user, not a new location for an active point of
> contact.

we dont 'intend' things in a protocol. we just use them. a protocol
specifies how two entities will interact in a predictible manner. it
does not and should not enter into the realm of why they want to do
that. if that were the case, you are essentially arguing against
innovative application of existing protocols. for instance, the purpose
of http is to transfer documents and not read email - hotmail is out.
the purpose of UDP is not real time communication but unreliable
delivery- rtp is out.

> Even to do the hacked solution of REGISTER'ing under the new
> address and attempting to re-INVITE any active sessions, you don't need
> to add any new modifications to SIP.
> 

i dont forsee reinvites or re-registers due to mobile ip issues. mobile
ip should gaurenttee seamless and continuous coverage. it is completely
an issue of the network (or maybe even a lower layer - like in
bluetooth).

lets define the issue of mobility. when we are talking within sip
persepective, we are essentially talking of app level mobility. correct
me if i am wrong.

app level mobility means that i should be able to switch between varying
apps. from my desktop UA to my cell phone to my answering machine at
voicemail.com seamlessly and on a single id. something that is being
promised by likes of hotsip. the mobility is NOT in terms of physical
space but application layer. for that end, REGISTER is perfect. With
remarkable clarity and insight, REGISTER talks about third party
registerations, multiple registerations and forking locators. All of
them fully and completely cover mobility.

- farhan

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


From sip-admin@lists.bell-labs.com  Fri Sep 29 04:37: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 EAA25131
	for ; Fri, 29 Sep 2000 04:37: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 3DB09443D1; Fri, 29 Sep 2000 03:37:11 -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 F2448443A0
	for ; Fri, 29 Sep 2000 03:36: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; 29 Sep 2000 08:36:29 UT
Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef)
	id JAA23622; Fri, 29 Sep 2000 09:34:18 +0100 (BST)
From: "Jo Hornsby" 
To: "Dvir Oren" , "SIP" 
Subject: RE: [SIP] received param
Message-ID: <003601c029f0$0e7878c0$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: <14803.34874.915381.402119@jodie.lucid>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
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: Fri, 29 Sep 2000 09:34:17 +0100
Content-Transfer-Encoding: 7bit

> I ran into a problem with my SIP implementation when a UAS returned a
> reply to a Proxy with a receiver-tagged Via.  The Proxy then wanted to 
> check whether this reply is for itself, or to be proxied.  It first
> looked at the first Via to see if it's its own Via.  It found the
> receiver-tagged Via, and tried to compare it with what it knows about
> itself.
> 
> What I did at this point is compare the IP addresses.  Unfortunately,
> the DNS had only one of the IP addresses of the Proxy, while the UAS
> saw the request coming from a different IP.  So, the Via's did not
> match.

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 did some hack which ignores the recieved tag.  I personally don't
> like it.

Via-received was intended (whether it really works is another matter)
to work around NATs, thus it doesn't seem unreasonable that a client
should ignore it (if the client knew what IP it would appear as to the
server, why didn't it just put that IP in the Via from the beginning?).

> Any other solutions?

Yes -- use the branch parameter.


 - 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 Sep 29 05:05: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 FAA25390
	for ; Fri, 29 Sep 2000 05:05: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 7FBAF443D1; Fri, 29 Sep 2000 04:05:12 -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 413FD443A0
	for ; Fri, 29 Sep 2000 04:04:22 -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; 29 Sep 2000 09:04:41 UT
Received: from gethin by ubiquity.net with SMTP (8.8.8+Sun/25-eef)
	id KAA06988; Fri, 29 Sep 2000 10:02:34 +0100 (BST)
From: Gethin Liddell 
Organization: Ubiquity Software Corp.
To: Dvir Oren , SIP 
Subject: Re: [SIP] received param
X-Mailer: KMail [version 1.0.29.2]
Content-Type: text/plain
References: <14803.34874.915381.402119@jodie.lucid>
In-Reply-To: <14803.34874.915381.402119@jodie.lucid>
MIME-Version: 1.0
Message-Id: <00092910073201.17537@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: Fri, 29 Sep 2000 09:57:19 +0100
Content-Transfer-Encoding: 8bit

On Thu, 28 Sep 2000, Dvir Oren wrote:
> I ran into a problem with my SIP implementation when a UAS returned a
> reply to a Proxy with a receiver-tagged Via.  The Proxy then wanted to 
> check whether this reply is for itself, or to be proxied.  It first
> looked at the first Via to see if it's its own Via.  It found the
> receiver-tagged Via, and tried to compare it with what it knows about
> itself.

I don't think that you should be making this comparison at all.

Section 2.1, although specifically talks about sip url, does say that
when comparing parameters:

"If a com-ponent is omitted, it matches based on its default value.
(For example, otherwise equivalent URLs without a port specification
and with port 5060 match.) Components not found in both URLs being
compared are ignored."

applying this ethos to headers, then as your via does not contain a
received parameter, you should not be making this comparison.  Just
compare on the sent-protocol, sent-by and any parameters you add (such
as branch)

HTH

-- 
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  Fri Sep 29 09:13: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 JAA28992
	for ; Fri, 29 Sep 2000 09:13: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 B0959443A0; Fri, 29 Sep 2000 08:13:11 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from smtp6.mindspring.com (smtp6.mindspring.com [207.69.200.110])
	by lists.bell-labs.com (Postfix) with ESMTP id D983444339
	for ; Fri, 29 Sep 2000 08:12:17 -0400 (EDT)
Received: from gamma (user-1054j4b.biz.mindspring.com [64.82.76.139])
	by smtp6.mindspring.com (8.9.3/8.8.5) with SMTP id JAA01704
	for ; Fri, 29 Sep 2000 09:12:13 -0400 (EDT)
Reply-To: 
From: "Raja Sekhar" 
To: 
Subject: RE: [SIP] received param
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: <14803.34874.915381.402119@jodie.lucid>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
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, 29 Sep 2000 09:09:21 -0400
Content-Transfer-Encoding: 7bit

hi Dvir Oren
 This is the raj here . I have few questions about it . Weather your
register message via tag has  considering the local proxy or IP address of u
r system .
There should be a matching of IP address on the proxy accordingly DNS lookup
takes place . So please clear  your register message Via tag entry

thanq
rajasekhar-voicecore



-----Original Message-----
From: sip-admin@lists.bell-labs.com
[mailto:sip-admin@lists.bell-labs.com]On Behalf Of Dvir Oren
Sent: Thursday, September 28, 2000 2:10 PM
To: SIP
Subject: [SIP] received param


I ran into a problem with my SIP implementation when a UAS returned a
reply to a Proxy with a receiver-tagged Via.  The Proxy then wanted to
check whether this reply is for itself, or to be proxied.  It first
looked at the first Via to see if it's its own Via.  It found the
receiver-tagged Via, and tried to compare it with what it knows about
itself.

What I did at this point is compare the IP addresses.  Unfortunately,
the DNS had only one of the IP addresses of the Proxy, while the UAS
saw the request coming from a different IP.  So, the Via's did not
match.

I did some hack which ignores the recieved tag.  I personally don't
like it.

Any other solutions?

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


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


From sip-admin@lists.bell-labs.com  Fri Sep 29 09:45: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 JAA29723
	for ; Fri, 29 Sep 2000 09:45: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 B0A464438C; Fri, 29 Sep 2000 08:45:13 -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 44854443A0
	for ; Fri, 29 Sep 2000 04:36:25 -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; 29 Sep 2000 09:36:44 UT
Received: from phoffer by ubiquity.net with SMTP (8.8.8+Sun/25-eef)
	id KAA22885; Fri, 29 Sep 2000 10:34:40 +0100 (BST)
Message-ID: <002001c029f8$7ce87050$5334c3c1@ubiquity.co.uk>
From: "Phil Hoffer" 
To: "Michael Thomas" 
Cc: "Jonathan Rosenberg" , ,
        "Henning Schulzrinne" 
References: <002701c02862$5eb0e050$5334c3c1@ubiquity.co.uk><39D211A6.7805F15E@cs.columbia.edu> <14802.5141.143274.484448@thomasm-u1.cisco.com>
Subject: Re: [SIP] The Null authentication scheme
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, 29 Sep 2000 10:34:38 +0100
Content-Transfer-Encoding: 7bit

> There seems to be a lot of conflation of
> algorithms and users going on here.
>
> I still don't understand why this is more desirable
> than having a BCP which says that if you want to
> authenticate as an anonymous user, use Basic with
> guest/anonymous/null/whatever and no password.
>
> This works for ftp, there doesn't seem to be a
> burning need in http; why is SIP different in this
> regard?

Well the difference is that with http is that if authentication is enabled
you either have access or you don't.
What is being proposed is a mechanism which says I know I don't have access
to this service/resource, but can you help me out here with a lesser
service/resource.

This mechanism does seem more straightforward, and presents no security risk
as the anonymous nature of the username and password is not compromised by
the Basic authentication scheme.

My earlier concerns about the mandatory requirement of strongest
authentication scheme selection still stands.
That said I'm sure that this can be documented.

HTH
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 Sep 29 09:46: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 JAA29809
	for ; Fri, 29 Sep 2000 09:46: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 A24E3443FC; Fri, 29 Sep 2000 08:45:34 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from fgwmail7.fujitsu.co.jp (fgwmail7.fujitsu.co.jp [192.51.44.37])
	by lists.bell-labs.com (Postfix) with ESMTP id E6B1344339
	for ; Fri, 29 Sep 2000 07:06:15 -0400 (EDT)
Received: from m5.gw.fujitsu.co.jp by fgwmail7.fujitsu.co.jp (8.9.3/3.7W-MX0006-Fujitsu Gateway)
	id VAA22220 for ; Fri, 29 Sep 2000 21:06:11 +0900 (JST)
	(envelope-from yuhara@atom.flab.fujitsu.co.jp)
Received: from flabmail.flab.fujitsu.co.jp by m5.gw.fujitsu.co.jp (8.9.3/3.7W-0008-Fujitsu Domain Master)
	id VAA15787; Fri, 29 Sep 2000 21:06:10 +0900 (JST)
Received: from silver by flabmail.flab.fujitsu.co.jp (8.9.3/3.7W-000330-Fujitsu Labs. Domain Mail Master)
	id VAA18358; Fri, 29 Sep 2000 21:06:05 +0900 (JST)
Received: from localhost (localhost [127.0.0.1])
	by silver (8.8.7/3.6Wbeta7-98082009) with ESMTP id VAA15874
	for ; Fri, 29 Sep 2000 21:04:02 +0900 (JST)
To: sip@lists.bell-labs.com
From: Masanobu Yuhara 
X-Mailer: Mew version 1.94b28 on Emacs 19.28 / Mule 2.3 (SUETSUMUHANA)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20000929210402G.yuhara@atom.flab.fujitsu.co.jp>
X-Dispatcher: imput version 990425(IM115)
Lines: 16
Subject: [SIP] ABNF in 2543bis-01
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
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, 29 Sep 2000 21:04:02 +0900
Content-Transfer-Encoding: 7bit

Regarding draft-ietf-sip-rfc2543bis-01,

(1)  should be listed in  ABNF.

(2) There seems to be no ABNF for  used in .

(3) '=' is missing in  (Section 6.30)

------
Masanobu Yuhara		yuhara@flab.fujitsu.co.jp
Fujitsu Laboratories Ltd.






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


From sip-admin@lists.bell-labs.com  Fri Sep 29 10:07: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 KAA00241
	for ; Fri, 29 Sep 2000 10:07: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 345F94438C; Fri, 29 Sep 2000 09:07:11 -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 1F98D44339
	for ; Fri, 29 Sep 2000 09:06: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; 29 Sep 2000 14:06:23 UT
Received: from gethin by ubiquity.net with SMTP (8.8.8+Sun/25-eef)
	id PAA05790; Fri, 29 Sep 2000 15:04:15 +0100 (BST)
From: Gethin Liddell 
Organization: Ubiquity Software Corp.
To: Masanobu Yuhara , sip@lists.bell-labs.com
Subject: Re: [SIP] ABNF in 2543bis-01
X-Mailer: KMail [version 1.0.29.2]
Content-Type: text/plain
References: <20000929210402G.yuhara@atom.flab.fujitsu.co.jp>
In-Reply-To: <20000929210402G.yuhara@atom.flab.fujitsu.co.jp>
MIME-Version: 1.0
Message-Id: <00092915065100.25992@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: Fri, 29 Sep 2000 15:04:53 +0100
Content-Transfer-Encoding: 8bit

You are reading an old bis.  bis-02 is the latest available from
Hennings site: http://www.cs.columbia.edu/~hgs/sip/	

On Fri, 29 Sep 2000, Masanobu Yuhara wrote:
> Regarding draft-ietf-sip-rfc2543bis-01,
> 
> (1)  should be listed in  ABNF.
> 
> (2) There seems to be no ABNF for  used in .
> 
> (3) '=' is missing in  (Section 6.30)
> 
> ------
> Masanobu Yuhara		yuhara@flab.fujitsu.co.jp
> Fujitsu Laboratories Ltd.
> 
> 
> 
> 
> 
> 
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip
-- 
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  Fri Sep 29 10:24: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 KAA00509
	for ; Fri, 29 Sep 2000 10:24: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 2E23B4438C; Fri, 29 Sep 2000 09:24:12 -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 4BAFD44339
	for ; Fri, 29 Sep 2000 09:23:00 -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 KAA12475; Fri, 29 Sep 2000 10:22:43 -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 ABL38817;
	Fri, 29 Sep 2000 10:22:42 -0400 (EDT)
Message-Id: <4.3.2.7.2.20000929102353.00b159c0@cia.cisco.com>
X-Sender: mhammer@cia.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
To: Doug Harbert , Simon Barber 
From: hammer michael 
Subject: Re: [SIP] Re-direct of Media During Ringing
Cc: Jonathan Rosenberg ,
        "'Tom-PT Taylor'" ,
        "'sip'" 
In-Reply-To: <39D3DB7F.F13FD1C1@voyanttech.com>
References: 
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, 29 Sep 2000 10:27:20 -0700

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  Fri Sep 29 10:53: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 KAA00956
	for ; Fri, 29 Sep 2000 10:53: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 09FFC44409; Fri, 29 Sep 2000 09:53:12 -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 A387744401
	for ; Fri, 29 Sep 2000 09:52:07 -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 KAA13082; Fri, 29 Sep 2000 10:52:02 -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 ABL39235;
	Fri, 29 Sep 2000 10:52:00 -0400 (EDT)
Message-Id: <4.3.2.7.2.20000929104630.00b1a9e0@cia.cisco.com>
X-Sender: mhammer@cia.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
To: "Roy, Radhika R, ALCOO" , Michael Thomas ,
        Henry Sinnreich 
From: hammer michael 
Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP
  Mobility )
Cc: Lewis Karl-QA3387 ,
        "'Henning Schulzrinne'" ,
        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: Fri, 29 Sep 2000 10:56:39 -0700

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


From sip-admin@lists.bell-labs.com  Fri Sep 29 11:33: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 LAA01396
	for ; Fri, 29 Sep 2000 11:33: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 1CF5344401; Fri, 29 Sep 2000 10:33:13 -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 1068A44339
	for ; Fri, 29 Sep 2000 10:32: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; 29 Sep 2000 15:32:22 UT
Received: from gethin by ubiquity.net with SMTP (8.8.8+Sun/25-eef)
	id QAA10171; Fri, 29 Sep 2000 16:30:15 +0100 (BST)
From: Gethin Liddell 
Organization: Ubiquity Software Corp.
To: Grard GONNET , 
Subject: Re: [SIP] rfc 2543bis-01 SIP syntax
X-Mailer: KMail [version 1.0.29.2]
Content-Type: text/plain
Cc: , "SEVESTRE Thibaut" 
References: <002201c026c1$81374300$5a040237@it.atosgroup.com>
In-Reply-To: <002201c026c1$81374300$5a040237@it.atosgroup.com>
MIME-Version: 1.0
Message-Id: <00092916325201.26245@gethin>
X-MIME-Autoconverted: from 8bit to quoted-printable by ubiquity.net id QAA10171
X-Eagle-Notice: Sender not 8-bit clean in 'To: G\351rard GONNET , '
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
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, 29 Sep 2000 16:07:53 +0100
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA01396

On Mon, 25 Sep 2000, Gérard GONNET wrote:
> 
> rfc 2543bis-01 SIP syntax revisited
> 
> Some definitions of the SIP syntax can introduce undesirable side effects. For exemple :
> 
> the user element is defined as *(unreserved | escaped | "&"| "=" | "+" | "$" | "," | ";" | "?" | "/" ) .
> The application of the * operator tell us that a user element is represented as a succession of 0 (the default value) or more chars belonging to the enumerated set.
> Giving a 0 value to the low limit of the repetition factor results in an "empty" user element, which is an authorized syntax.
> This can introduce some trouble :
> 1/ what is the meaning of an "empty" user ?

what ever you want it to mean.

> 2/ because the given syntax is equivalent to [user] (cf. C part of the draft, page 116), how to ensure the definition of a mandatory user ?

why define a mandatory user?  i do not see why "sip:@example.com" should
be considiered illegal.  perhaps this may mean something to some
server, its all implementation specific.

> 
> The same remark applies to the password element, defined as
> password =  *(unreserved |escaped | "&" | "=" | "+" | "$" | ","), because the notation [":" password] of the user-info element is significant enough to declare password as an optional child element. Furthermore, this syntax could reduce the [":" password] to a lone ":" char only when used with an "empty" password.

again there is no reason to make "sip:person:@example.com" illegal.  if
the password does not match then return an unautherized.

> The same remark applies to the url-parameters element . This mandatory child element of the SIP-URL element can be emptied by the given definition :
> url-parameters = * (";" url-parameter).

mandatory?  there is nothing wrong with a sip url as
"sip:person@example.com" or even "sip:example.com" and there are no
parameters present.  which parameters do you think are mandatory?

> The same remark applies to the hvalue element defined as :
> hvalue = *(hnv-unreserved | unrerserved | escaped) .
> Using this definition in the header element 
> header = hname "=" hvalue
> can reduce the header to a  hname "="  not terminated form. (notice that the hname left element is declared as hname = 1*(hnv-unreserved | unrerserved | escaped) ...

yes, this should probably be:

header = hname [ "=" hvalue ]
where hvalue is defined the same as hname

also please ensure you have the most up to date bis draft - bis02 from
hennings site:

http://www.cs.columbia.edu/~hgs/sip/

> A remark about the escaped element, declared as :
> escaped = "%" hex hex
> I cannot find a definition for hex in the ABNF specification. I suppose that a typographic error has occured and hex has to be translated into HEX, which is well defined and seems to be the right element ?

yep

-- 
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  Fri Sep 29 11:34:57 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA01442
	for ; Fri, 29 Sep 2000 11:34: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 B396E44412; Fri, 29 Sep 2000 10:33:33 -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 E68C244339
	for ; Fri, 29 Sep 2000 10:32:29 -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 LAA17345;
	Fri, 29 Sep 2000 11:34:21 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id ; Fri, 29 Sep 2000 11:29:00 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'archow@hss.hns.com'" ,
        Jonathan Rosenberg 
Cc: "'sip-implementors@cs.columbia.edu'" ,
        "'sip (E-mail)'" 
Subject: RE: [SIP] Re: More arbitrary limits
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, 29 Sep 2000 11:28:59 -0400




> -----Original Message-----
> From: archow@hss.hns.com [mailto:archow@hss.hns.com]
> Sent: Friday, September 29, 2000 12:30 AM
> To: Jonathan Rosenberg
> Cc: 'sip-implementors@cs.columbia.edu'; 'sip (E-mail)'
> Subject: [SIP] Re: More arbitrary limits
> 
> 
> 
> 
> Jonathan,
> in principle I agree with you.
> However, I would like to know what exactly you connotate by 
> 'barf' - does
> it mean the UA crashes, or does it mean it
> gracefully declines ?

Not sure. Either way the call is not established.

> 
> I have worked with people on the embedded side who simply 
> cannot allocate
> more than Xk for SIP messages and
> by policy, their application rejects any message greater than this, by
> returning a message too long bad response( I think its a 
> 413). While this
> may not be desirable, at times it can be a practical limitation.

Well, I would encourage them to set X to at least 2 or 3 for now. SIP
messages are getting bigger all the time.

In any case, that is different from the arbitrary limit imposed on a
particular header. In this case, requests were being rejected (or causing
the system to crash or something) even though the total length was within
reasonable bounds.


> 
> If the UA crashes, I would say its certainly a no-no. If it 
> declines by
> saying 'sorry, I can't handle your message', then its certainly
> a scenario that should be still in line. I would say that 
> this approach is
> still inter-operable .

Not really. Interoperability means that communications is successfully set
up. It has not been here.

-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 Sep 29 12: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 MAA01911
	for ; Fri, 29 Sep 2000 12: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 7EB604438C; Fri, 29 Sep 2000 11:01: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 ECD2944339
	for ; Fri, 29 Sep 2000 11:00: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 MAA18026;
	Fri, 29 Sep 2000 12:01:49 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id ; Fri, 29 Sep 2000 11:56:28 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'Gethin Liddell'" ,
        "'Dvir Oren'" , "'SIP'" 
Subject: RE: [SIP] received param
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, 29 Sep 2000 11:56:27 -0400


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

-Jonathan R.

> -----Original Message-----
> From: Gethin Liddell [mailto:gethin@ubiquity.net]
> Sent: Friday, September 29, 2000 4:57 AM
> To: Dvir Oren; SIP
> Subject: Re: [SIP] received param
> 
> 
> On Thu, 28 Sep 2000, Dvir Oren wrote:
> > I ran into a problem with my SIP implementation when a UAS 
> returned a
> > reply to a Proxy with a receiver-tagged Via.  The Proxy 
> then wanted to 
> > check whether this reply is for itself, or to be proxied.  It first
> > looked at the first Via to see if it's its own Via.  It found the
> > receiver-tagged Via, and tried to compare it with what it 
> knows about
> > itself.
> 
> I don't think that you should be making this comparison at all.
> 
> Section 2.1, although specifically talks about sip url, does say that
> when comparing parameters:
> 
> "If a com-ponent is omitted, it matches based on its default value.
> (For example, otherwise equivalent URLs without a port specification
> and with port 5060 match.) Components not found in both URLs being
> compared are ignored."
> 
> applying this ethos to headers, then as your via does not contain a
> received parameter, you should not be making this comparison.  Just
> compare on the sent-protocol, sent-by and any parameters you add (such
> as branch)
> 
> HTH
> 
> -- 
> 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
> 

---
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 Sep 29 12: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 MAA01949
	for ; Fri, 29 Sep 2000 12:05: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 03F0C44413; Fri, 29 Sep 2000 11:05:11 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from chupacabras.flash.net (chupacabras.flash.net [209.30.2.16])
	by lists.bell-labs.com (Postfix) with ESMTP id 0C5FE44339
	for ; Fri, 29 Sep 2000 11:04:37 -0400 (EDT)
Received: from mckinley (209-30-194-209.flash.net [209.30.194.209])
	by chupacabras.flash.net (8.9.3/Pro-8.9.3) with ESMTP id LAA27189;
	Fri, 29 Sep 2000 11:04:32 -0500 (CDT)
Reply-To: 
From: "Gary Cote" 
To: "'farhan'" , "'sip'" 
Subject: RE: [SIP] distributed sip
Message-ID: <8F7ED3E5E583D311BA5F0050DA261DB01ACCEF@pikespeak>
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: <8F7ED3E5E583D311BA5F0050DA261DB03C62A6@pikespeak>
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
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, 29 Sep 2000 11:06:43 -0500
Content-Transfer-Encoding: 7bit

So you're basically running a proprietary call control protocol
between the SIP server and your endpoints? You're not asking about
the relative merits of such architecture (you clearly have your reasons),
you're simply enquiring out interoperability? Is that right?

I can imagine such a setup for a SIP-enabled wireless network, or
possibly for java-based clients: an architecture optimized for thin
clients and control protocols.

Anyway, in terms of pure protocol interoperability, I would imagine 
your solution will be interoperable to the degree that your SIP 
server is SIP-compliant. That's pretty straightforward.

Feature interoperability, however, will depend on how feature-rich
your proprietary protocol is. For example, what if somebody tries to
initiate a multicast session, change media encoding schemes mid-call, 
or perform some other mid-call signaling? These are all perfectly
legitimate operations for a SIP session. Will you be able to perform
the logical equivalents through your proprietary control protocol? 

My two cents,

 - Gary



> -----Original Message-----
> From: sip-admin@lists.bell-labs.com
> [mailto:sip-admin@lists.bell-labs.com]On Behalf Of farhan
> Sent: Thursday, September 28, 2000 1: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 am placing this architecture for review because of my 
> interest in getting
> sip into smaller stacks. With an approach wherein, we locate 
> the sip stack
> on a central host and attach the communication end points as slaves of
> host, we retain all the goods of sip while at the same time 
> we will be able
> to afford far simpler and leaner clients. All we need to 
> ensure is that the
> end points are in themselves capable of handling RTP.
> 
> our hotfoon.com deployment is on similar lines. i can well 
> imagine this as a
> route to interoperability with other protocols too.
> we can consider the communication endpoints to be some sort of "remote
> device drivers" of the sip stack that communicate with sip 
> stack using some
> very simple protocol (just two calls: setup and clear down). 
> Our hotfoon
> client is just a 48kb slave totally controlled by 
> hotfoon.com. As a result.,
> we never upgrade our client, we only upgrade the server at 
> hotfoon.com.
> 
> i am considering using this approach on our hotfoon 
> deployment. will there
> be any issues of interoperability?
> 
> - farhan
> 
> 
> 
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> 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 Sep 29 12:16: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 MAA02100
	for ; Fri, 29 Sep 2000 12: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 CA4A54441A; Fri, 29 Sep 2000 11:16:11 -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 38F3E44410
	for ; Fri, 29 Sep 2000 11:15:08 -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; 29 Sep 2000 16:15:27 UT
Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef)
	id RAA28228; Fri, 29 Sep 2000 17:13:25 +0100 (BST)
From: "Jo Hornsby" 
To: 
Subject: RE: [SIP] question on receiving multiple invites
Message-ID: <000401c02a30$3260dee0$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
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
In-Reply-To: <000401c026b3$96993b80$38c9a8c0@labs>
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: Fri, 29 Sep 2000 17:13:25 +0100
Content-Transfer-Encoding: 7bit

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


From sip-admin@lists.bell-labs.com  Fri Sep 29 12:30: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 MAA02428
	for ; Fri, 29 Sep 2000 12:30: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 0F1AC44419; Fri, 29 Sep 2000 11:30:12 -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 53E7244414
	for ; Fri, 29 Sep 2000 11:29: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; 29 Sep 2000 16:30:02 UT
Received: from gethin by ubiquity.net with SMTP (8.8.8+Sun/25-eef)
	id RAA02136; Fri, 29 Sep 2000 17:27:48 +0100 (BST)
From: Gethin Liddell 
Organization: Ubiquity Software Corp.
To: Jonathan Rosenberg ,
        "'Dvir Oren'" , "'SIP'" 
Subject: RE: [SIP] received param
X-Mailer: KMail [version 1.0.29.2]
Content-Type: text/plain
References: 
In-Reply-To: 
MIME-Version: 1.0
Message-Id: <00092917302500.26665@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: Fri, 29 Sep 2000 17:27:29 +0100
Content-Transfer-Encoding: 8bit

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?

-- 
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  Fri Sep 29 12:39: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 MAA02670
	for ; Fri, 29 Sep 2000 12:39: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 27F3844402; Fri, 29 Sep 2000 11:39:12 -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 CB05E44339
	for ; Fri, 29 Sep 2000 11:38:52 -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 MAA25674;
	Fri, 29 Sep 2000 12:38:48 -0400 (EDT)
Received: from njb140bh2.ems.att.com by njb140r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2)
	id MAA27444; Fri, 29 Sep 2000 12:37:26 -0400 (EDT)
Received: by njb140bh2.ems.att.com with Internet Mail Service (5.5.2652.35)
	id ; Fri, 29 Sep 2000 12:38:48 -0400
Message-ID: 
From: "Roy, Radhika R, ALCOO" 
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
	 )
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: Fri, 29 Sep 2000 12:38:45 -0400

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


From sip-admin@lists.bell-labs.com  Fri Sep 29 13: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 NAA03573
	for ; Fri, 29 Sep 2000 13:22: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 C363E443FE; Fri, 29 Sep 2000 12:22:12 -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 1E8BD44339
	for ; Fri, 29 Sep 2000 12:21:31 -0400 (EDT)
Received: from zrchb200.us.nortel.com (actually zrchb200) 
          by smtprch1.nortel.com; Fri, 29 Sep 2000 12:19:15 -0500
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2652.35) 
          id ; Fri, 29 Sep 2000 12:19:08 -0500
Message-ID: <36FA02BD7083D411BC9E0000F8073E43C4522E@crchy271.us.nortel.com>
From: "Brian Stucker" 
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.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C02A39.5D6CAE80"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
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, 29 Sep 2000 12:19:03 -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_01C02A39.5D6CAE80
Content-Type: text/plain;
	charset="iso-8859-1"

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

------_=_NextPart_001_01C02A39.5D6CAE80
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






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?

> > >

> > =
>           &n=
bsp;        Mike

> > >

> > >  >

> > >  > Henry

> > >  >

> > >  > >-----Original =
Message-----

> > >  > >From: =
sip-admin@lists.bell-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]

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

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





------_=_NextPart_001_01C02A39.5D6CAE80--

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


From sip-admin@lists.bell-labs.com  Fri Sep 29 13:52: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 NAA04102
	for ; Fri, 29 Sep 2000 13:52: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 A912044427; Fri, 29 Sep 2000 12:52:11 -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 730B444424
	for ; Fri, 29 Sep 2000 12:51:19 -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 NAA22239;
	Fri, 29 Sep 2000 13:51:16 -0400 (EDT)
Received: from njb140bh1.ems.att.com by njb140r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2)
	id NAA02919; Fri, 29 Sep 2000 13:49:53 -0400 (EDT)
Received: by njb140bh1.ems.att.com with Internet Mail Service (5.5.2652.35)
	id ; Fri, 29 Sep 2000 13:51:15 -0400
Message-ID: 
From: "Roy, Radhika R, ALCOO" 
To: 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: Fri, 29 Sep 2000 13:51:12 -0400

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


From sip-admin@lists.bell-labs.com  Fri Sep 29 14:21: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 OAA04810
	for ; Fri, 29 Sep 2000 14: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 C8FD944424; Fri, 29 Sep 2000 13:21:10 -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 8A2DA44339
	for ; Fri, 29 Sep 2000 13:20: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 OAA19810;
	Fri, 29 Sep 2000 14:22:52 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id ; Fri, 29 Sep 2000 14:17:30 -0400
Message-ID: 
From: Igor Slepchin 
To: "'Dvir Oren'" , SIP 
Subject: RE: [SIP] received param
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, 29 Sep 2000 14:17:29 -0400

I think the proxy should not look at the received parameter when validating
the response or checking for loops in a request. 

What the proxy is looking for is the data it inserted itself (i.e., its own
host, port etc.) whereas the received parameter is added by the next hop.
I'd say that doing DNS lookups on addresses in Via is rather useless since
the proxy should always know what addresses it may insert in the Via in the
first place and then just doing a string match for one of those addresses is
sufficient.

---
Igor Slepchin


> -----Original Message-----
> From: Dvir Oren [mailto:dvir@lucidvon.com]
> Sent: Thursday, September 28, 2000 2:10 PM
> To: SIP
> Subject: [SIP] received param
> 
> 
> I ran into a problem with my SIP implementation when a UAS returned a
> reply to a Proxy with a receiver-tagged Via.  The Proxy then 
> wanted to 
> check whether this reply is for itself, or to be proxied.  It first
> looked at the first Via to see if it's its own Via.  It found the
> receiver-tagged Via, and tried to compare it with what it knows about
> itself.
> 
> What I did at this point is compare the IP addresses.  Unfortunately,
> the DNS had only one of the IP addresses of the Proxy, while the UAS
> saw the request coming from a different IP.  So, the Via's did not
> match.
> 
> I did some hack which ignores the recieved tag.  I personally don't
> like it.
> 
> Any other solutions?
> 
> -- 
> 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
> 

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


From sip-admin@lists.bell-labs.com  Fri Sep 29 14:57: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 OAA05268
	for ; Fri, 29 Sep 2000 14:57: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 70F7C44402; Fri, 29 Sep 2000 13:57:12 -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 056AC44339
	for ; Fri, 29 Sep 2000 13:26:42 -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 LAA07471;
	Fri, 29 Sep 2000 11:27:02 -0700 (PDT)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA05760; Fri, 29 Sep 2000 11:26:37 -0700 (PDT)
From: Michael Thomas 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14804.57053.206665.616135@thomasm-u1.cisco.com>
To: "Phil Hoffer" 
Cc: "Michael Thomas" ,
        "Jonathan Rosenberg" ,
        ,
        "Henning Schulzrinne" 
Subject: Re: [SIP] The Null authentication scheme
In-Reply-To: <002001c029f8$7ce87050$5334c3c1@ubiquity.co.uk>
References: 
	<002701c02862$5eb0e050$5334c3c1@ubiquity.co.uk>
	<39D211A6.7805F15E@cs.columbia.edu>
	<14802.5141.143274.484448@thomasm-u1.cisco.com>
	<002001c029f8$7ce87050$5334c3c1@ubiquity.co.uk>
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, 29 Sep 2000 11:26:37 -0700 (PDT)
Content-Transfer-Encoding: 7bit

Phil Hoffer writes:
 > > There seems to be a lot of conflation of
 > > algorithms and users going on here.
 > >
 > > I still don't understand why this is more desirable
 > > than having a BCP which says that if you want to
 > > authenticate as an anonymous user, use Basic with
 > > guest/anonymous/null/whatever and no password.
 > >
 > > This works for ftp, there doesn't seem to be a
 > > burning need in http; why is SIP different in this
 > > regard?
 > 
 > Well the difference is that with http is that if authentication is enabled
 > you either have access or you don't.

   That's only pertinent for static content.

	       Mike

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


From sip-admin@lists.bell-labs.com  Fri Sep 29 15:04: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 PAA05416
	for ; Fri, 29 Sep 2000 15:04: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 47AAB44431; Fri, 29 Sep 2000 14:04:11 -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 556C244431
	for ; Fri, 29 Sep 2000 14:03:01 -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 PAA08275;
	Fri, 29 Sep 2000 15:02:54 -0400 (EDT)
Received: from njb140bh2.ems.att.com by gab200r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2)
	id PAA00496; Fri, 29 Sep 2000 15:04:54 -0400 (EDT)
Received: by njb140bh2.ems.att.com with Internet Mail Service (5.5.2652.35)
	id ; Fri, 29 Sep 2000 15:02:53 -0400
Message-ID: 
From: "Roy, Radhika R, ALCOO" 
To: farhan , Billy Biggs 
Cc: 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: Fri, 29 Sep 2000 15:02:46 -0400

Hi, Farhan:

I think that you have rightly captured the true essence: Let us keep the
doors open for innovative solutions.

You are right that Re-INVITE and re-REGISTRATION are SIP messages and belong
to the session layer of SIP.

We are using re-INVITE and re-REGISTRAION even in the static environment
even today. We will be using the same thing in mobile environment as well.
It does not change the basic procedures in SIP whether it is mobile or
non-mobile environment.

It is the lower layer that is doing all  mobility related functions. As a
result, a reaction may propagate to the upper layer to cause it to send the
re-INVITE and re-REGISTRAION messages.

So, I guess that we are in agreement.

Best regards,
Radhika R. Roy
AT&T

-----Original Message-----
From: farhan [mailto:farhan@hotfoon.com]
Sent: Thursday, September 28, 2000 2:14 AM
To: Billy Biggs
Cc: Roy, Radhika R, ALCOO; sip
Subject: Re: [SIP] sip mobility with REGISTER




Billy Biggs wrote: 
>   I think you are confused as to the general purpose of a REGISTER
> message.  A REGISTER is intended to be used to inform the proxy of a new
> point of contact for a user, not a new location for an active point of
> contact.

we dont 'intend' things in a protocol. we just use them. a protocol
specifies how two entities will interact in a predictible manner. it
does not and should not enter into the realm of why they want to do
that. if that were the case, you are essentially arguing against
innovative application of existing protocols. for instance, the purpose
of http is to transfer documents and not read email - hotmail is out.
the purpose of UDP is not real time communication but unreliable
delivery- rtp is out.

> Even to do the hacked solution of REGISTER'ing under the new
> address and attempting to re-INVITE any active sessions, you don't need
> to add any new modifications to SIP.
> 

i dont forsee reinvites or re-registers due to mobile ip issues. mobile
ip should gaurenttee seamless and continuous coverage. it is completely
an issue of the network (or maybe even a lower layer - like in
bluetooth).

lets define the issue of mobility. when we are talking within sip
persepective, we are essentially talking of app level mobility. correct
me if i am wrong.

app level mobility means that i should be able to switch between varying
apps. from my desktop UA to my cell phone to my answering machine at
voicemail.com seamlessly and on a single id. something that is being
promised by likes of hotsip. the mobility is NOT in terms of physical
space but application layer. for that end, REGISTER is perfect. With
remarkable clarity and insight, REGISTER talks about third party
registerations, multiple registerations and forking locators. All of
them fully and completely cover mobility.

- farhan

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


From sip-admin@lists.bell-labs.com  Fri Sep 29 15:19: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 PAA05629
	for ; Fri, 29 Sep 2000 15:19: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 7653F44413; Fri, 29 Sep 2000 14:19:11 -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 4A7B944422
	for ; Fri, 29 Sep 2000 14:17:14 -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 PAA29033;
	Fri, 29 Sep 2000 15:16:49 -0400 (EDT)
Received: from njb140bh2.ems.att.com by njb140r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2)
	id PAA23295; Fri, 29 Sep 2000 15:15:22 -0400 (EDT)
Received: by njb140bh2.ems.att.com with Internet Mail Service (5.5.2652.35)
	id ; Fri, 29 Sep 2000 15:16:44 -0400
Message-ID: 
From: "Roy, Radhika R, ALCOO" 
To: "Roy, Radhika R, ALCOO" ,
        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: Fri, 29 Sep 2000 15:16:35 -0400

Hi, Brian:
 
Let me add one more important technical point that has been raised by you:
Race, synchronization, performance, and other problems in the case of
re-INVITE message sent during the mid-session.
 
In general, these are the inherent problems of "continuous (intra-session)"
mobility in all layers: Physical, link, network, and application/session
layer.
 
It is worthwhile to investigate not only for the session layer, but for all
layers together.
 
Some I-Ds are there and people are experimenting in the labs. We like to
hear from them.
 
In the meantime, if you can provide some data on this, it would be much
helpful to see whether more innovative solutions can be found out.
 
Best regards,
Radhika R. Roy
AT&T
 
PS: I have added one word "NOT" in correcting my previous mail.

-----Original Message-----
From: Roy, Radhika R, ALCOO 
Sent: Friday, September 29, 2000 1:51 PM
To: 'Brian Stucker'; sip@lists.bell-labs.com
Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP Mobility )


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 [Roy, Radhika R,
ALARC] "NOT" 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
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


From sip-admin@lists.bell-labs.com  Fri Sep 29 15:39: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 PAA05935
	for ; Fri, 29 Sep 2000 15:39: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 C3D46443B5; Fri, 29 Sep 2000 14:39:11 -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 22AC544430
	for ; Fri, 29 Sep 2000 14:02:14 -0400 (EDT)
Received: from zrchb200.us.nortel.com (actually zrchb200) 
          by smtprch2.nortel.com; Fri, 29 Sep 2000 13:57:35 -0500
Received: from crchy28b.us.nortel.com ([47.100.128.236]) 
          by zrchb200.us.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) 
          id T21XC3NX; Fri, 29 Sep 2000 14:01:28 -0500
Received: from americasm01.nt.com (btexi02f.us.nortel.com [47.104.22.54]) 
          by crchy28b.us.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) 
          id SV1R360H; Fri, 29 Sep 2000 14:01:27 -0500
Message-ID: <39D4E7C4.A199DA50@americasm01.nt.com>
X-Sybari-Space: 00000000 00000000 00000000
From: "Susan Whitaker" 
Organization: Nortel Networks
X-Mailer: Mozilla 4.5 [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
X-Orig: 
Subject: [SIP] Updated SIP REGISTER Payload 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, 29 Sep 2000 14:04:36 -0500
Content-Transfer-Encoding: 7bit

Hello,

    I noticed that the current version of the "Transporting User Control
Information in SIP REGISTER Payloads"
(draft-lennox-sip-reg-payload-00.txt) draft is due to expire this week.
Is anyone maintaining this draft and planning to submit an updated copy
in the near future? I believe this is the only draft which outlines how
to transport payloads in REGISTER messages and is thus required for the
transport of call control scripts such as CPL. If this draft is no
longer being pursued or has been incorporated into another draft, please
let me know. Any information would be appreciated.

Thanks,
Susan


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


From sip-admin@lists.bell-labs.com  Fri Sep 29 16:08: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 QAA06380
	for ; Fri, 29 Sep 2000 16:08: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 B4ACA4438C; Fri, 29 Sep 2000 15:08:11 -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 C806744339
	for ; Fri, 29 Sep 2000 15:07:31 -0400 (EDT)
Received: from conrail.cs.columbia.edu (conrail.cs.columbia.edu [128.59.19.147])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id QAA07745;
	Fri, 29 Sep 2000 16:07:26 -0400 (EDT)
Received: (from lennox@localhost)
	by conrail.cs.columbia.edu (8.9.3/8.9.1) id QAA84800;
	Fri, 29 Sep 2000 16:07:27 -0400 (EDT)
	(envelope-from lennox)
From: Jonathan Lennox 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14804.63102.684911.624490@conrail.cs.columbia.edu>
To: "Susan Whitaker" 
Cc: sip@lists.bell-labs.com
Subject: Re: [SIP] Updated SIP REGISTER Payload Draft?
In-Reply-To: <39D4E7C4.A199DA50@americasm01.nt.com>
References: <39D4E7C4.A199DA50@americasm01.nt.com>
X-Mailer: VM 6.75 under Emacs 19.34.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, 29 Sep 2000 16:07:26 -0400 (EDT)
Content-Transfer-Encoding: 7bit

On Friday, September 29 2000, "Susan Whitaker" wrote to "sip@lists.bell-labs.com" saying:

>     I noticed that the current version of the "Transporting User Control
> Information in SIP REGISTER Payloads"
> (draft-lennox-sip-reg-payload-00.txt) draft is due to expire this week.
> Is anyone maintaining this draft and planning to submit an updated copy
> in the near future? I believe this is the only draft which outlines how
> to transport payloads in REGISTER messages and is thus required for the
> transport of call control scripts such as CPL. If this draft is no
> longer being pursued or has been incorporated into another draft, please
> let me know. Any information would be appreciated.

I plan to submit a new version of this draft within the next few weeks.
The main changes will be to align it better with rfc2543bis, i.e. to use the
"Content-Disposition" header to indicate the type of the uploaded script.

-- 
Jonathan Lennox
lennox@cs.columbia.edu

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


From sip-admin@lists.bell-labs.com  Fri Sep 29 16:58: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 QAA07101
	for ; Fri, 29 Sep 2000 16:58: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 8D6E64433A; Fri, 29 Sep 2000 15:58:12 -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 727C144339
	for ; Fri, 29 Sep 2000 15:57:55 -0400 (EDT)
Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-33 #42261)
 id <0G1O00A0127APO@firewall.mcit.com> for sip@lists.bell-labs.com; Fri,
 29 Sep 2000 20:57:10 +0000 (GMT)
Received: from dgismtp02.wcomnet.com ([166.38.58.142])
 by firewall.mcit.com (PMDF V5.2-33 #42261)
 with ESMTP id <0G1O007J527AXS@firewall.mcit.com>; Fri,
 29 Sep 2000 20:57:10 +0000 (GMT)
Received: from CONVERSION-DAEMON by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263)
 id <0G1O00D01279HN@dgismtp02.wcomnet.com>; Fri,
 29 Sep 2000 20:57:09 +0000 (GMT)
Received: from dgismtp02.wcomnet.com by dgismtp02.wcomnet.com
 (PMDF V5.2-33 #42263) with SMTP id <0G1O00D01277HF@dgismtp02.wcomnet.com>;
 Fri, 29 Sep 2000 20:57:09 +0000 (GMT)
Received: from C25776A ([166.44.58.153])
 by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263)
 with SMTP id <0G1O007NS1UYHJ@dgismtp02.wcomnet.com>; Fri,
 29 Sep 2000 20:56:55 +0000 (GMT)
From: Henry Sinnreich 
Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP Mobility )
In-reply-to: <4.3.2.7.2.20000928150757.00adee90@cia.cisco.com>
To: hammer michael ,
        "Roy, Radhika R, ALCOO" ,
        Michael Thomas 
Cc: Lewis Karl-QA3387 ,
        "'Henning Schulzrinne'" ,
        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: Fri, 29 Sep 2000 15:56:01 +0100
Content-Transfer-Encoding: 7bit

Have struggled with the same, and believe

>user/application and terminal,
>terminal and network end-point,
>network end-point and link end-point, etc.

would be worth an I-D all by itself.

Henry

>-----Original Message-----
>From: hammer michael [mailto:mhammer@cisco.com]
>Sent: Thursday, September 28, 2000 11: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


From sip-admin@lists.bell-labs.com  Fri Sep 29 17:03: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 RAA07162
	for ; Fri, 29 Sep 2000 17:03: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 014EF44392; Fri, 29 Sep 2000 16:01:12 -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 660F74438C
	for ; Fri, 29 Sep 2000 16:00:20 -0400 (EDT)
Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-33 #42260)
 id <0G1O00201281DT@firewall.mcit.com> for sip@lists.bell-labs.com; Fri,
 29 Sep 2000 20:57:37 +0000 (GMT)
Received: from dgismtp02.wcomnet.com ([166.38.58.142])
 by firewall.mcit.com (PMDF V5.2-33 #42260)
 with ESMTP id <0G1O000GB2817M@firewall.mcit.com>; Fri,
 29 Sep 2000 20:57:37 +0000 (GMT)
Received: from CONVERSION-DAEMON by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263)
 id <0G1O00D01281QP@dgismtp02.wcomnet.com>; Fri,
 29 Sep 2000 20:57:37 +0000 (GMT)
Received: from dgismtp02.wcomnet.com by dgismtp02.wcomnet.com
 (PMDF V5.2-33 #42263) with SMTP id <0G1O00D0127YQ7@dgismtp02.wcomnet.com>;
 Fri, 29 Sep 2000 20:57:37 +0000 (GMT)
Received: from C25776A ([166.44.58.153])
 by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263)
 with SMTP id <0G1O007NS1UYHJ@dgismtp02.wcomnet.com>; Fri,
 29 Sep 2000 20:57:23 +0000 (GMT)
From: Henry Sinnreich 
Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP Mobility	)
In-reply-to: <14803.27684.645056.731927@thomasm-u1.cisco.com>
To: Michael Thomas , "Roy, Radhika R, ALCOO" 
Cc: Lewis Karl-QA3387 ,
        "'Henning Schulzrinne'" ,
        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: Fri, 29 Sep 2000 15:56:30 +0100
Content-Transfer-Encoding: 7bit

>   the SIP mobility draft
Where can I find it?

Thanks, Henry

>-----Original Message-----
>From: sip-admin@lists.bell-labs.com
>[mailto:sip-admin@lists.bell-labs.com]On Behalf Of
>Michael Thomas
>Sent: Thursday, September 28, 2000 5:05 PM
>To: Roy, Radhika R, ALCOO
>Cc: Michael Thomas; Henry Sinnreich; Lewis
>Karl-QA3387; 'Henning
>Schulzrinne'; sip@lists.bell-labs.com
>Subject: RE: [SIP] Attempt at summarizing current SIP
>drafts (SIP
>Mobility )
>
>
>Roy, Radhika R, ALCOO writes:
> > 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.
>
>   OK.
>
> > If it is found that SIP does not need to be
>involved, I do not think that
> > anyone will force it to do this.
>
>   Just to be pedantic about my concern: if the
>   reality of the situation is that mobile ip is
>   going to be needed in the vast majority of
>   devices using SIP -- say because they have
>   embedded web browsers -- as a group, IETF
>   would be better served by trying to solve
>   the problem at layer 3 instead of each WG
>   trying to tackle the problem on their own.
>
>   Remember, the context of my concern here was
>   the SIP mobility draft which seems to take
>   application layer continuous mobility as a
>   starting point.
>
> > 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)?
>
>   By discrete mobility, I assume you mean that
>   SIP doesn't repeat the PSTN'ism of assigning
>   a name (phone number) to the physical end of a
>   wire? Ie, that to: mat@cisco.com is divorced
>   from where I happen to be injecting IP packets
>   from? If so, I agree this is a Good Thing, but
>   I'm not sure that there's much if anything to
>   be done beyond that.
>
> > 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.
>
>   Sure. I said up front that I'm willing to believe
>   that real device layer mobility may very well dredge
>   up problems that need to be solved at the SIP layer
>   too.
>
>		Mike
> >
> > 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


From sip-admin@lists.bell-labs.com  Fri Sep 29 17:12: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 RAA07224
	for ; Fri, 29 Sep 2000 17:12: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 076EF443B4; Fri, 29 Sep 2000 16:12:12 -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 365C044386
	for ; Fri, 29 Sep 2000 16:11:02 -0400 (EDT)
Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (motgate 2.1) with ESMTP id OAA06600 for ; Fri, 29 Sep 2000 14:10:58 -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 OAA01720 for ; Fri, 29 Sep 2000 14:10:57 -0700 (MST)]
Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2650.21)
	id ; Fri, 29 Sep 2000 16:10:57 -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: multipart/mixed;
	boundary="----_=_NextPart_000_01C02A59.C0F324F0"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
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, 29 Sep 2000 16:10:54 -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_000_01C02A59.C0F324F0
Content-Type: text/plain;
	charset="iso-8859-1"

This was forwarded to me. I haven't had a  chance to review it.

-----Original Message-----
From: Henry Sinnreich [mailto:Henry.Sinnreich@WCom.com]
Sent: Friday, September 29, 2000 9:57 AM
To: Michael Thomas; Roy, Radhika R, ALCOO
Cc: Lewis Karl-QA3387; 'Henning Schulzrinne'; sip@lists.bell-labs.com
Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP
Mobility )


>   the SIP mobility draft
Where can I find it?

Thanks, Henry

>-----Original Message-----
>From: sip-admin@lists.bell-labs.com
>[mailto:sip-admin@lists.bell-labs.com]On Behalf Of
>Michael Thomas
>Sent: Thursday, September 28, 2000 5:05 PM
>To: Roy, Radhika R, ALCOO
>Cc: Michael Thomas; Henry Sinnreich; Lewis
>Karl-QA3387; 'Henning
>Schulzrinne'; sip@lists.bell-labs.com
>Subject: RE: [SIP] Attempt at summarizing current SIP
>drafts (SIP
>Mobility )
>
>
>Roy, Radhika R, ALCOO writes:
> > 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.
>
>   OK.
>
> > If it is found that SIP does not need to be
>involved, I do not think that
> > anyone will force it to do this.
>
>   Just to be pedantic about my concern: if the
>   reality of the situation is that mobile ip is
>   going to be needed in the vast majority of
>   devices using SIP -- say because they have
>   embedded web browsers -- as a group, IETF
>   would be better served by trying to solve
>   the problem at layer 3 instead of each WG
>   trying to tackle the problem on their own.
>
>   Remember, the context of my concern here was
>   the SIP mobility draft which seems to take
>   application layer continuous mobility as a
>   starting point.
>
> > 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)?
>
>   By discrete mobility, I assume you mean that
>   SIP doesn't repeat the PSTN'ism of assigning
>   a name (phone number) to the physical end of a
>   wire? Ie, that to: mat@cisco.com is divorced
>   from where I happen to be injecting IP packets
>   from? If so, I agree this is a Good Thing, but
>   I'm not sure that there's much if anything to
>   be done beyond that.
>
> > 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.
>
>   Sure. I said up front that I'm willing to believe
>   that real device layer mobility may very well dredge
>   up problems that need to be solved at the SIP layer
>   too.
>
>		Mike
> >
> > 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


------_=_NextPart_000_01C02A59.C0F324F0
Content-Type: message/rfc822
Content-Description: RE: [SIP] Attempt at summarizing current SIP drafts (SIP Mobility )

Message-ID: 
From: "Roy, Radhika R, ALCOO" 
To: "Roy, Radhika R, ALCOO" , Brian Stucker
	 , sip@lists.bell-labs.com
Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP Mobility
	 )
Date: Fri, 29 Sep 2000 14:16:35 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
List-Help: 
List-Subscribe: , 
List-Unsubscribe: , 
Content-Type: text/plain;
	charset="iso-8859-1"

Hi, Brian:
 
Let me add one more important technical point that has been raised by you:
Race, synchronization, performance, and other problems in the case of
re-INVITE message sent during the mid-session.
 
In general, these are the inherent problems of "continuous (intra-session)"
mobility in all layers: Physical, link, network, and application/session
layer.
 
It is worthwhile to investigate not only for the session layer, but for all
layers together.
 
Some I-Ds are there and people are experimenting in the labs. We like to
hear from them.
 
In the meantime, if you can provide some data on this, it would be much
helpful to see whether more innovative solutions can be found out.
 
Best regards,
Radhika R. Roy
AT&T
 
PS: I have added one word "NOT" in correcting my previous mail.

-----Original Message-----
From: Roy, Radhika R, ALCOO 
Sent: Friday, September 29, 2000 1:51 PM
To: 'Brian Stucker'; sip@lists.bell-labs.com
Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP Mobility )


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 [Roy, Radhika R,
ALARC] "NOT" 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
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_000_01C02A59.C0F324F0--

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


From sip-admin@lists.bell-labs.com  Sat Sep 30 03:32: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 DAA26293
	for ; Sat, 30 Sep 2000 03:32: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 79E8B44339; Sat, 30 Sep 2000 02:32:12 -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 4B0A144337
	for ; Sat, 30 Sep 2000 02:31:47 -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 ;
 Sat, 30 Sep 2000 00:29:43 -0700
From: "Simon Barber" 
To: 
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: 
Subject: [SIP] SIP through firewalls without SIP 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: Sat, 30 Sep 2000 00:33:23 -0700
Content-Transfer-Encoding: 7bit

I currently have a commercial need to make my SIP client operate from
networks with firewalls that will not allow SIP or RTP traffic through. I
have just posted a proposal to the AFT mailing list for a generic mechanism
to allow any protocol to operate through HTTP only firewalls. I've included
a copy of the message below - but this is definately off topic for the SIP
mailing list. Please post your replies on the AFT mailing list.

Simon Barber

------

proxy sockets

firewall admins will hate this.

This is a varient on the SOCKS protocol, with a couple of significant
differences. SOCKS V4 only allows a single TCP connection to be mapped to a
single SOCKS connection. SOCKS V5 is similar to V4 for TCP, and for UDP uses
a second UDP connection to transport the data for the socket that is
proxied.

Increasingly applications are finding that they have to run behindfirewalls,
with restricted access out. Either only TCP, or even HTTP connections may be
possible. As as result any protocol the application requires must be mapped
down to these protocols.

Here I propose a simple RPC mechanism for the berkeley sockets API, to run
over any bi-directional character stream. This could be implemented over
whatever the user wishes - TCP, TLS, HTTP, HTTPS or whatever connection is
available.

Multiple TCP connections, incoming and outgoing, and UDP connections would
all be supported over a single bi-directional character stream.

The protocol is defined in binary, to conserve bandwidth, especially
important since it is envisioned one use will be to carry RTP traffic over
TCP and HTTP connections. These connections are rate-limited, where RTP is
not. Because of this it is considered important to not add to the session
bandwidth. This would exacerbate problems with real-time media during
periods of congestion.

It is recommended that this protocol is implemented on the client as a
library - with a similar API as the berkeley sockets API. This will make it
simple to port non firewall friendly apps to use this protocol.

Messages, client->server:

Format:

1 byte - message number
followed by:

(todo: map API calls to binary messages)
Create
Bind
GetLocalAddr
Listen
GetPeerAddr
Connect
Send
SendTo
Close
IoCtl (used for multicast sockets)

Messages server->client

Create result
Bind result
Accept
Connect result
Recv
IoCtl result


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


From sip-admin@lists.bell-labs.com  Sat Sep 30 07:32: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 HAA27422
	for ; Sat, 30 Sep 2000 07:32: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 2836944339; Sat, 30 Sep 2000 06:32:11 -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 34CA044337
	for ; Sat, 30 Sep 2000 06:31:49 -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 e8UBVnC21742;
	Sat, 30 Sep 2000 17:01:50 +0530 (IST)
Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2  (651.2 6-10-1998))  id 6525696A.003FACAD ; Sat, 30 Sep 2000 17:05:29 +0530
X-Lotus-FromDomain: HSSBLR
From: archow@hss.hns.com
To: Jonathan Rosenberg 
Cc: archow@hss.hns.com, Jonathan Rosenberg ,
        "'sip-implementors@cs.columbia.edu'" ,
        "'sip (E-mail)'" 
Message-ID: <6525696A.003FAB28.00@sampark.hss.hns.com>
Subject: RE: [SIP] Re: More arbitrary limits
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, 30 Sep 2000 17:04:36 +0530






arjun>>> I have worked with people on the embedded side who simply
arjun>>> cannot allocate
arjun>>> more than Xk for SIP messages and
arjun>>> by policy, their application rejects any message greater than
this, by
arjun>>> returning a message too long bad response( I think its a
arjun>>> 413). While this
arjun>>> may not be desirable, at times it can be a practical limitation.

jdr>> Well, I would encourage them to set X to at least 2 or 3 for now. SIP
jdr>> messages are getting bigger all the time.

jdr>> In any case, that is different from the arbitrary limit imposed on a
jdr>> particular header. In this case, requests were being rejected (or
causing
jdr>> the system to crash or something) even though the total length was
within
jdr>> reasonable bounds.

Agree here. As I mentioned in a prev. mail, per header limits is imho,
unjustified.
Per message, well, that you can't do without in many cases.


>
arjun>>> If the UA crashes, I would say its certainly a no-no. If it
arjun>>> declines by
arjun>>> saying 'sorry, I can't handle your message', then its certainly
arjun>>> a scenario that should be still in line. I would say that
arjun>>> this approach is
arjun>>>> still inter-operable .

jdr>> Not really. Interoperability means that communications is
successfully set
jdr>> up. It has not been here.

Actually yes - however  if a client does not accept a message > Xk,it is
still SIP compliant.
As long as it can move back to a steady state giving the other side a valid
protocol message saying why it failed.
I think 'compliant to SIP' would have been  a more appropriate term for me
to use, rather than 'interoperable'. In this case its just the client
policy to say msg>X is a reject.

(Note that I am not talking about this specific case of that vendor's
client barfing )


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  Sat Sep 30 15:35: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 PAA00312
	for ; Sat, 30 Sep 2000 15: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 AE44A44337; Sat, 30 Sep 2000 14:35:11 -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 E680F44336
	for ; Sat, 30 Sep 2000 14:34:20 -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 TAA13031;
	Sat, 30 Sep 2000 19:34:16 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 NAA12799;
	Sat, 30 Sep 2000 13:34:05 -0600 (MDT)
Received: by n0195idc1.oss.level3.com with Internet Mail Service (5.5.2650.21)
	id ; Sat, 30 Sep 2000 13:35:54 -0600
Message-ID: <87A245E94948D3118DE30008C716B01301523B86@c0005v1idc1.oss.level3.com>
To: simon@firetalk.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: Sat, 30 Sep 2000 13:33:58 -0600


When you say 'without SIP proxy', I assume you mean without resorting to the
sort of techniques outlined in:

http://search.ietf.org/internet-drafts/draft-rosenberg-sip-firewalls-00.txt

... or perhaps a case in which the SIP client effectively acts as the ALG
described in that document. I can understand why, if that's where you're
coming from, you'd take this to AFT, but I'd thought that the AFT group had
a slightly different focus (certainly SOCKS does, anyway), in so far the
problems of firewall traversal for protocols like SIP are not matters of
user-level authentication.

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.

Jon Peterson
Level(3) Communications

-----Original Message-----
From: Simon Barber [mailto:simon@firetalk.com]
Sent: Saturday, September 30, 2000 1:33 AM
To: sip@lists.bell-labs.com
Subject: [SIP] SIP through firewalls without SIP proxy


I currently have a commercial need to make my SIP client operate from
networks with firewalls that will not allow SIP or RTP traffic through. I
have just posted a proposal to the AFT mailing list for a generic mechanism
to allow any protocol to operate through HTTP only firewalls. I've included
a copy of the message below - but this is definately off topic for the SIP
mailing list. Please post your replies on the AFT mailing list.

Simon Barber

------

proxy sockets

firewall admins will hate this.

This is a varient on the SOCKS protocol, with a couple of significant
differences. SOCKS V4 only allows a single TCP connection to be mapped to a
single SOCKS connection. SOCKS V5 is similar to V4 for TCP, and for UDP uses
a second UDP connection to transport the data for the socket that is
proxied.

Increasingly applications are finding that they have to run behindfirewalls,
with restricted access out. Either only TCP, or even HTTP connections may be
possible. As as result any protocol the application requires must be mapped
down to these protocols.

Here I propose a simple RPC mechanism for the berkeley sockets API, to run
over any bi-directional character stream. This could be implemented over
whatever the user wishes - TCP, TLS, HTTP, HTTPS or whatever connection is
available.

Multiple TCP connections, incoming and outgoing, and UDP connections would
all be supported over a single bi-directional character stream.

The protocol is defined in binary, to conserve bandwidth, especially
important since it is envisioned one use will be to carry RTP traffic over
TCP and HTTP connections. These connections are rate-limited, where RTP is
not. Because of this it is considered important to not add to the session
bandwidth. This would exacerbate problems with real-time media during
periods of congestion.

It is recommended that this protocol is implemented on the client as a
library - with a similar API as the berkeley sockets API. This will make it
simple to port non firewall friendly apps to use this protocol.

Messages, client->server:

Format:

1 byte - message number
followed by:

(todo: map API calls to binary messages)
Create
Bind
GetLocalAddr
Listen
GetPeerAddr
Connect
Send
SendTo
Close
IoCtl (used for multicast sockets)

Messages server->client

Create result
Bind result
Accept
Connect result
Recv
IoCtl result


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

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